【发布时间】：2013-12-14 03:28:20
【问题描述】：
我有一个每 20 毫秒通过 TCP 发送数据的设备。我有一个连接到这个设备的应用程序，启动套接字通信。我的应用程序在一个单独的线程上进行侦听，并在数据准备好时尽快读取数据，将数据放在一边，然后其他一些线程处理它。设备通过以太网电缆直接连接到计算机。
我看到一个奇怪的问题，我试图了解原因，几乎每分钟一次，从设备接收数据包需要大约 50 毫秒。我做了一个阻塞读取，它会尝试读取一秒钟，并且会在数据准备好后尽快完成，通常它需要大约 20 毫秒，正如我所期望的那样，但就像我之前所说的那样，有时它需要 50 毫秒，即使它是非常罕见（3000 分之 1）。我注意到的是延迟数据包立即到达后的数据包，所以这让我认为网络层存在一些延迟。我还检查了数据包的时间戳（由设备给出），它们一直增加 20 毫秒。
当设备直接连接到计算机时看到这样的延迟是否正常，因为它是 TCP，所以可能需要付出很多努力（CRC 检查、乱序包、重传等）。我仍然想找到一种替代方法来防止这种延迟，而不是接受它可能发生的事实。
我们将不胜感激任何见解。
【问题讨论】：
-
简单地说，这不是 TCP 的设计初衷！ 你使用“数据包”这个词的那一刻 TCP 是错误的选择，因为 TCP 不适合数据包面向客户。实际上，您没有看到 Nagle 算法出现 200 毫秒的延迟，这有点令人惊讶。
-
在实时数据处理场景中，您会选择什么协议？不幸的是 TCP 是我的设备支持的，我不得不使用它。
-
这可能是该设备不是为这种用途而设计的，或者是为此而设计的，但设计不佳。您可以尝试使用数据包嗅探器来查看实际情况，在极端情况下，您可以使用原始套接字编写您自己的假 TCP 实现，以试图诱使设备更好地执行。或者您可以查看它是否具有串行端口，这可能会为您提供较低延迟的替代通道。或者你可以向它的创建者投诉，或者破解它并更换固件。
-
非常感谢，我会调查的:)
-
不客气。至于应该如何完成低延迟数据包接口，通常是 UDP，可以选择使用任何经过调整的以延迟成本为代价的可靠性方案，您觉得在上面分层是合适的。但首先要确保您的问题是真正的延迟；一些数据的延迟并不一定意味着整体数据速率会落后，而且您似乎在进行异步处理，那么您是否真的需要关心数据何时到达？如果有时间戳（采样的？）在数据块中，也许你可以使用那些并忽略到达时间。