Wireshark TCP Dup ACK - 奇怪[关闭]答案

【问题标题】：Wireshark TCP Dup ACK - strange [closed]Wireshark TCP Dup ACK - 奇怪[关闭]
【发布时间】：2023-04-02 20:30:01
【问题描述】：

我在服务器的电脑上运行了Wireshark，却出现了这么奇怪的传输：

客户端（X：src 端口 65509）连接到我的服务器（Y：dst 端口 9999）。

1) 有正常的 TCP 握手

15:47:41.921228 XXX.XXX.XXX.XXX 65509   YYY.YYY.YYY.YYY 9999    65509 > distinct [SYN] Seq=0 Win=8688 Len=0 MSS=1460 WS=0 SACK_PERM=1 TSV=66344090 TSER=0
15:47:41.921308 YYY.YYY.YYY.YYY 9999    XXX.XXX.XXX.XXX 65509   distinct > 65509 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1 TSV=69754693 TSER=66344090
15:47:42.176823 XXX.XXX.XXX.XXX 65509   YYY.YYY.YYY.YYY 9999    65509 > distinct [ACK] Seq=1 Ack=1 Win=8688 Len=0 TSV=66344350 TSER=69754693

2) 服务器向客户端发送加密密钥，客户端 ACK 收到它：

15:47:42.180755 YYY.YYY.YYY.YYY 9999    XXX.XXX.XXX.XXX 65509   distinct > 65509 [PSH, ACK] Seq=1 Ack=1 Win=65160 Len=24 TSV=69754719 TSER=66344350
15:47:42.452606 XXX.XXX.XXX.XXX 65509   YYY.YYY.YYY.YYY 9999    65509 > distinct [ACK] Seq=1 Ack=25 Win=8664 Len=0 TSV=66344630 TSER=69754719

3) 突然面板由于某种原因重置连接

15:47:42.948618 XXX.XXX.XXX.XXX 65509   YYY.YYY.YYY.YYY 9999    65509 > distinct [RST] Seq=28 Win=0 Len=0

4) 但对我来说奇怪的是这里。服务器发送 TCP Dup ACK。这可能是什么原因？我以为这条消息只有在重传或某事后才能发送。我从未见过它会在 RST 之后发送。

15:47:42.948654 YYY.YYY.YYY.YYY 9999    XXX.XXX.XXX.XXX 65509   [TCP Dup ACK 5856#1] distinct > 65509 [ACK] Seq=25 Ack=1 Win=65160 Len=0 TSV=69754796 TSER=66344630**

5) 客户端再次发送 RST。

15:47:43.227269 XXX.XXX.XXX.XXX 65509   YYY.YYY.YYY.YYY 9999    65509 > distinct [RST] Seq=1 Win=0 Len=0

感谢您的任何建议。

【问题讨论】：

Stackoverflow 旨在解决与编程相关的问题（请参阅常见问题解答，stackoverflow.com/faq）。您的问题并未表明涉及到编程。
Sjoerd，您是否阅读了您链接的常见问题解答？ [cut] ...但是如果您的问题通常涵盖... * 程序员常用的软件工具 * 编程行业独有的问题... 那么您来对地方提出您的问题了！ [/cut] Wireshark 不是编程行业独有的工具之一吗？
据我判断，您的问题不在于 Wireshark 作为程序员的工具，而在于您使用 Wireshark 作为诊断工具获得的结果。从您的问题的措辞看来，您的问题出在客户端和服务器之间的通信中。 SuperUser 或 ServerFault 站点似乎更适合解决此类问题。

标签： sockets tcp connection wireshark

【解决方案1】：

步骤(4)中来自服务器的Dup-ACK是由步骤(3)中的Seq 28引起的：

      65509 > distinct [RST] Seq=28 Win=0 Len=0

因为服务器期待 Seq#25 但收到了 #28。当 seq 25~27 在网络中丢失时，就会发生这种情况。 Dup-ACK在RST之前通知客户端重传丢失的数据；然而，在步骤（5）中，我们看到客户端响应服务器的 dup-ack 再次重置。所以客户端数据 #25~27 从未到达服务器并且已经消失了。

您可以通过在服务器和客户端上进行数据包捕获来验证这一点。

详情请阅读一些TCP重传文档。

【讨论】：