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

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

tcp

TCP ACK被忽略，重新传输SYN ACK，为什么？,tcp,Tcp,我们不理解这种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.38

我们不理解这种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

pcap：

TCP伪重传的原因是什么？有没有办法来分析这一点？非常感谢您的帮助

Thomas

在进一步调查后，我们得出结论，这是一种apache行为，我们可以在任何时候复制：

“telnet服务器地址80”

如果我们用“nc-L80”启动一个简单的Web服务器，就不会有重传

因此apache至少需要一个TCP PSH或任何数据包来打开连接。你可以用netstat监控这个问题。

我在重新加载数据库时遇到了同样的问题，所以我发现了这个问题。但看起来我们处于不同的原因，所以我将把我的结果发布在这里，其他遇到这个问题的人可以在这里看到

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

顺便说一句，apache的行为可能与TCP_DEFER_ACCEPT有关，在这个问题中提到了它：

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

你有多确定ACK确实到达了堆栈？嗅探器是否在主机本身上运行？您是否有可能有一个IPTables-FW规则阻止发送ACK？是的，嗅探器正在同一台主机上运行。行为不稳定。这只会偶尔发生。我有时只看到2次重传，在大多数情况下，它在这些地址之间工作得非常完美。我应该补充一点，安装了远程系统日志工具。请尝试使用“-vv”运行嗅探器，并验证返回的ACK中的校验和是否有效。嵌入式协议校验和可能在某处损坏。这仍将允许它路由，但接收主机将无声地丢弃它。这表明在这里和那里之间有一个网络设备在间歇性地破坏东西。谢谢！我们将尝试一下。IP头和TCP的校验和是可以的。netstat-i显示没有丢弃的数据包。Iptables-L-v也显示没有丢弃的数据包。