connect()是否阻止TCP套接字？

Question

嗨,我正在阅读TLPI(Linux编程接口),我有一个关于connect()的问题.

据我所知,如果listen()的挂起连接数没有达到"backlog",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() 阻塞直到完成 TCP 3 次握手。侦听端的握手由内核中的 TCP/IP 堆栈处理，并在不通知用户进程的情况下完成。只有在握手完成后（并且发起者已经可以从 connect() 调用返回），用户进程中的 accept() 才能拿起新的套接字并返回。无需等待 accept() 即可完成握手。

原因很简单：如果您有单线程进程侦听连接并需要等待 accept() 来建立连接，则在处理另一个请求时无法响应 TCP SYN。发起端的 TCP 堆栈将重新传输，但在中等负载的服务器上，此重新传输的数据包仍然会到达，而没有 accept() 挂起并再次被丢弃，从而导致丑陋的延迟和连接超时。