即使重置 RST 标志出现后，TCP 重传仍会继续
根据我对 TCP 重置（RST）标志的理解，只要收到的数据段不是用于当前连接的，就会设置 TCP 重置（RST）标志，这会导致中止当前 TCP 会话。但下面粘贴的wireshark捕获似乎并不遵循这个理论。基本上，已启动 RESET（帧＃466）的 A 端本身会尝试通过同一 TCP 会话重新传输 TCP 帧，并继续使用 [RST,ACK] 响应来自 B 端的任何后续新连接请求 [SYN]，并且此行为重复 5 次，并且仅在第 6 次尝试期间，3 次握手才再次成功（帧#486）。
464 04:35.1 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
465 04:35.2 enpc > 50000 [ACK] Seq=7454 Ack=31999 Win=32127 Len=0
466 04:35.2 50000 > enpc [RST] Seq=31999 Win=0 Len=0
467 04:35.4 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
468 04:36.1 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
469 04:37.5 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
470 04:40.3 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
471 04:45.9 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
472 04:57.1 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
473 05:17.1 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
474 05:17.1 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
475 05:17.5 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
476 05:17.5 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
477 05:18.0 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
478 05:18.0 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
479 05:19.5 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
480 05:23.2 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
481 05:23.2 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
482 05:23.7 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
483 05:23.7 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
484 05:24.2 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
485 05:24.2 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
486 05:29.7 dyniplookup > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
487 05:29.7 50000 > dyniplookup [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2
488 05:29.7 dyniplookup > 50000 [ACK] Seq=1 Ack=1 Win=65536 Len=0
489 05:29.7 dyniplookup > 50000 [PSH, ACK] Seq=1 Ack=1 Win=65536 Len=105
490 05:29.7 50000 > dyniplookup [ACK] Seq=1 Ack=106 Win=5840 Len=0
491 05:29.7 dyniplookup > 50000 [PSH, ACK] Seq=106 Ack=1 Win=65536 Len=105
我的问题：
为什么A端不断通过自己生成RST的连接重传数据包？
From my understanding about TCP reset(RST) flag is set whenever a segment received is not intended for the current connection and this results in aborting the current TCP session. But the wireshark capture pasted below doesn't seems to follow this theory. Basically end A which has initiated RESET ( frame#466 ) itself tries to Re-transmit the TCP frames over the same TCP session and also kept on responding any subsequent new connection request [SYN] from end B with [ RST,ACK ] and this behaviour repeats itself for 5 times and 3 way handshake again succeeds only during the 6th attempt (frame#486).
464 04:35.1 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
465 04:35.2 enpc > 50000 [ACK] Seq=7454 Ack=31999 Win=32127 Len=0
466 04:35.2 50000 > enpc [RST] Seq=31999 Win=0 Len=0
467 04:35.4 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
468 04:36.1 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
469 04:37.5 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
470 04:40.3 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
471 04:45.9 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
472 04:57.1 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
473 05:17.1 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
474 05:17.1 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
475 05:17.5 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
476 05:17.5 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
477 05:18.0 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
478 05:18.0 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
479 05:19.5 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105
480 05:23.2 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
481 05:23.2 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
482 05:23.7 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
483 05:23.7 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
484 05:24.2 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
485 05:24.2 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
486 05:29.7 dyniplookup > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
487 05:29.7 50000 > dyniplookup [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2
488 05:29.7 dyniplookup > 50000 [ACK] Seq=1 Ack=1 Win=65536 Len=0
489 05:29.7 dyniplookup > 50000 [PSH, ACK] Seq=1 Ack=1 Win=65536 Len=105
490 05:29.7 50000 > dyniplookup [ACK] Seq=1 Ack=106 Win=5840 Len=0
491 05:29.7 dyniplookup > 50000 [PSH, ACK] Seq=106 Ack=1 Win=65536 Len=105
My Question:
Why end A kept on re-transmitting the packets over a connection where RST was generated from it's own end?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
发送 RST 的原因有很多。当 TCP 段到达但不适合当前打开的连接或侦听端口时，将使用重置标志。例如，如果 TCP 端口关闭，系统上的 TCP 堆栈将使用 RST 进行响应。
通常，当系统发送 TCP 重置时，它也会设置 ack 标志，因为它正在确认连接尝试。在你的情况下，没有 ack 标志，根据 RFC，只有当没有建立连接时才会完成（从记忆中），在你的情况下，这对我来说是一个防火墙或似乎是中间设备（不属于发送重置的 TCP 连接）。因此，服务器 A 仍然会合理地认为连接是活动的。
帧 467-472 是标准 TCP 重传行为（来自系统 A），连接尝试之间的时间加倍，服务器在帧 472 中的最后一次尝试后最终似乎放弃了。这些帧是帧 464 的重传，这似乎表明系统 B 没有收到第 465 帧。我猜您是在系统 B 上捕获的？
我相信系统 A 在发送帧 473 后才转到 CLOSED，这将解释为什么我们随后会看到从系统 B 发起的三向握手。
从您的跟踪来看，如果没有更多的网络知识，很难说更多。
哈！
There are many reasons why a RST might be sent. The reset flag is used when a TCP segment arrives that is not intended for a current open connection or listening port. For example, if the TCP port is closed, the TCP stack on the system will respond with a RST.
Typically when a system sends a TCP reset, it will have the ack flag also set as it's acknowledging a connection attempt. In your case, there's no ack flag, which (from memory) as per the RFC is only done when there's no established connection, which there is in your case, which would suggest to me that it's a firewall or seem intermediary device (not part of the TCP connection) that sends the reset. Therefore, the server A will legitimately then still think the connection is alive.
Frames 467-472 are standard TCP retransmission behaviour (from system A) with the time between connection attempts doubling with the server finally appearing to give up after the last attempt in frame 472. These frames are retransmissions of frame 464, which would appear to indicate that frame 465 was not received by system B. I'm guessing you took the capture on system B?
I believe system A only moved to CLOSED after frame 473 was sent, which will explain why we then see the three-way handshake initiated from system B.
From your trace, it's hard to say much more without more knowledge of the network.
HTH!