TCP套接字的connect（）是否阻塞？

Question

嗨，我正在阅读TLPI（Linux编程接口），我对connect（）有疑问。

据我了解，如果listen（）的挂起连接数未达到“积压”，则connect（）将立即返回。 否则它将阻止。 （根据图56-2）

但是对于TCP套接字，它将始终阻塞，直到调用服务器端的accept（）为止（根据图61-5）。

我对么？ 因为我在示例代码（p.1265）中看到了它，所以它调用listen（）侦听特定端口，然后在调用accept（）之前将connect（）调用到该端口。

因此，在这种情况下，connect（）会永远阻塞，不是吗？

谢谢！！

Answer 1

几乎没有关于网络的“立即”信息，途中会丢失任何东西，并且理论上应立即执行的操作在实践中可能不会这样做，并且在任何情况下都存在端到端的传输时间。

然而

• 除非套接字描述符进入非阻塞模式，否则TCP套接字上的connect（）是阻塞操作。

• 操作系统负责TCP握手，握手完成后，connect（）返回。 （也就是说，connect（）直到另一端调用accept（）时才阻塞）

• 成功的TCP握手将排队到服务器应用程序，以后可以随时接受（）。

Answer 2

默认情况下， connect是一个阻止调用，但是您可以通过将SOCK_NONBLOCK标志传递给套接字来使其SOCK_NONBLOCK非阻止。

Answer 3

connect（）块，直到完成TCP 3向握手。 侦听端的握手由内核中的TCP / IP堆栈处理，并且在不通知用户进程的情况下完成。 仅在握手完成之后（并且发起方可以从connect（）调用返回），用户进程中的accept（）才能选择新的套接字并返回。 完成握手不需要等待的accept（）。

原因很简单：如果您有一个单线程进程正在监听连接，并且需要等待accept（）建立连接，那么您在处理另一个请求时就无法响应TCP ​​SYN。 发起方的TCP堆栈将重传，但是在中等负载的服务器上，重传的数据包的机会很高，而没有accept（）挂起的情况下仍然会到达，并且将再次丢弃，从而导致难看的延迟和连接超时。