TCP/IP-over-Ethernet 网络中的延迟

Question

您会推荐哪些资源（书籍、网页等）：

• 解释 TCP/IP-over-Ethernet 网络中延迟的原因；
• 提及用于查找导致延迟的事物的工具（例如 中的某些条目netstat -s）；
• 建议调整 Linux TCP 堆栈以减少 TCP 延迟（Nagle、套接字缓冲区等）的方法。

我所知道的最接近的是这个文件，但它相当简短。

或者，欢迎您直接回答上述问题。

编辑需要明确的是，问题不仅仅是关于“异常”延迟，而是关于一般的延迟。此外，它专门针对以太网上的 TCP/IP 而不是其他协议（即使它们具有更好的延迟特性。）

Answer 1

关于延迟的内核可调参数，请牢记：

echo 1 > /proc/sys/net/ipv4/tcp_low_latency

从文档：

如果设置，TCP 堆栈会做出更喜欢更低延迟而不是更高吞吐量的决定。默认情况下，未设置此选项意味着首选更高的吞吐量。应更改此默认值的应用程序示例是 Beowulf 计算集群。默认值：0

您还可以在您的应用程序中禁用 Nagle 算法（它将缓冲 TCP 输出直到最大段大小），例如：

#include <sys/types.h>
#include <stdio.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <linux/tcp.h>

int optval = 1;
int mysock;

void main() {
    void errmsg(char *msg) {perror(msg);exit(1);}

    if((mysock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
        errmsg("setsock failed");
    }

    if((setsockopt(mysock, SOL_SOCKET, TCP_NODELAY, &optval, sizeof(optval))) < 0) {
        errmsg("setsock failed");
    }

    /* Some more code here ... */

    close(mysock);
}

此选项的“相反”是TCP_CORK，它将“重新Nagle”数据包。但是，请注意，因为它TCP_NODELAY可能并不总是按照您的预期执行，并且在某些情况下可能会影响性能。例如，如果您要发送批量数据，您将希望最大化每个数据包的吞吐量，因此设置TCP_CORK. 如果您有一个需要即时交互的应用程序（或响应比请求大得多的应用程序，从而消除开销），请使用TCP _NODELAY. 另一方面，这种行为是 Linux 特有的，而 BSD 可能有所不同，所以请注意管理员。

确保对应用程序和基础架构进行全面测试。

Answer 2

根据我的经验，在其他方面健康的高速网络上造成异常延迟的最大原因是 TCP 窗口化（RFC1323，第 2 节）故障，其次是围绕 TCP 延迟确认的故障（RFC1122 第 4.2.3.2 节）密切相关。这两种方法都是对 TCP 的增强，以便更好地处理高速网络。当它们断裂时，速度会下降到非常缓慢的水平。这些情况下的故障会影响大传输（想想备份流），其中极小的事务性小流量（平均数据传输低于 MTU 大小，并且有很多来回）受这些影响较小。

再一次，当两个不同的 TCP/IP 堆栈进行通信时，我已经看到了这两个问题的最大问题。如Windows/Linux、2.4-Linux/2.6-Linux、Windows/NetWare、Linux/BSD。喜欢喜欢的作品非常非常好。微软在 Server 2008 中重写了 Windows TCP/IP 堆栈，它引入了 Server 2003 不存在的 Linux 互操作性问题（我相信这些问题是固定的，但我不是 100% 确定）。

关于延迟或选择性确认的确切方法的分歧可能导致以下情况：

192.168.128.5 -> 192.168.128.20：1500b 有效载荷，SEQ 1562
192.168.128.5 -> 192.168.128.20：1500b 有效载荷，SEQ 9524
[200ms 通过]
192.168.128.20 -> 192.168.128.5：确认 1562
192.168.128.5 -> 192.168.128.20：1500b 有效载荷，SEQ 12025
192.168.128.5 -> 192.168.128.20：1500b 有效载荷，SEQ 13824
[200ms 通过]
192.168.128.20 -> 192.168.128.5：确认 12025

由于所有 200 毫秒超时（Windows 默认延迟确认计时器为 200 毫秒），吞吐量通过了地板。在这种情况下，对话双方都未能处理 TCP Delayed Ack。

TCP 窗口错误更难被注意到，因为它们的影响可能不太明显。在极端情况下，Windowing 完全失败，你会得到 packet->ack->packet->ack->packet->ack，这在传输明显大于 10KB 的任何东西时真的很慢，并且会放大链路上的任何基本延迟。更难检测的模式是当双方不断重新协商他们的窗口大小并且一方（发送方）未能遵守协商要求时，需要处理几个数据包才能继续传递数据。这种故障在 Wireshark 跟踪中以红色闪烁的灯显示，但表现为低于预期的吞吐量。

正如我所提到的，上述情况往往会困扰大笔转账。像流媒体视频或备份流这样的流量可以真正受到它们的影响，以及非常大的文件（如 Linux 发行版 ISO 文件）的简单下载。碰巧的是，TCP Windowing 被设计为一种解决基本延迟问题的方法，因为它允许数据流水线；您不必为发送的每个数据包等待往返时间，您只需发送一个大块并在发送更多数据之前等待一个 ACK​​。

也就是说，某些网络模式不会从这些变通办法中受益。高度事务性的小传输（例如由数据库生成的传输）受线路上正常延迟的影响最大。如果 RTT 很高，这些工作负载会受到很大影响，而大型流媒体工作负载会受到的影响要小得多。