networking - TCP 窗口更新方案

Question

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

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

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

我的问题:

什么情况下“TCP Window Update”数据包会从服务器发送到客户端。

这是否意味着网络服务器或应用层需要大约 3-5 秒来读取其 TCP 接收器窗口中的 65535-62356(~ 3100)字节，并且在读取之后，它已发送“TCP 窗口更新”数据包，因为它是尚未发送回复

经过一些套接字测试，

有趣的观察:“TCP 窗口更新”数据包仅在应用层仅完全读取整个消息而不是一半/部分数据时传输!!!

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

场景:

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

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

Answer 1

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

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

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

因此没有必要发送“窗口更新”，除非它之前通告窗口为零。看起来不是这样。

此外，将发送者和接收者牢记在心也很有帮助——因为客户端/服务器实际上仅由执行 listen 的人员决定。谁做了 connect .