主页 / server / 问题 / 1156869
Accepted
Rama
Asked: 2024-03-25 22:54:34 +0800 CST

动态 TCP 窗口大小

  • 772

在 3 次握手期间，发送方 (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```
tcp-window-scaling

1 个回答

  1. Best Answer

    在 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 字节块。再次注意如何舍入(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。

    • 1

相关问题