我正在做一个项目，用新的硬件替换现有的具有相同功能的嵌入式linux设备。我们已经过渡到Microchip WiFi模块（WFI 32 E01）运行他们的TCP堆栈，性能一直很好，因为我们只是通过HTTP与Windows软件通信。它还需要向后兼容另一块Windows软件，我遇到了断开/重新连接，由于什么似乎是全缓冲区。我们的Windows程序和设备之间的通信正常。无无序数据包或重置。另一个Windows程序和设备之间的通信有缺陷，如下图所示，并导致连接重置。
Wireshark capture
我将捕获解释为Windows（192.168.211.1 0），说明其窗口已满。它让我感到困惑的原因是，设备只响应来自Windows软件的HTTP请求，所以我不认为会有足够的吞吐量来填满窗口缓冲区。此Windows软件与以前的设备版本配合良好，这表明它可能是新设备出现故障，但错误似乎是在Windows方面。192.168.211.1是运行DHCP服务器的嵌入式设备的I。也许有人能给我指出正确的方向
附加信息：
V1 Legacy HTTP Request的
V1 Legacy HTTP Response的
V2 New Device Microchip HTTP Request的
V2 New Device Microchip HTTP Response的
原始V1设备的HTTP请求包括一个“keep-alive”报头，我认为这在HTTP1.1中是多余的，但从同一个Windows PC到新的硬件设备仍然不存在。V1设备响应有HTTP1.0和HTTP1.1，但我不知道为什么，如果我应该尝试复制。
1条答案
按热度按时间wn9m85ua1#
让我解释一下那里发生了什么：
1.从分组7开始进行连接。连接建立以分组9正确地结束。主机位于端口62121（客户端，windows，通告窗口大小--可能是它的缓冲区大小-为64240）和80（传感器设备，充当服务器）通告窗口1024（小型设备常见）
1.进行两个HTTP请求以获得相同的资源，一些温度，它们之间的延迟为5秒。
1.一个额外的数据包（可能是重复的数据包17被发送-它似乎是自动的，因为两者之间几乎没有延迟，不需要，但许多实现这样做，以确保更好的连接关闭）
1.重置作为对分组21（零窗口分组）的响应而出现，分组21在两端都已确认它们的FIN之后被发送，这发生在分组20之后。此数据包不应被发送，并且RST由设备正确发送。在分组16之后，客户端发送窗口大小0仍然有效（但是不期望的是，允许分组流，仅仅忽略它，比使发送方保留将不可能递送的分组更好），但是在从服务器接收到FIN分组20之后不再有效（它发信号通知不再发送数据，因此，在接收到窗口大小为0之后，宣布窗口大小为0将在协议中产生故障，并且RST消息将是适当的）窗口大小为0显然是非法的，因为它是在FIN之后发送的，因此它显然是在连接上下文之外。这显然是对TCP协议的误解，与窗口大小信令有关，窗口大小信令仅是流控制资源，而不是关闭数据流。
注意，这里没有缓冲区满的情况……两侧的缓冲区大于1024字节，并且全连接总共传输215字节（每两个HTTP请求）。（SYN/FIN标志每个计数为一个字节，在wireshark输出中总共排序为217）窗口零数据包可能是由客户端软件作为安全网络发送的-但它误解了窗口的使用并使协议失败，被发送出连接-以科普可能不相关的错误。众所周知，Windows软件具有错误的TCP实现。