稳定延迟。 Wireshark 捕获的许多 TCP Bad CheckSum 数据包答案

【问题标题】：Stabilizing the latency. Many TCP Bad CheckSum packets captured by Wireshark稳定延迟。 Wireshark 捕获的许多 TCP Bad CheckSum 数据包
【发布时间】：2011-12-05 18:05:07
【问题描述】：

我正在编写一些网络软件并尝试最小化和稳定延迟。我想出了在大多数情况下远程主机的延迟（通过某种协议发送消息和接收 ACK）大约 2 毫秒，但有时会有一些波动（立即变为 40 毫秒，然后回到 2 毫秒），我无法解释（代码非常简单明了），所以我开始责怪网卡。我通过 WireShark 发现的第一件事是有很多 TCP 错误校验和数据包？有可能是这种情况吗？这是第一件事，毕竟我发现操作系统（Linux SLED 11）不正确地检测到我的英特尔网卡。 lspci 命令输出错误的网卡信息。我该如何解决？我应该重新安装驱动程序吗？如果可以，我该怎么做？

谢谢！

【问题讨论】：

标签： linux networking tcp driver

【解决方案1】：

请参阅here 了解校验和错误。校验和有时由您的 NIC 在硬件中计算，因此即使在线路上正确，wireshark 也会错误地看到它。

除非您有直接的点对点网络连接，并且中间没有任何路由器或交换机，否则您将无法消除所有延迟变化。即使使用直接连接，除非您在两端都运行实时操作系统，否则您将无法连接。队列已满、内存调入和调出、运行优先级更高的任务以及许多其他因素都会影响您的延迟。如果您想尽量减少抖动的有害影响，您需要研究抖动缓冲区和滑动窗口协议。

另外，lspci 命令显示在 pci 总线上实际检测到的芯片组，实际上与它使用的驱动程序无关。制造商偶尔会更换芯片组，它们并不总是与包装盒上的品牌匹配。根据驱动程序的历史，名称不一定符合您的期望。如果交通拥堵，您几乎可以肯定使用的是正确的驱动程序。

【讨论】：

感谢您的评论！所以我不应该为校验和错误而烦恼，而实际上更多地关注代码？我直接连接到服务器并运行实时操作系统（也使用实时 Java）。也许你可以推荐一些实践，模式如何有效地组织客户端（例如我需要读取更多的数据并很少发送回服务器）？
延迟、抖动和吞吐量之间总是存在权衡，如何优化取决于应用程序。你用它做什么？
我将它用于贸易应用。从交易服务器连续检索数据，处理每条消息，有时将一些指令发送回服务器。我试图找出好的建筑设计，但我找不到任何材料或以前的经验。现在我想出了单线程（实时最高优先级）-> 我读取 ByteBuffer，解组消息并将其发送到算法（处理大约 50mk 秒）。所以所有的过程都是同步的。也许有2个线程更合适？一个用于 I/O，一个用于算法和它们之间的阻塞队列？
所以我现在正在尝试调整网络延迟，因为我对算法非常有信心（它的处理时间非常稳定并且适合我，50mksec）
该应用程序对抖动不敏感，例如视频或音频流，所以我不会太担心偶尔的 40 毫秒。问题是吞吐量还是延迟对您来说更重要。您可以通过在接收下一个数据时在单独的线程中处理以前的数据来获得更多的吞吐量，因为处理器可以利用数据包之间的间隙。如果周转比每秒交易更重要，那么您当前的单线程架构通常会更好，因为您可以避免上下文切换开销。