socket编程中的阻塞和非阻塞 以及 I/O复用总结
一、阻塞及非阻塞
阻塞：一般的I/O操作可以在新建的流中运用.在服务器回应前它等待客户端发送一个空白的行.当会话结束时,服务器关闭流和客户端socket.如果在队列中没有请示将会出现什么情况呢?那个方法将会等待一个的到来.这个行为叫阻塞.accept()方法将会阻塞服务器线程直到一个呼叫到来.当5个连接处理完闭之后,服务器退出.任何的在队列中的呼叫将会被取消.
非阻塞：非阻塞套接字是指执行此套接字的网络调用时，不管是否执行成功，都立即返回。比如调用recv()函数读取网络缓冲区中数据，不管是否读到数据都立即返回，而不会一直挂在此函数调用上。在实际Windows网络通信软件开发中，异步非阻塞套接字是用的最多的。平常所说的C/S（客户端/服务器）结构的软件就是异步非阻塞模式的。
具体机制就是上面所说的，简明扼要的来说可以打个比方：
你有数个同学来访 <---> 有若干数据需要收取
你时不时的去门口看看，没有看到你同学的话就回客厅等待，看到同学就接到客厅来 <---> 非阻塞模式，无论收到数据与否都返回
你一直在门口等着你同学，接到后才回客厅 <---> 阻塞模式，接收到数据后才返回
二、socket套接字的阻塞
套接字有两种模式，阻塞模式与非阻塞模式。默认创建的为阻塞模式.
阻塞套接字在IO时阻塞应用程序，就是说控制权不会返回给应用程序，也就是说程序执行到此代码时会卡住。分两种情况
1.send时,只有把要发送的数据下传至TCP层，send这句代码才继续向下执行，此时可确认自己的数据已经在网络上传输了
2.recv时，只有收到一定数据给应用程序缓冲区时,recv这行代码才会向下执行。如果不想这样做，可以使用多线程，或者选用其他网络IO模型。 一般在做服务器程序时，不会使用阻塞套接字，性能低，数据吞吐率也不高。优点是此种模型编写难度较低，可以用来做入门的学习之用。
非阻塞的套接字，IO会马上返回.
在send时，如果SOCKET缓冲区已满，会返回错误，使用WSAGetLastError会得到错误码为WSAEWOULDBLOCK,意思是说在一个非阻塞的套接字上，请求没有完成。recv时如果SOCKET缓冲区没有可以读的数据，也会返回WSAEWOULDBLOCK.
三、 Socket 的模式大概分为这么几种：
1、阻塞式的，Socket操作都需要将线程挂起，等待内核完成后才能返回。
如: 调用connect=>进入内核=>Syn包=〉服务器返回SYN ACK 包=〉connect返回 =〉ACK包发往服务器。
但一般来说，阻塞和非阻塞对于recv来说意义更大。当在阻塞式的Socket上调用recv时，如果这时网络栈上没有数据给你接收，那么这时线程将
会挂起，直到有报文给你接收才返回。这样就造成你的应用程序在企图接收数据时候，而网络栈上没有数据的时候就会被锁住。
当使用socket()函数创建套接字时，默认的套接字都是阻塞的。这意味着当调用 Sockets API不能立即完成时，线程处于等待状态，直到操作完成。
当使用socket()函数和WSASocket()函数创建套接字时，默认的套接字都是阻塞的。这意味着当调用Windows Sockets API不能立即完成时，线程处于等待状态，直到操作完成。
并不是所有Windows Sockets API以阻塞套接字为参数调用都会发生阻塞。例如，以阻塞模式的套接字为参数调用bind()、listen()函数时，函数会立即返回。将可能阻塞套接字的Windows Sockets API调用分为以下四种:
(1).输入操作： recv()、recvfrom()、WSARecv()和WSARecvfrom()函数。以阻塞套接字为参数调用该函数接收数据。如果此时套接字缓冲区内没有数据可读，则调用线程在数据到来前一直睡眠。
(2).输出操作： send()、sendto()、WSASend()和WSASendto()函数。以阻塞套接字为参数调用该函数发送数据。如果套接字缓冲区没有可用空间，线程会一直睡眠，直到有空间。
(3).接受连接：accept()和WSAAcept()函数。以阻塞套接字为参数调用该函数，等待接受对方的连接请求。如果此时没有连接请求，线程就会进入睡眠状态。
(4).外出连接：connect()和WSAConnect()函数。对于TCP连接，客户端以阻塞套接字为参数，调用该函数向服务器发起连接。该函数在收到服务器的应答前，不会返回。这意味着TCP连接总会等待至少到服务器的一次往返时间。
有什么办法解决这个问题呢？
(1).阻塞模式给网络编程带来了一个很大的问题，如在调用 send()的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。这给多客户机、多业务逻辑的网络编程带来了挑战。这时，我们可能会选择多线程的方式来解决这个问题。 应对多客户机的网络应用，最简单的解决方式是在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。
(2).调用函数及I/O复用技术
2、非阻塞socket
非阻塞IO通过进程反复调用IO函数（多次系统调用，并马上返回）；在数据拷贝的过程中，进程是阻塞的；
把SOCKET设置为非阻塞模式，即通知系统内核：在调用 Sockets API时，不要让线程睡眠，而应该让函数立即返回。在返回时，该函数返回一个错误代码。图所示，一个非阻塞模式套接字多次调用recv()函数的过程。前三次调用recv()函数时，内核数据还没有准备好。因此，该函数立即返回WSAEWOULDBLOCK错误代码。第四次调用recv()函数时，数据已经准备好，被复制到应用程序的缓冲区中，recv()函数返回成功指示，应用程序开始处理数据。
调用函数设置非阻塞socket方法
当使用socket()函数创建套接字时，默认都是阻塞的。
方法一:fcntl函数
int flag;
if (flag = fcntl(fd, F_GETFL, 0) <0) perror("get flag");
flag |= O_NONBLOCK;
if (fcntl(fd, F_SETFL, flag) < 0)
perror("set flag");
方法二：ioctl函数
int b_on = 1;
ioctl (fd, FIONBIO, &b_on);
备注：在socket编程中使用：fcntl(sockfd,F_SETFL,O_NONBLOCK)；会把sockfd设定为非阻塞模式，则之后的connect、accept、recv、recvfrom等函数便失去了阻塞功能，变成了非阻塞函数。
3.I/O复用技术
简介：主要是select和epoll；对一个IO端口，两次调用，两次返回，比阻塞IO并没有什么优越性；关键是能实现同时对多个IO端口进行监听；而之前只是实现了一个客户端对一个服务器，其实它的本质也是阻塞socket，一般会与fcntl一起使用，建立多用户的非阻塞通讯
I/O复用典型使用场合：
1) 服务器同时处理多个客户套接字请求；
2) 服务器既要处理监听套接字，又要处理已连接套接字；
3) 服务器既要处理TCP，又要处理UDP；
4) 服务器处理多个协议；
I/O复用模型会用到select、poll、epoll函数，这几个函数也会使进程阻塞，但是和阻塞I/O所不同的的，这两个函数可以同时阻塞多个I/O操作。而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操作函数。
epoll跟select都能提供多路I/O复用的解决方案。在现在的Linux内核里有都能够支持，其中epoll是Linux所特有，而select则应该是POSIX所规定，一般操作系统均有实现
（1）select：
select本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。这样所带来的缺点是：
1)、 单个进程可监视的fd数量被限制，即能监听端口的大小有限。
一般来说这个数目和系统内存关系很大，具体数目可以cat /proc/sys/fs/file-max察看。32位机默认是1024个。64位机默认是2048.
2)、 对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低：
当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。
3)、需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大
(2).poll：
poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。
它没有最大连接数的限制，原因是它是基于链表来存储的，但是同样有一个缺点：
1)、大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义
2)、poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。
(3).epoll:
epoll支持水平触发和边缘触发，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就需态，并且只会通知一次。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知
epoll的优点：
2)、效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数；
即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll。
LT和ET工作模式
LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表．
ET(edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once),不过在TCP协议中，ET模式的加速效用仍需要更多的benchmark确认（这句话不理解）。
1、支持一个进程所能打开的最大连接数
| select | 单个进程所能打开的最大连接数有FD_SETSIZE宏定义，其大小是32个整数的大小（在32位的机器上，大小就是32*32，同理64位机器上FD_SETSIZE为32*64），当然我们可以对进行修改，然后重新编译内核，但是性能可能会受到影响，这需要进一步的测试。 |
| poll | poll本质上和select没有区别，但是它没有最大连接数的限制，原因是它是基于链表来存储的 |
| epoll | 虽然连接数有上限，但是很大，1G内存的机器上可以打开10万左右的连接，2G内存的机器可以打开20万左右的连接 |
2、FD剧增后带来的IO效率问题
| select | 因为每次调用时都会对连接进行线性遍历，所以随着FD的增加会造成遍历速度慢的“线性下降性能问题”。 |
| poll | 同上 |
| epoll | 因为epoll内核中实现是根据每个fd上的callback函数来实现的，只有活跃的socket才会主动调用callback，所以在活跃socket较少的情况下，使用epoll没有前面两者的线性下降的性能问题，但是所有socket都很活跃的情况下，可能会有性能问题。 |
3、 消息传递方式
| select | 内核需要将消息传递到用户空间，都需要内核拷贝动作 |
| poll | 同上 |
| epoll | epoll通过内核和用户空间共享一块内存来实现的。 |
总结：
综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特点。
1、表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。
2、select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善
1169
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
