忽略 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 秒的延迟与重试失败的 SYN/ACK 的 TCP 超时相匹配，因此这是预期的。但令人难以置信的是，客户端从未回复 ACK 或 RST。当客户端再次尝试登录时，就成功了。在许多首次连接尝试中都会重现此问题。来自该程序的其他 HTTPS 连接同时进行，并且它们在网络跟踪中似乎正常。
我怀疑存在竞争条件，导致套接字有时被错误管理。但到目前为止，除了受影响的客户端（这是一个非常大且复杂的软件）之外，我无法在任何代码中重新创建它。即使使用 nmap 和 hping3 手工制作数据包，客户端也始终至少发送一个 RST。
有没有办法在用户态代码中配置（有意或无意）这样的套接字，使其不响应 SYN/ACK？
A Mac OSX network client I'm working on sometimes having trouble connecting to an HTTPS port. Looking at the network trace, we're seeing this:
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
The 3 second delay matches the TCP timeout for retrying on a failed SYN/ACK, so that's expected. But what is incredible here is that the client never responds with ACK or RST. When the client tries to login a second time, it is successful. This problem reproduces on many first attempts to connect. There are other HTTPS connections from this program going on at the same time, and they appear to be fine in the network traces.
My suspicion is that there is a race condition causing the socket to sometimes be incorrectly managed. But so far I've been unable to recreate this in any code but the impacted client (which is a very large and complicated piece of software). Even using nmap and hping3 to hand-craft the packets, the client always sends at least a RST.
Is there any way to configure (intentionally or by mistake) a socket like this in userland code so it doesn't respond to SYN/ACK?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，没有办法在用户态配置 TCP 套接字来忽略 SYN/ACK，除非关闭它，否则会引发传出 RST 以响应传入的 SYN/ACK。对我来说这听起来像是一个内核错误。但我想知道所有这些联系。您应该最大限度地利用 HTTP 保持活动来最小化每单位时间的新连接数。
No, there is no way to configure a TCP socket in user land to ignore a SYN/ACK except to close it, which would provoke an outgoing RST in response to the incoming SYN/ACK. It is sounding like a kernel bug to me. I'm wondering about all these connections though. You should be making maximum use of HTTP keep alive to minimize the number of new connections per unit time.
您不能忽略 SYN/ACK，因为它是 TCP 协议 3 次握手连接的一部分。在我看来，问题是服务器套接字没有正确打开。其他假设是服务器不可访问（例如防火墙阻止它）。
很难提供比不了解该程序更多的帮助。希望这有帮助！
编辑：检查您是否正确关闭了先前客户端的套接字。可能会发生先前的套接字未正确关闭并且操作系统达到允许打开的套接字的限制。在这种情况下，将发送 RST 数据包。
You can't ignore the SYN/ACK because it is part of the 3-way handshake connection for TCP protocol. It seems to me that the problem is the server socket not being correctly open. Other hypothesis is server not being accessible (firewall blocking it, for example).
It's hard to give more help than this not knowing the program. Hope this helps!
Edit: check if you are correctly closing the previous client's sockets. It can happen the previous sockets not being correctly closed and the OS reaches the limit of allowed open sockets. In that case, an RST packet is sent.