忽略 SYN/ACK答案

【问题标题】：Ignoring SYN/ACK忽略 SYN/ACK
【发布时间】：2011-08-28 05:47:25
【问题描述】：

我正在使用的 Mac OSX 网络客户端有时无法连接到 HTTPS 端口。查看网络跟踪，我们看到：

T0.0 client:port -> server:443 SYN
T0.1 server:443 -> client:port SYN, ACK
T3.1 server:443 -> client:port SYN, ACK
T6.1 server:443 -> client:port RST

3 秒延迟与重试失败的 SYN/ACK 的 TCP 超时相匹配，因此这是意料之中的。但这里令人难以置信的是客户端从不响应 ACK 或 RST。当客户端尝试第二次登录时，它是成功的。此问题在许多第一次尝试连接时重现。该程序还有其他 HTTPS 连接同时进行，并且在网络跟踪中它们似乎很好。

我的怀疑是存在导致套接字有时被错误管理的竞争条件。但到目前为止，除了受影响的客户端（这是一个非常庞大且复杂的软件）之外，我无法在任何代码中重新创建它。即使使用nmap 和hping3 手工制作数据包，客户端总是至少发送一个RST。

有什么方法可以（有意或无意地）在用户空间代码中配置这样的套接字，使其不响应 SYN/ACK？

【问题讨论】：

【解决方案1】：

不，没有办法在用户空间配置 TCP 套接字以忽略 SYN/ACK，除非关闭它，这会引发传出 RST 以响应传入的 SYN/ACK。对我来说，这听起来像是一个内核错误。不过，我想知道所有这些联系。您应该最大限度地利用 HTTP 保持活动，以尽量减少每单位时间的新连接数。

【讨论】：

【解决方案2】：

您不能忽略 SYN/ACK，因为它是 TCP 协议的 3 次握手连接的一部分。在我看来，问题是服务器套接字没有正确打开。其他假设是服务器不可访问（例如防火墙阻止它）。

在不了解该程序的情况下，很难提供比这更多的帮助。希望这会有所帮助！

编辑：检查您是否正确关闭了前一个客户端的套接字。可能会发生先前的套接字未正确关闭并且操作系统达到允许打开的套接字的限制。在这种情况下，会发送一个 RST 数据包。

【讨论】：

如果服务器不可访问，那么我就不会从中获得 SYN/ACK。我的问题是 my 一方没有发送所需的 ACK（因此，尽管有规则，但显然可以忽略 SYN/ACK，因为它正在发生：D 现实总是胜过规范）。同样，如果我的套接字用完了，我不会发送初始的 SYN，但我是。我的工作理论是我必须不小心使用相同的套接字文件描述符来连接线程以尝试与两个不同的服务器通信。不过，我无法证明如果您尝试这样做会发生什么。
对不起，我不同意你的观点。您不能忽略 TCP 连接上的 3 次握手！如果忽略它，则不会建立连接。但是您的理论可能是正确的：也许您正在使用并发线程访问客户端的同一个套接字，其中一个可能正在关闭套接字，而不是发送 ACK，因此是服务器发送的 RST。尝试检查您的理论（我不知道您的程序）。事实上，RST 最常见的原因是套接字被关闭 :)
我同意 OP。上面的答案显然是错误的。如果服务器套接字没有正确打开，它就没有发送 SYN/ACK。