首先需要强调的是：
一个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。
