☰

动态 TCP 窗口大小

tag-icon • tag-icon tcp-window-scaling
动态 TCP 窗口大小

在三次握手期间，发送方（10.16.0.128）和接收方（10.16.0.5）分别通告其窗口大小为 42340 和 65535。

从第 3 个数据包（syn+ack+ack）开始，发送方再次通告寡口大小为 166，而接收方通告寡口大小为 512。

您能告诉我为什么窗口大小在没有发送任何段的情况下减小了吗？每次确认时它都会不断变化吗？为什么他们在协商期间没有提交窗口大小。

    10.16.0.128.59570 > 10.16.0.5.22: Flags [S], cksum 0x7da0 (incorrect -> 0xf0a5), seq 2355031382, win 42340, options [mss 1460,sackOK,TS val 4284732064 ecr 0,nop,wscale 8], length 0

09:50:58.661172 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    10.16.0.5.22 > 10.16.0.128.59570: Flags [S.], cksum 0x2d67 (correct), seq 1148159519, ack 2355031383, win 65535, options [mss 1460,sackOK,TS val 216174882 ecr 4284732064,nop,wscale 7], length 0

09:50:58.661229 IP (tos 0x0, ttl 64, id 49621, offset 0, flags [DF], proto TCP (6), length 52)
    10.16.0.128.59570 > 10.16.0.5.22: Flags [.], cksum 0x7d98 (incorrect -> 0x5b8c), seq 1, ack 1, win 166, options [nop,nop,TS val 4284732065 ecr 216174882], length 0

09:50:58.661455 IP (tos 0x0, ttl 64, id 49622, offset 0, flags [DF], proto TCP (6), length 98)
    10.16.0.128.59570 > 10.16.0.5.22: Flags [P.], cksum 0x7dc6 (incorrect -> 0x5b5f), seq 1:47, ack 1, win 166, options [nop,nop,TS val 4284732065 ecr 216174882], length 46

09:50:58.661543 IP (tos 0x0, ttl 64, id 8746, offset 0, flags [DF], proto TCP (6), length 52)
    10.16.0.5.22 > 10.16.0.128.59570: Flags [.], cksum 0x5a03 (correct), seq 1, ack 47, win 512, options [nop,nop,TS val 216174883 ecr 4284732065], length 0

09:50:58.661543 IP (tos 0x0, ttl 64, id 8746, offset 0, flags [DF], proto TCP (6), length 52)
    10.16.0.5.22 > 10.16.0.128.59570: Flags [.], cksum 0x5a03 (correct), seq 1, ack 47, win 512, options [nop,nop,TS val 216174883 ecr 4284732065], length 0```

答案1

在 SYN/SYN+ACK 期间，会提供窗口大小。此外，窗口缩放因子 (又名窗口比例（即wscaleOP 捕获中的）针对整个 TCP 实例进行传输，作为仅对 SYN 数据包（SYN 或 SYN/ACK）有效的 TCP 选项，如RFC 7323：

比例因子的指数在 TCP 选项“窗口比例”中承载。 该选项仅在 <SYN> 段中发送（带有 SYN 位的段），因此当打开连接时，窗口比例在每个方向上都是固定的。

窗口尺度是唯一稍后会固定的部分（每个方向一个值），如果真的谈判，因为这是一个选项。由于最初系统无法知道此类协商是否会成功，即：如果对等方确实支持窗口缩放并且也将在其 SYN/ACK 中发送此选项，它将发送“正常”的暂定窗口大小。一旦协商发生，如果要保持大致相同，则初始窗口大小通常会除以缩放因子。

因此，发送方最初告知它最多可以支持 42340 个字节，并且如果协商成功，则稍后此窗口大小将以 2^8 = 256 的块形式提供。请注意如何 roundup(42340 / 2^8) = 166：下一个可见值。

响应者表示，它最多可以支持 65535（没有窗口缩放的最大值），如果协商成功，将使用后面的 2^7 = 128 字节块。请再次注意如何将 roundup(65535 / 2^7) = 512，这也是下一个可见值。

窗口大小实际上并没有改变。它稍后可能仍会因为其他因素而改变，例如应用程序是否愿意接受更多数据，但这不是这里发生的情况。这里大小几乎没有改变，只是通过使用窗口比例“重新缩放”发送。

为了澄清此案并回应补充评论：

对于每个后续 TCP 段，段中的窗口值必须乘以 2^wscale 才能获得实际窗口值。在此 TCP 连接中，发送方对等体使用 wscale=8，响应方对等体使用 wscale=7（这两个值在此连接生命周期内不会改变）。

  • 发送方的实际窗口大小：166*2^8=42496
  • 响应者的实际窗口大小：512*2^7=65536

如果响应者使用 win 599，那就意味着接受实际窗口大小为 599*2^7=76672。

相关内容