0

我们正在运行带有 2.6.16 内核的 D​​ebian，并启用了 iptables。系统正在运行一个定制的 HTTP 代理，该代理受到轻微负载（它在其他站点上的相同负载下工作正常）。该系统由 4 台服务器组成，前面是具有虚拟 IP 的负载平衡器，前面是 4 台 ISA 2004 机器的阵列，因此基本拓扑为：

客户端 -> ISA [1-4] -> 负载均衡器 -> 我们的代理 [1-4] -> 互联网

有时，ISA 会向我们发送一个 SYN 数据包，但没有向该数据包发送 SYN-ACK。3秒后会再试，6秒后会再试第三次，之后会报告proxy down，并切换到直连。在此期间，即在这 3 个 SYN 之前、之中和之后，来自同一 ISA 的其他 SYN 会出现并得到成功响应。

其他人报告了一个非常相似的问题（但是没有解决方案）：

所有这些都来自一种名为 CentOS 的 Linux。它的特点是默认启用 iptables。

http://www.linuxhelpforum.com/showthread.php?t=931912&mode=linear http://www.centos.org/modules/newbb/viewtopic.php?topic_id=16147

几乎相同：但有点不同： http ://www.linuxquestions.org/questions/linux-networking-3/tcp-handshake-fails-synack-ignored-by-system.-637171/

似乎也相关： http ://groups.google.com/group/comp.os.linux.networking/browse_thread/thread/b1c000e2d65e0034

我怀疑 iptables 是罪魁祸首，但欢迎提供任何额外的反馈。

4

2 回答 2

2

如您发布的第一个链接中所述，查看listen 调用的第二个参数。这是待处理（尚未接受）连接的最大数量。根据listen（2）手册页，如果协议支持重传（TCP支持），当队列满时连接请求将被丢弃（期待稍后重传，如果队列中有足够的空间再次创建连接）。

于 2008-10-19T15:45:06.340 回答
0

Indeed, the iptables turned out to be the culrpit, with the rule that dropped INVALID packets. We still do not know for sure what made iptables to think those SYNs were invalid (no TIME_WAIT for sure, since we did not have any traffic with the same source ports for at least 30 mins prior to the drops).

于 2008-10-23T14:07:02.933 回答