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

Question

首先介绍一下背景:

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

Now a little Data:

我正在使用wireshark来分析这个问题。所有数据都是在连接的客户端(192.168.110.1)端捕获的，因为服务器不容易访问。以下是相关数据(抱歉，格式很糟糕)。这是我能想到的唯一方法来获得这里的数据):

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

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

最后，几个问题:

就像现在很明显的那样，我不是一个TCP专家(甚至不是)。我以为谷歌对我很强大，但我似乎找不到以下问题的答案:

1. 我注意到TCP RST数据包来自我正在交谈的服务器，这很奇怪，因为这个服务器没有回复我的任何其他数据包。这是真的吗?还是有一些TCP欺骗在这里，让我的客户端端口"认为"这个数据包来自服务器，而实际上它是在客户端发起的，试图重置自己?
2. 套接字是否有可能处于可以发送但不能接收的状态?这可以解释我所看到的行为，但仍然无法解释我如何能够接收RST数据包，除非我在1中的假设是正确的。
3. 我注意到重传数据包的大小正在增长…这对TCP来说是正常的吗?我的客户端试图发送到服务器的额外数据包似乎被集中到重传的TCP数据包中。其他一切似乎都正常运行(超时加倍等)。

提前感谢您的时间。

Answer 1

回答你的问题:

1. 客户端发送RST给自己并欺骗服务器，这是非常可疑的。如果是这样，你可能也不会在电线上看到它。查看src和dst MAC地址，它们是否与来自服务器的其他流量相同?
2. 是的，如果接收缓冲区已满，它不能再接收任何东西，但它可以发送窗口更新，或者可能甚至是另一个方向的数据。
3. 是的，这很正常。这叫做重新包装。如果应用程序有更多的数据要发送，TCP将把它添加到重传中。

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

1. 如果通信已经发生了10分钟，那么服务器已经接收到数据并已将其打包。根据我的经验，在这种情况下，RST将包括ACK号，但RST没有。
2. 持续发生在10min。听起来像是防火墙或代理超时。

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