![Wireshark 在每个常规 ACK 之后在 SACK 上显示“TCP Dup Ack”](https://linux22.com/image/670346/Wireshark%20%E5%9C%A8%E6%AF%8F%E4%B8%AA%E5%B8%B8%E8%A7%84%20ACK%20%E4%B9%8B%E5%90%8E%E5%9C%A8%20SACK%20%E4%B8%8A%E6%98%BE%E7%A4%BA%E2%80%9CTCP%20Dup%20Ack%E2%80%9D.png)
我通过交换机端口镜像和 tcpdump 捕获了一个 TCP 会话。查看它时(在 Wireshark 中),每当我发送消息时,我都会看到相同的模式;以下是出站数据包的摘录(我还没有捕获入站数据包...):
[PSH, ACK] Seq=34477 Ack=46645 Len=51 # sending first message
[ACK] Seq=34528 Ack=46714 Len=0 # acknowledge response (not shown)
[ACK] Seq=34528 Ack=46714 Len=0 SLE=46645 SRE=46714 # TCP Dup Ack!
[PSH, ACK] Seq=34528 Ack=46714 Len=51 # sending second message
[ACK] Seq=34579 Ack=46783 Len=0 # acknowledge response (not shown)
[ACK] Seq=34579 Ack=46783 Len=0 SLE=46714 SRE=46783 # TCP Dup Ack!
问题是,为什么我会收到这些“dup ack”数据包,它们实际上是 TCP 选择性确认 (SACK) 数据包,似乎与它们之前的常规 ACK 数据包完全冗余?
对于此 TCP 流,我总是看到上述模式。该机器运行的是 RHEL7。当我在常规接口(而不是镜像)上运行 tcpdump 时,我没有看到重复的确认。
答案1
在您的场景中,主机收到重复的数据包 - 一份来自初始源,另一份来自镜像端口。它会回复两者,然后您会在镜像端口上看到两个答案。
只要数据包被内核处理,接口就无关紧要了,应用程序关心的唯一参数是 IP 和端口。