常见的网络通信模型都会使用IO多路复用技术如select
、poll
、epoll
等。当有新的连接请求到来时,监听套接字变为可读,然后调用accept()
接收新连接、返回一个连接套接字。
如果监听套接字是阻塞的,问题可能出在什么地方?
先来看下TCP三次握手的示意图:
从图中可知,connect()
会先于accep()
函数返回。
当一个连接到来的时候,监听套接字可读,此时,我们稍微等一段时间之后再调用accept()
。就在这段时间内,客户端设置linger选项(l_onoff = 1, l_linger = 0),然后调用了close()
,那么客户端将不经过四次挥手过程,通过发送RST报文断开连接。服务端接收到RST报文,系统会将排队的这个未完成连接直接删除,此时就相当于没有任何的连接请求到来, 而接着调用的accept()
将会被阻塞,直到另外的新连接到来时才会返回。这是与IO多路复用的思想相违背的(系统不阻塞在某个具体的IO操作上,而是阻塞在select
、poll
、epoll
这些IO复用上的)。
上述这种情况下,如果监听套接字为非阻塞的,accept()不会阻塞住,立即返回-1,同时errno = EWOULDBLOCK。
具体示例可参考UNP 16.6节 非阻塞accept。