TCP之延时Nagle算法实验详解

news2025/1/11 16:58:46

TCP/IP协议中，无论发送多少数据，总是要在数据前面加上协议头，同时，对方接收到数据，也需要发送ACK表示确认。为了尽可能的利用网络带宽，TCP总是希望尽可能的发送足够大的数据。（一个连接会设置MSS参数，因此，TCP/IP希望每次都能够以MSS尺寸的数据块来发送数据）。Nagle算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。
Nagle算法的基本定义是任意时刻，最多只能有一个未被确认的小段。所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。
当 TCP 报文的承载的数据非常小的时候，例如几个字节，那么整个网络的效率是很低的，因为每个 TCP 报文中都会有 20 个字节的 TCP 头部，也会有 20 个字节的 IP 头部，而数据只有几个字节，所以在整个报文中有效数据占有的比重就会非常低。
在这里插入图片描述

nagle 算法讲的是减少发送端频繁的发送小包给对方。
Nagle 算法要求：当一个 TCP 连接中有在传数据（已经发出但还未确认的数据）时，小于 MSS 的报文段就不能被发送，直到所有的在传数据都收到了 ACK。同时收到 ACK 后，TCP 还不会马上就发送数据，会收集小包合并一起发送。
在这里插入图片描述

可以看到前后对比：

packetdrill 演示

packetdrill 脚本

--tolerance_usecs=100000
0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
// 0.010 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
0.100...0.200 connect(3, ..., ...) = 0
// Establish a connection.
0.100 > S 0:0(0) <mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 7>
0.200 < S. 0:0(0) ack 1 win 32792 <mss 1100,nop,wscale 7>
0.200 > . 1:1(0) ack 1
+0 write(3, ..., 10) = 10
+0 write(3, ..., 10) = 10
+0 write(3, ..., 10) = 10
+0 write(3, ..., 10) = 10
+0 write(3, ..., 10) = 10
+0.030 < . 1:1(0) ack 11 win 257
+0.030 < . 1:1(0) ack 21 win 257
+0.030 < . 1:1(0) ack 31 win 257
+0.030 < . 1:1(0) ack 41 win 257
+0.030 < . 1:1(0) ack 51 win 257
+0 `sleep 1000000`

数据量比较小的场景：

Nagle 算法的意义

Nagle 算法的作用是减少小包在客户端和服务端直接传输，一个包的 TCP 头和 IP 头加起来至少都有 40 个字节，如果携带的数据比较小的话，那就非常浪费了。就好比开着一辆大货车运一箱苹果一样。
在这里插入图片描述

Nagle 算法是时代的产物

Nagle 算法在通信时延较低的场景下意义不大。在 Nagle 算法中 ACK 返回越快，下次数据传输就越早。假设 RTT 为 10ms 且没有延迟确认，那么你敲击键盘的间隔大于 10ms 的话就不会触发 Nagle 的条件。如果你想触发 Nagle 的停等（stop-wait）机制，1s 内要输入超过 100 个字符。因此如果在局域网内，Nagle 算法基本上没有什么效果。
如果客户端到服务器的 RTT 较大，比如多达 200ms，这个时候你只要1s 内输入超过 5 个字符，就有可能触发Nagle 算法了。Nagle 算法出现的时候网络带宽都很小，当有大量小包传输时，很容易将带宽占满，出现丢包重传等现象。因此对 ssh 这种交互式的应用场景，选择开启 Nagle 算法可以使得不再那么频繁的发送小包，而是合并到一起，代价是稍微有一些延迟。现在的 ssh 客户端已经默认关闭了 Nagle 算法。