我们的服务器遭遇了严重的连接超时问题，因此我们使用 tcptrack 来跟踪 tcp 连接
我们发现，如果客户端开始连接到服务器，tcptrack 会显示连接，但处于 SYN_SENT 状态，并且netstat -nat不显示任何内容。（tcptrack 和 netstat 都在服务器上运行）
- 这是否意味着 syn 请求已到达服务器？并且没有发回 syn/ack？
- 为什么 tcptrack 可以报告此连接但 netstat 却不能？
- 通用apache无法与客户端建立连接可能是什么问题？
我使用同一个内联网进行了基准测试ab，对于指定的 NIC，它可以处理 10000 个并发连接和 400000 个请求
附言：这种情况不是每次都会发生，但确实发生过很多次
pps：有没有什么好的工具可以追踪 tcp 连接丢失的位置？
答案1
这意味着客户端发送了 SYN，但该 SYN 未到达服务器，服务器未回复该 SYN，或者服务器选择回复该 SYN 而不进行跟踪。服务器不需要跟踪它发送的每个 SYN 回复（可以使用SYN cookie) 因为它们可能会被欺骗，这样做会产生拒绝服务攻击的风险。
答案2
当我收到“不需要的”流量时，例如已被 IPTABLES 规则专门阻止的流量（例如被 DROPped），tcptrack 会显示传入的 IP 地址以及 SYN_SENT 状态（以及连接时间和 0b/秒的数据速率）。该列表会停留几秒钟，直到清除。
因此 - 您看到的连接可能由于某种原因被阻止。SYN_SENT 出现的 IP 地址可能由于 IPTABLES DROP 而被锁定。您可以暂时禁用 IPTABLES，看看这种情况是否继续。如果是，请确保被阻止的地址是应该的。