【Linux I/O复用】不同类型的Socket是否需要设置为非阻塞的总结---Epoll中ET和LT的选择

首先需要强调的是：
一个Socket是否设置为阻塞模式只会影响connect、accept、send、recv这四个常用函数，
不会影响select、poll、epoll、bind、listen

一般在网络编程中有三种Socket:

服务端监听用的Socket — listenfd;

服务端accept建立连接时返回的Socket — connfd；

客户端connect请求建立连接的Connent返回的Socket — clientfd；

1对于Listenfd而言

1.1没有使用I/O复用模型的select、poll、epoll

listenfd可以设置为阻塞，此时程序会阻塞在while(1){...accept()...}上，一直阻塞到成功建立连接或者超时或者中断等；

listenfd也可以设置为非阻塞，此时需要处理非阻塞返回的信号：EWOULDBLOCK，实现非阻塞accept —一些情况下必须使用非阻塞的listenfd来实现非阻塞accept，否则会造成阻塞：

返回listenfd可读,不过从返回到执行accept需要经过一小段时间。
在等待accept期间，服务器tcp收到客户端的rst(对端直接close 且 so_linger l_onoff = 1 l_linger = 0 时关闭直接发送rst)。
已完成的链接被服务器TCP驱除出队列，且没有新的链接达到。
服务器代码运行到accept，会阻塞到下一个新的链接到达。

因此建议使用非阻塞。

1.2若使用了I/O复用模型的select、poll、epoll

此时listenfd是否为阻塞并不影响select、poll、epoll，因为这三个函数返回的listenfd是可以直接accept并立即返回的，所以listenfd是否设置为阻塞效果一样。

但依然建议使用非阻塞。

因为除了1.1中提到的客户端可能突然发送RST外，阻塞的listenfd还可能发生一些问题：

在listenfd为阻塞时，一次只处理一个accept建立一个连接，速度太慢，若是在循环中进行accept又有可能阻塞accept，因为listenfd本身是阻塞的，不确定是否有新的连接到来进而会阻塞accept。

1.2.1Epoll中listenfd的LT和ET选择的问题

一般而言，仅使用Epoll接口时使用LT比较好，因为ET在高并发的时候可能导致部分客户端连接不上。

在Epoll反应堆模型中就按照反应堆模型的来了，上ET。

2.对于Connfd而言

在阻塞时，若没法进行send则会阻塞到可以发送或者超时为止；若没收到数据recv会阻塞到收到或者超时为止。

在非阻塞时，send和recv总是会立即返回，此时可以实现非阻塞忙轮询。

2.1Epoll中connfd的LT和ET选择的问题

可以选择LT或者ET。

ET更高效，要求connfd非阻塞且一次性完整读写全部数据，开发难度更高。因为此时若connfd为阻塞则会导致程序卡在recv上，while循环没法继续进而卡死。

LT时则阻塞和非阻塞效果一致，建议使用非阻塞。

3.对于Clientfd而言

阻塞时会一直阻塞到成功或超时或出错

非阻塞时总会立刻返回且并不保证连接是否建立成功，此时需要getsockopt判断socket是否有效，用select或poll判断socket是否可写，即实现非阻塞connect。