TCP Window 更新方案

TCP Window Update Scenarios

在我们的应用程序中,我们在 8081 中使用 apache tomcat 网络服务器 运行。

它在 16:42:06.87 IST 时间帧收到来自客户端的 POST 消息。 它在 200 毫秒后通过 window 大小为 62356 字节的 ACK 数据包进行确认。

几秒后(3-5 秒),它也向客户端发送类似的 ACK 数据包,但作为 "TCP Window Update" 65535 字节(缓冲区为空)的数据包。 然后它发送 200 OK 这意味着处理成功...

我的问题:

"TCP Window Update" 数据包从服务器发送到客户端的场景是什么。

这是否意味着网络服务器或 Application-Layer 花了大约 3-5 秒来读取其 TCP 接收器 window 中的 65535-62356(~ 3100)字节,并在读取后发送了 "TCP Window Update" 数据包,因为它尚未发送响应

经过一些套接字测试,

有趣的观察: "TCP Window Update" 仅当应用层仅完全读取整个消息而不是 half/part 数据时才传输数据包!!!

想补充一下,我实际上通过正常的 Client-Server C 套接字编程复制了 "TCP Window Update" 数据包。

场景:

客户端发送一个大段(约3000字节) 服务器接受连接并通过 fork 生成一个 child。 分叉后,服务器需要等待一分钟左右()才能读取套接字。 这通常会向客户端发起一个减少 "TCP window size(65535-3000)" 的 ACK。 我确保读取调用读取完全接收的数据并确保该套接字的 TCP-Receive 队列为空。 话又说回来,服务器需要等待一段时间,然后才写入套接字。 在读取后的等待时间内,我从 iptraces 中看到一个 "TCP Window Update" 数据包从服务器发送到客户端,更新后的 window 为 65535 字节。

此外,当我使用 read 调用读取部分传入数据时,它没有发送 "TCP Window Update packet" 即使缓冲区在部分读取后实际上增加了。

通常 TCP 将发送接收方 window 大小,当它发送 Ack 时,如果需要的话,它有助于与发送方通信到 'slow down'。 'A window update' 通常很少出现在合理实现的客户端和服务器中。 window 更新只是向发件人表明“之前我发送的 window 已满(接收方 window 大小为 0),我可以获取更多数据,你可以发送更多数据。 TCP 的流量控制将尝试确保始终只有最少的(接收方 window,拥塞 window)价值未被确认的数据。 (还有另一种称为持久计时器的东西 - 发件人将在其到期时尝试探测 window 是否打开 - 通过发送 1 个字节的数据,以防客户端从未发送 window 更新)。

您看到的第一个 window 尺寸基本上是由内部 'Delayed acknowledgement Timer' 发送的。这是服务端发给客户端的ack,说可以占用62356字节的数据。这很可能意味着(应用程序(apache 服务器)尚未读取 GET 请求,并且那 300 个奇数字节仍在 TCP 缓冲区中)。没问题。

您在 5-7 秒后看到的可能是对新发送数据的 ACK,它也表明 - 我的应用程序已完成读取所有必须读取的内容,因此通告 window 大小65536。所以那不是 'window update'。它是对某些数据的 ACK 或对客户端发送的 FIN 的 ACK,表示我完成了。

所以没有必要发送 'Window Update' 除非它之前通告 window 为零。看起来不是这样。

作为发送者和接收者,记住这一点也很有帮助——因为 Client/Server 实际上只是由谁做了 listen 和谁做了 connect.[=12= 决定的]