给定一个从客户端到服务器的tcp连接，是否在不显式调用accept的情况下解决第二个问题？

Question

如果我的术语非常基础，请提前道歉：

我正在与建立与服务器的TCP连接的客户端一起工作。 客户端的套接字是非阻塞的，因此在调用connect() ，客户端将等待套接字变为可写状态。

在accept()从客户端建立连接后，服务器将执行阻止操作（将其称为功能X），并且长时间不返回到accept()处的阻止。

在服务器被占用并执行功能X的这段时间中，客户端再次使用无阻塞套接字（与第一个连接使用的套接字不同connect()对同一服务器执行另一个connect() ），然后等待套接字在其中可写为了将tcp连接视为“已建立”。

我天真地希望第二个套接字保持不可写状态，直到服务器第二次调用accept()来接受该第二个连接。 但是我观察到的情况并非如此：第二个套接字很快就可写，因此客户端再次将这个新的TCP连接视为“已建立”。

这是预期的吗？

从这个问题的评论中，我（非常宽松地）理解，在执行TCP握手期间，位于tcp连接中间的非阻塞套接字将保持不可写状态-是这样吗？ 这是否与上述问题有关？ 是否类似： 如果存在从客户端到服务器的现有tcp连接，则从该相同客户端到该服务器的后续tcp连接将立即/迅速“解析”（套接字变为可写状态，而服务器无需显式执行第二次连接accept ）？

我试过了

我尝试编写一个单元测试来模拟这种情况，其中一个线程用于在同一台PC上运行的客户端和服务器，每个线程一个，但是我认为这不是一种有效的测试方法：根据此问答，我认为客户端和服务器是否在同一台上PC，“ TCP握手”与两台单独的PC并不完全相同，例如，客户端的连接套接字变得可写，而服务器甚至没有侦听 接受连接的情况。

Answer 1

每个connect()需要一个相应的accept() ，以便客户端和服务器相互通信。

但是，有可能/有可能​​在连接仍在服务器的待办事项中时，在accept()为它创建新套接字之前/完成了三向TCP握手。 握手完成后，“建立” connect() ，即使在服务器端尚未accept()连接，也将在客户端完成connect()操作。

请参阅Linux中的TCP积压工作原理