TCP的connect/accept返回时机及三次握手异常场景技术问询

针对你遇到的两个TCP连接异常场景，我结合TCP协议栈的实现细节来逐一解释：

一、::connect 的返回时机与异常原因 #

准确返回时机 #

不同操作系统的TCP栈实现略有差异：

• POSIX标准（如Linux）：严格遵循TCP三次握手流程，只有当客户端发送完第三次ACK（部分实现仅要求内核发出ACK，无需确认服务器接收），connect才会返回0（成功）。
• Windows系统：内核在收到服务器的SYN-ACK后，就会立即唤醒connect调用返回成功，同时由内核自动发送第三次ACK。这种设计是为了让应用层更快获取连接结果，无需等待ACK的发送确认。

为何会出现三次握手未完成却返回成功的情况 #

你遇到的场景正是Windows TCP栈的特性导致的：

1. 客户端调用connect后，内核发送SYN；
2. 收到服务器的SYN-ACK后，Windows内核直接让connect返回0；
3. 但此时内核可能因网络拥塞、系统资源不足等原因，没能成功发送第三次ACK；
4. 服务器端的连接状态仍停留在SYN_RECV（半连接状态），未进入ESTABLISHED；
5. 当你调用::send发送数据时，服务器发现无对应已建立连接，就会返回RST包，导致send返回WSAECONNRESET（10054）错误。

二、::accept 的返回时机与异常原因 #

准确返回时机 #

::accept的返回依赖于服务器的全连接队列（也叫accept队列）：

1. 三次握手完成后，服务器内核会将连接从半连接队列（SYN_RECV状态）转移到全连接队列（ESTABLISHED状态）；
2. accept函数会阻塞等待全连接队列中有可用连接，一旦有连接存在，就取出该连接并返回对应的套接字。

为何三次握手完成后::accept仍不返回 #

结合你“多个客户端几乎同时连接”的场景，最可能的原因是服务器全连接队列溢出：

1. 服务器调用listen时设置的backlog参数指定了全连接队列的最大长度；
2. 当大量客户端同时发起连接，全连接队列被占满后，新完成三次握手的连接会被服务器内核拒绝加入队列；
3. 此时服务器会向客户端发送RST包，但accept函数因全连接队列中无可用连接，会继续阻塞，不会返回INVALID_SOCKET（因为未发生函数调用层面的错误，只是队列为空）。

另外需要注意：部分操作系统的backlog参数实际生效值可能受系统内核参数限制（比如Linux下的tcp_max_syn_backlog），即使你设置了较大的backlog，实际队列长度可能达不到预期。

内容的提问来源于stack exchange，提问作者moog