Windows Winsock TCP重传/重置协议详细信息

首先是一点背景：

我目前有一个通过TCP与服务器对话的客户端。客户端和服务器都运行Windows并使用WinSocks。我向服务器发送各种消息，并且每秒至少发送一条消息。几乎每10分钟，我就会发现服务器似乎停止回复我的客户机。然后，我看到来自客户端的5次重新传输，每次使用加倍的超时时间，最后在客户端上从服务器接收到一个RST包。这将重置我的客户端套接字，分配一个新的端口号，然后通信继续正常进行10分钟

下面是一些数据：

我正在使用wireshark分析这个问题。所有数据都是在连接的客户端（192.168.110.1）捕获的，因为服务器不容易访问。下面是相关数据（很抱歉格式太糟糕了。这是我唯一能在这里找到数据的方法）：

1-6-原始和重新传输的数据包
7-从服务器接收到重置
8-10-使用新的客户端端口号在客户端和服务器之间进行新的握手
11-12-第一条新消息和带有新客户端端口号的响应

最后，有几个问题：

现在很可能很明显，我不是TCP大师（甚至不是很亲密）。我认为谷歌对我很强大，但我似乎无法找到以下问题的答案：

我注意到TCP RST数据包来自于我正在与之交谈的服务器，这是奇怪的，因为该服务器没有回复我的任何其他数据包。这是真的吗？还是有一些TCP欺骗在这里进行，使我的客户端端口“认为”这个数据包是来自服务器的，而实际上它是在客户端发起的，以尝试重置自身

套接字是否可能处于可以发送但不能接收的状态？这可以解释我看到的行为，但仍然不能解释我如何能够接收RST数据包，除非我在1中的假设是正确的

我注意到重传数据包的大小在增长…这对TCP来说正常吗？我的客户端试图发送到服务器的其他数据包似乎被集中到重新传输的TCP数据包中。其他一切似乎都正常工作（超时加倍等）

---

提前感谢您的时间。

对您的问题的回答：

客户机向自己发送RST并欺骗服务器是极为可疑的。如果是这样的话，你可能不会在电线上看到它。查看src和dst MAC地址，它们是否与来自服务器的其他流量相同

是的，如果接收缓冲区已满，它将无法再接收任何内容，但它可以发送窗口更新，或者甚至可以发送其他方向的数据

是的，这很正常。这是电话。如果应用程序有更多数据要发送，TCP会将其添加到重传中

有两件事让我怀疑RST是否不是来自服务器，而是来自中间设备或主机防火墙：

如果通信已持续10分钟，则服务器已收到数据并已确认数据。根据我的经验，在这种情况下，RST将包括一个ACK号，但RST没有

它在10分钟内持续发生。听起来像是防火墙或代理超时

如果是服务器应用程序问题（进程出现问题并停止从套接字读取数据），服务器上的TCP仍会确认接收到数据，但其接收窗口将填满。在这种情况下，由于没有ACK，客户端的数据包似乎在这两者之间的某个地方被丢弃或阻止

RefNum|Source|Destination|Length|Packet Info

1 | 192.168.110.1 | 192.168.110.22 | 61 | 62314 > 7074 [PSH, ACK] Seq=693 Ack=8483 Win=63303 Len=7

2 | 192.168.110.1 | 192.168.110.22 | 75 | [TCP Retransmission] 62314 > 7074 [PSH, ACK] Seq=693 Ack=8483 Win=63303 Len=21

3 | 192.168.110.1 | 192.168.110.22 | 75 | [TCP Retransmission] 62314 > 7074 [PSH, ACK] Seq=693 Ack=8483 Win=63303 Len=21

4 | 192.168.110.1 | 192.168.110.22 | 89 | [TCP Retransmission] 62314 > 7074 [PSH, ACK] Seq=693 Ack=8483 Win=63303 Len=35

5 | 192.168.110.1 | 192.168.110.22 | 113 | [TCP Retransmission] 62314 > 7074 [PSH, ACK] Seq=693 Ack=8483 Win=63303 Len=59

6 | 192.168.110.1 | 192.168.110.22 | 135 | [TCP Retransmission] 62314 > 7074 [PSH, ACK] Seq=693 Ack=8483 Win=63303 Len=81

7 | 192.168.110.22 | 192.168.110.1 | 64 | 7074 > 62314 [RST] Seq=8483 Win=0 Len=0 [ETHERNET FRAME CHECK SEQUENCE INCORRECT]

8 | 192.168.110.1 | 192.168.110.22 | 66 | 62348 > 7074 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

9 | 192.168.110.22 | 192.168.110.1 | 64 | 7074 > 62348 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 [ETHERNET FRAME CHECK SEQUENCE INCORRECT]

10 | 192.168.110.1 | 192.168.110.22 | 54 | 62348 > 7074 [ACK] Seq=1 Ack=1 Win=64240 Len=0

11 | 192.168.110.1 | 192.168.110.22 | 56 | 62348 > 7074 [PSH, ACK] Seq=1 Ack=1 Win=64240 Len=2

12 | 192.168.110.22 | 192.168.110.1 | 72 | 7074 > 62348 [PSH, ACK] Seq=1 Ack=3 Win=5838 Len=18