TCP ACK已忽略，重新传输SYN ACK，为什么？

Question

我们不理解这种TCP行为，该行为表明redhat linux 5 TCP堆栈(HTTP服务器，这是此转储的来源)接收到SYN，ACK的ACK，但继续忽略该ACK，并重复复制SYN，ACK 5次。最后，服务器在这个“连接”上发送一个HTTP GET的RST。

Time                          Source                Destination           Port   Protocol Length Info
2015-01-30 08:42:18.387260000 81.74.146.89          124.219.82.236        80     TCP      74     64866 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=988669132 TSecr=0
2015-01-30 08:42:18.387309000 124.219.82.236        81.74.146.89          64866  TCP      62     http > 64866 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1
2015-01-30 08:42:18.387354000 81.74.146.89          124.219.82.236        80     TCP      60     64866 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0
2015-01-30 08:42:21.386871000 124.219.82.236        81.74.146.89          64866  TCP      62     [TCP Retransmission] http > 64866 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1
2015-01-30 08:42:21.387118000 81.74.146.89          124.219.82.236        80     TCP      66     [TCP Dup ACK 3#1] 64866 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 SLE=0 SRE=1
2015-01-30 08:42:27.386919000 124.219.82.236        81.74.146.89          64866  TCP      62     [TCP Retransmission] http > 64866 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1
2015-01-30 08:42:27.387165000 81.74.146.89          124.219.82.236        80     TCP      66     [TCP Dup ACK 3#2] 64866 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 SLE=0 SRE=1
2015-01-30 08:42:39.387130000 124.219.82.236        81.74.146.89          64866  TCP      62     [TCP Retransmission] http > 64866 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1
2015-01-30 08:42:39.387376000 81.74.146.89          124.219.82.236        80     TCP      66     [TCP Dup ACK 3#3] 64866 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 SLE=0 SRE=1
2015-01-30 08:43:03.387486000 124.219.82.236        81.74.146.89          64866  TCP      62     [TCP Retransmission] http > 64866 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1
2015-01-30 08:43:03.387709000 81.74.146.89          124.219.82.236        80     TCP      66     [TCP Dup ACK 3#4] 64866 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 SLE=0 SRE=1
2015-01-30 08:43:51.588227000 124.219.82.236        81.74.146.89          64866  TCP      62     [TCP Retransmission] http > 64866 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1
2015-01-30 08:43:51.588449000 81.74.146.89          124.219.82.236        80     TCP      66     [TCP Dup ACK 3#5] 64866 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 SLE=0 SRE=1
2015-01-30 08:57:13.679727000 81.74.146.89          124.219.82.236        80     TCP      353    64866 > http [PSH, ACK] Seq=1 Ack=1 Win=5840 Len=299
2015-01-30 08:57:13.679740000 124.219.82.236        81.74.146.89          64866  TCP      54     http > 64866 [RST] Seq=1 Win=0 Len=0

http://i.stack.imgur.com/5F2ZO.png

pcap：https://www.dropbox.com/s/ave4sctozc5m2a4/TcpAckIgnored.pcapng?dl=0

这种TCP虚假重传的原因是什么？有什么方法可以分析这一点吗？任何帮助我们都深表感谢。

托马斯

Answer 1

经过进一步的调查，我们得出的结论是，这是一种apache行为，我们可以随时用以下命令重现：

"telnet服务器地址80“

如果我们使用"nc -l 80“启动一个简单的we服务器，则不会重新传输。

因此，apache至少需要一个TCP或任何数据包来打开连接。您可以使用netstat进行监控。

Answer 2

我在重新加载数据库时也遇到了同样的问题，所以我找到了这个问题。但是看起来我们有不同的原因，所以我会在这里发布我的结果，让其他遇到这个问题的人可以在这里看到。

在我的例子中，如果我有一个侦听端口，而您不能足够快地接受新的通信连接，那么当侦听队列已满时，您将遇到这个重新传输问题。我有下面的测试代码，你可以用它来自己测试。我已经在ubuntu12.04上测试过了，我不确定你是否会在其他linux版本上得到相同的行为。

Test code

顺便说一句，阿帕奇的行为可能与TCP_DEFER_ACCEPT有关，在这个问题中提到了：real-world-use-of-tcp-defer-accept

Answer 3

这种情况发生在我身上，我发现目标主机的子网掩码配置错误(24个而不是16个)。