在我们的应用程序中，我们使用的是在8081中运行的apache tomcat webserver .
它在IST时间帧16：42：06.87从客户端收到POST消息 . 它通过ACK数据包确认，在200ms后窗口大小为62356字节 .
在几秒钟（3-5秒）之后，它还向客户端发送类似的ACK数据包，但作为65535字节（缓冲区空）的“TCP窗口更新”数据包 . 然后它发送200 OK表示成功处理......
我的问题：
将“TCP窗口更新”数据包从服务器发送到客户端的方案是什么 .
这是否意味着Web服务器或应用程序层需要大约3-5秒来读取其TCP接收器窗口中的65535-62356（~3100）字节，并且在读取之后，它已发送“TCP窗口更新”数据包，因为它尚未发送响应
经过一些套接字测试，
有趣的观察：“TCP窗口更新”数据包仅在应用层仅完全读取整个消息而不是一半/部分数据时传输！
想添加我实际上通过C中的普通客户端 - 服务器套接字编程再现“TCP窗口更新”数据包 .
场景：
客户端发送一个大段（约3000字节）服务器接受连接并通过fork生成一个子 . 在fork之后，服务器需要等待一分钟左右（）才能读取套接字 . 这通常会向客户端发起一个减少“TCP窗口大小（65535-3000）”的ACK . 我确保读取调用读取完全接收的数据并确保该套接字的TCP接收队列为空 . 然后，服务器需要等待一段时间，然后只写入套接字 . 在读取后的等待时间段内，我从iptraces看到“TCP窗口更新”数据包从服务器发送到客户端，更新窗口为65535字节 .
此外，当我使用读取调用来读取部分传入数据时，即使缓冲区在部分读取后实际增加，它也不会发送“TCP窗口更新数据包” .
1 回答
通常TCP会发送接收器窗口大小，当它发送Ack时，如果需要，它有助于与发送者通信以“减速” . 在合理实施的客户端和服务器中，通常很少会看到“窗口更新” . 窗口更新只是向发件人表明'我之前发送的窗口已满（接收器窗口大小为0），我可以获取更多数据，您可以发送更多数据 . TCP的流量控制将尝试确保始终只有最小的（接收器窗口，拥塞窗口）值的数据未被确认 . （还有另一种叫做持久定时器的东西 - 当过期时，发送者将尝试通过发送1字节数据来探测窗口是否被打开 - 以防客户端从未发送窗口更新） .
您看到的第一个窗口大小基本上由内部“延迟确认定时器”发送 . 这是服务器发送给客户端的ack，表示它可以占用62356个字节的数据 . 这很可能意味着（应用程序（apache服务器）尚未读取GET请求，并且300个奇数字节仍在TCP缓冲区中） . 不是问题 .
你在5-7秒后看到的内容可能是对新发送的数据的确认，它也在说明 - 我的应用程序已经读完了必须读取的内容，因此宣告窗口大小为65536.所以这不是'窗口更新” . 这是对某些数据的ACK或客户端发送的对FIN的ACK，说我已经完成了 .
所以不需要发送“窗口更新”，除非它先前通告了一个零窗口 . 哪个看起来不像这样 .
此外，它还有助于牢记发送者和接收者 - 因为客户端/服务器实际上只是由谁做
listen以及谁做connect.