我有一个应用程序（在Win2k12上运行）通过TCP下载stream。
问题是连接被发送者closures，因为它超时。
我使用wireshark来查看2个不同服务器上发生了什么（在一台服务器上工作正常，另一台服务器超时）。 我已经注意到两者上的相同的行为：
当下载开始时，一切似乎确定，窗口大小是64K，并保持相同的一段时间，段得到确认。 然后在某个时候，窗口大小开始减less，直到它为0（据我所知，这是好的，接收方不能跟上发送方。）但是，没有从接收方的ACK或窗口更新消息，直到整个缓冲区被应用程序读取，然后一个窗口更新再次宣传64k窗口大小。 然后重新开始。 窗口大小减小到零。
这对我来说并不合适。 当应用程序从缓冲区中读取时，它应该有空闲空间，并且应该发送一个Window更新，所以发送者可以发送下一个段。
另一件我不明白的是失败的服务器上的行为。 这个服务器在每个这样的周期中通告越来越大的窗口大小，在超时之前的最后一个周期中，窗口大小是〜800 000。超时发生，因为缓冲区未被清空足够快。 但我不知道为什么在这台服务器上的窗口大小增加？ 有没有在服务器上设置，以防止这种情况？
我的假设是正确的，还是我误解了TCP协议？ 任何想法来解决这个问题表示赞赏。
谢谢。
如果接收过程没有像在networking上传输数据那样快速地处理数据，那么随着接收数据包被接收，窗口应该变小，直到接收缓冲区已满，并且窗口为0.服务器仍然被认为是ACK在这种情况下收到的数据，使发送者知道不要重发它。
一旦窗口已经变为0，接收端就不应该通知在应用程序从stream中读取另一个字节时，在窗口中有更多的数据。 它至less应该等到有足够的空闲空间来匹配一个MTU大小的数据包。 等待比这更长的时间不是一个好主意。
在传输过程中dynamic调整内存分配大小是明智的行为。 然而，algorithm应该集中在一个足够大的尺寸上，以避免造成瓶颈，但不应该比这个大得多。 你描述的方式波动，不应该发生。 而如果接收的应用程序不能跟上到达的数据，那么窗口大小不应该增加。
发送方不应该在不发送less量保持活动数据包的情况下超时连接。 如果发送者超时而不发送keep-alive数据包，那么我会说发送者有一个错误。 如果发送者发送保持活动的数据包，但接收者不响应他们，那么我会说有一个接收器的错误。
你有没有检查连接的每一端的通信，以确保没有任何重大的数据包丢失，导致超时？