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