TCP 窗口更新方案

Question

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

它在 IST 时间范围的 16:42:06.87 收到来自客户端的 POST 消息。 它在 200ms 后通过 ACK 包确认，窗口大小为 62356 字节。

几秒钟后（3-5 秒），它也会向客户端发送类似的 ACK 数据包，但作为 65535 字节（缓冲区为空）的“TCP 窗口更新”数据包。 然后它发送 200 OK 这意味着成功处理...

我的问题：

“TCP Window Update”数据包会从服务器发送到客户端的场景有哪些？

这是否意味着 webserver 或 Application-Layer 需要大约 3-5 秒来读取其 TCP 接收器窗口中的 65535-62356(~ 3100) 个字节，并且在读取后，它已发送“TCP 窗口更新”数据包，因为它是还没有回复

经过一些套接字测试，

有趣的观察： “TCP Window Update”数据包仅在应用层仅完全读取整个消息而不是一半/部分数据时传输！！！

想补充一下，我实际上是通过 C 中的普通客户端-服务器套接字编程复制了“TCP 窗口更新”数据包。

场景：

客户端发送一个大段（约3000字节） 服务器接受连接并通过 fork 生成一个子节点。 分叉后，服务器需要等待一分钟左右（）才能读取套接字。 这通常会向客户端发起具有减小的“TCP 窗口大小（65535-3000）”的 ACK。 我确保 read 调用读取完全接收到的数据，并确保该套接字的 TCP-Receive Queue 为空。 再一次，服务器需要等待一段时间，然后才写入套接字。 在读取后的等待时间段内，我从 iptraces 中看到从服务器向客户端发送了一个“TCP 窗口更新”数据包，更新窗口为 65535 字节。

另外，当我使用 read 调用读取部分传入数据时，即使缓冲区在部分读取后实际上增加了，它也没有发送“TCP 窗口更新数据包”。

Answer 1

通常 TCP 会发送接收者窗口大小，当它发送一个 Ack 时，如果需要，它有助于与发送者通信以“减慢”速度。在合理实现的客户端和服务器中，通常很少会看到“窗口更新”。窗口更新只是向发送者表明“之前我发送的窗口已满（接收者窗口大小为 0），我可以获取更多数据，您可以发送更多数据。 TCP 的流量控制将尝试确保始终只有最小的（接收器窗口、拥塞窗口）价值未确认的数据。 （还有一个叫做持久计时器的东西——当它到期时，发送者将尝试探测窗口是否打开——通过发送 1 个字节的数据，以防客户端从未发送过窗口更新）。

您看到的第一个窗口大小基本上是由内部“延迟确认计时器”发送的。这是服务器发给客户端的一个ack，说它可以占用62356字节的数据。这很可能意味着（应用程序（apache 服务器）尚未读取 GET 请求，并且这 300 个奇数字节仍在 TCP 缓冲区中）。没问题。

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

所以没有必要发送“窗口更新”，除非它之前公布的窗口为零。看起来情况并非如此。

记住作为发送者和接收者也是有帮助的——因为客户端/服务器实际上只是由谁执行listen 和谁执行connect 决定。