Question

我们不明白这个TCP行为表明redhat linux 5 TCP堆栈（HTTP服务器，这是这个转储的来源）收到了一个SYN的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行为：

＆＃34; telnet serveraddress 80＆＃34;

如果我们使用＆＃34; nc -l 80＆＃34;启动一个简单的网络服务器没有转发。

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

Answer 2

我在重装数据库上遇到同样的问题，所以我发现了这个问题。但看起来我们有不同的原因，所以我会在这里发布我的结果，其他遇到此问题的人可以在这里看到。

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

Test code

BTW，apache行为可能与TCP_DEFER_ACCEPT有关，在这个问题中引用它：real-world-use-of-tcp-defer-accept

Answer 3

发生在我身上，我发现目标主机的子网掩码配置错误（24而不是16）。

TCP ACK被忽略，重传SYN ACK，为什么？

3 个答案: