Networking 忽略SYN/ACK

我正在使用的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秒延迟与TCP超时相匹配，以便在失败的SYN/ACK上重试，因此这是预期的。但令人难以置信的是，客户机从不使用ACK或RST进行响应。当客户端尝试第二次登录时，成功。这个问题在许多首次尝试连接时重现。此程序的其他HTTPS连接也在同时进行，并且在网络跟踪中它们似乎很好

我的怀疑是，存在一种竞争条件，导致套接字有时被错误地管理。但到目前为止，除了受影响的客户机（这是一个非常庞大而复杂的软件），我无法在任何代码中重新创建它。即使使用

nmap

和

hping3

手工制作数据包，客户端始终至少发送一个RST

---

有没有办法（故意或错误地）在userland代码中配置这样的套接字，使其不响应SYN/ACK？

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

在不了解项目的情况下，很难提供比这更多的帮助。希望这有帮助

---

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

否，除了关闭SYN/ACK之外，无法在用户区域中配置TCP套接字来忽略SYN/ACK，这将触发一个输出RST以响应传入的SYN/ACK。对我来说，这听起来像一个内核bug。我想知道所有这些联系。您应该最大限度地利用HTTP keep alive，以最小化单位时间内的新连接数

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