C++ socket非阻塞模式

一、前言

初期学习socket的时候，为了方便理解，使用默认的阻塞模式比较多。而实际做项目时，我们必须考虑程序的并发性，非阻塞模式在其中担任着很重要的角色，是必会的点之一。本文不对阻塞IO和非阻塞IO的概念做说明，不了解的请自行了解。下文代码以linux平台为例。

二、设置非阻塞模式

设置非阻塞模式，通过fcntl方法设置，为了保存socket其他设置，一般选择先获取 status flags, 并在其基础上设置O_NONBLOCK属性， 代码如下：

fcntl失败返回值为-1, 同时errno会被设置成对应的错误码。（errno在此不做说明，不了解的自行了解。） 考虑失败的情况，个人注意到网上有些例子（包括ss-libev项目）在 F_GETFL 失败后，给了flags默认值，代码如下：

经过测试，默认情况下，flags得到的值为2，也就是O_RDWR 读写， 而 0 对应的相关宏为O_RDONLY只读，明显不合理。个人感觉，对于一个正常的socket来说，F_GETFL 出错的机会不大吧， 至少我是没遇到过。如果实在出错了，还是建议走错误流程而不是给个默认值。

三、 非阻塞server

server端通常在accept后，我们为客户端连接的fd设置为非阻塞。设置O_NONBLOCK后，recv和send发生了变化。默认阻塞模式下，recv在没有数据可以接收(对方未发数据，或者缓冲区的数据已读完对方没有继续发)情况下，recv会阻塞等待，直到下次有数据发送过来。而非阻塞模式下，recv在没有数据可以接收的时候， recv会直接返回-1, 同时errno会被设置为EAGAIN/EWOULDBLOCK 。同理，非阻塞send也会在对方缓冲区满的情况下直接返回-1并设置errno， 而不是阻塞等待。 非阻塞模式下server代码大致如下：

四、非阻塞client

client除了在send/recv， 还可以在connect前设置非阻塞模式，这样在connect时候可以直接返回。

client 非阻塞connect的时候，如果返回0表示连接成功，如果返回-1, 则需要判断errno 是否为EINPROGRESS，EINPROGRESS表示非阻塞连接不能立刻获取connect结果，后面可使用select/poll/epoll等对socket 可写性进行判断，如果socket已可写，使用 getsockopt(iSocket, SOL_SOCKET, SO_ERROR ,&err, &len)进行判断。。。好像挺麻烦是不是，但是我还是建议在大部分项目中connect前设置非阻塞(小工具之类的就无所谓了，项目中一定要保证效率)。如果使用阻塞模式，有可能的问题：

下面是个非阻塞connect的部分代码, 使用select, 至于poll/epoll请自行搜索代码，跟非阻塞逻辑无关:

1. 设置socket

int oldOption = fcntl(sockfd, F_GETFL)

int newOption = oldOption | O_NONBLOCK

//设置sockfd非阻塞

fcntl(sockfd, F_SETFL, newOption)12345

2. 执行connect

如果返回0，表示连接成功，这种情况一般在本机上连接时会出现(否则怎么可能那么快)

否则，查看error是否等于EINPROGRESS(表明正在进行连接中)，如果不等于，则连接失败

int ret = connect(sockfd, (struct sockaddr*)&addr, sizeof(addr))

if(ret == 0)

{

//连接成功

fcntl(sockfd, F_SETFL, oldOption)

return sockfd

}

else if(errno != EINPROGRESS)

{

//连接没有立即返回，此时errno若不是EINPROGRESS，表明错误

perror("connect error != EINPROGRESS")

return -1

}12345678910111213141516

3. 使用select，如果没用过select可以去看看

用select对socket的读写进行监听

那么监听结果有四种可能

1. 可写(当连接成功后，sockfd就会处于可写状态，此时表示连接成功)

2. 可读可写(在出错后，sockfd会处于可读可写状态，但有一种特殊情况见第三条)

3. 可读可写(我们可以想象，在我们connect执行完到select开始监听的这段时间内，

如果连接已经成功，并且服务端发送了数据，那么此时sockfd就是可读可写的，

因此我们需要对这种情况特殊判断)

说白了，在可读可写时，我们需要甄别此时是否已经连接成功，我们采用这种方案：

再次执行connect，然后查看error是否等于EISCONN(表示已经连接到该套接字)。

4. 错误

if(FD_ISSET(sockfd, &writeFds))

{

//可读可写有两种可能，一是连接错误，二是在连接后服务端已有数据传来

if(FD_ISSET(sockfd, &readFds))

{

if(connect(sockfd, (struct sockaddr*)&addr, sizeof(addr)) != 0)

{

int error=0

socklen_t length = sizeof(errno)

//调用getsockopt来获取并清除sockfd上的错误.

if(getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &error, &length) <0)

{

printf("get socket option failed\n")

close(sockfd)

return -1

}

if(error != EISCONN)

{

perror("connect error != EISCONN")

close(sockfd)

return -1

}

}

}

//此时已排除所有错误可能，表明连接成功

fcntl(sockfd, F_SETFL, oldOption)

return sockfd

}12345678910111213141516171819202122232425262728293031323334353637383940

4. 恢复socket

因为我们只是需要将连接 *** 作变为非阻塞，并不包括读写等，所以我们吃醋要将socket重新设置。

fcntl(sockfd, F_SETFL, oldOption)关于Linux命令的介绍，看看《linux就该这么学》，具体关于这一章地址3w(dot)linuxprobe/chapter-02(dot)html

理解Linux的IO模型之前，首先要了解一些基本概念，才能理解这些IO模型设计的依据

*** 作系统使用虚拟内存来映射物理内存，对于32位的 *** 作系统来说，虚拟地址空间为4G（2^32）。 *** 作系统的核心是内核，为了保护用户进程不能直接 *** 作内核，保证内核安全， *** 作系统将虚拟地址空间划分为内核空间和用户空间。内核可以访问全部的地址空间，拥有访问底层硬件设备的权限，普通的应用程序需要访问硬件设备必须通过 系统调用 来实现。

对于Linux系统来说，将虚拟内存的最高1G字节的空间作为内核空间仅供内核使用，低3G字节的空间供用户进程使用，称为用户空间。

又被称为标准I/O，大多数文件系统的默认I/O都是缓存I/O。在Linux系统的缓存I/O机制中， *** 作系统会将I/O的数据缓存在页缓存（内存）中，也就是数据先被拷贝到内核的缓冲区（内核地址空间），然后才会从内核缓冲区拷贝到应用程序的缓冲区（用户地址空间）。

这种方式很明显的缺点就是数据传输过程中需要再应用程序地址空间和内核空间进行多次数据拷贝 *** 作，这些 *** 作带来的CPU以及内存的开销是非常大的。

由于Linux系统采用的缓存I/O模式，对于一次I/O访问，以读 *** 作举例，数据先会被拷贝到内核缓冲区，然后才会从内核缓冲区拷贝到应用程序的缓存区，当一个read系统调用发生的时候，会经历两个阶段：

正是因为这两个状态，Linux系统才产生了多种不同的网络I/O模式的方案

Linux系统默认情况下所有socke都是blocking的，一个读 *** 作流程如下：

以UDP socket为例，当用户进程调用了recvfrom系统调用，如果数据还没准备好，应用进程被阻塞，内核直到数据到来且将数据从内核缓冲区拷贝到了应用进程缓冲区，然后向用户进程返回结果，用户进程才解除block状态，重新运行起来。

阻塞模行下只是阻塞了当前的应用进程，其他进程还可以执行，不消耗CPU时间，CPU的利用率较高。

Linux可以设置socket为非阻塞的，非阻塞模式下执行一个读 *** 作流程如下：

当用户进程发出recvfrom系统调用时，如果kernel中的数据还没准备好，recvfrom会立即返回一个error结果，不会阻塞用户进程，用户进程收到error时知道数据还没准备好，过一会再调用recvfrom，直到kernel中的数据准备好了，内核就立即将数据拷贝到用户内存然后返回ok，这个过程需要用户进程去轮询内核数据是否准备好。

非阻塞模型下由于要处理更多的系统调用，因此CPU利用率比较低。

应用进程使用sigaction系统调用，内核立即返回，等到kernel数据准备好时会给用户进程发送一个信号，告诉用户进程可以进行IO *** 作了，然后用户进程再调用IO系统调用如recvfrom，将数据从内核缓冲区拷贝到应用进程。流程如下：

相比于轮询的方式，不需要多次系统调用轮询，信号驱动IO的CPU利用率更高。

异步IO模型与其他模型最大的区别是，异步IO在系统调用返回的时候所有 *** 作都已经完成，应用进程既不需要等待数据准备，也不需要在数据到来后等待数据从内核缓冲区拷贝到用户缓冲区，流程如下：

在数据拷贝完成后，kernel会给用户进程发送一个信号告诉其read *** 作完成了。

是用select、poll等待数据，可以等待多个socket中的任一个变为可读，这一过程会被阻塞，当某个套接字数据到来时返回，之后再用recvfrom系统调用把数据从内核缓存区复制到用户进程，流程如下：

流程类似阻塞IO，甚至比阻塞IO更差，多使用了一个系统调用，但是IO多路复用最大的特点是让单个进程能同时处理多个IO事件的能力，又被称为事件驱动IO，相比于多线程模型，IO复用模型不需要线程的创建、切换、销毁，系统开销更小，适合高并发的场景。

select是IO多路复用模型的一种实现，当select函数返回后可以通过轮询fdset来找到就绪的socket。

优点是几乎所有平台都支持，缺点在于能够监听的fd数量有限，Linux系统上一般为1024，是写死在宏定义中的，要修改需要重新编译内核。而且每次都要把所有的fd在用户空间和内核空间拷贝，这个 *** 作是比较耗时的。

poll和select基本相同，不同的是poll没有最大fd数量限制（实际也会受到物理资源的限制，因为系统的fd数量是有限的），而且提供了更多的时间类型。

总结：select和poll都需要在返回后通过轮询的方式检查就绪的socket，事实上同时连的大量socket在一个时刻只有很少的处于就绪状态，因此随着监视的描述符数量的变多，其性能也会逐渐下降。

epoll是select和poll的改进版本，更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

epoll_create()用来创建一个epoll句柄。

epoll_ctl() 用于向内核注册新的描述符或者是改变某个文件描述符的状态。已注册的描述符在内核中会被维护在一棵红黑树上，通过回调函数内核会将 I/O 准备好的描述符加入到一个就绪链表中管理。

epoll_wait() 可以从就绪链表中得到事件完成的描述符，因此进程不需要通过轮询来获得事件完成的描述符。

当epoll_wait检测到描述符IO事件发生并且通知给应用程序时，应用程序可以不立即处理该事件，下次调用epoll_wait还会再次通知该事件，支持block和nonblocking socket。

当epoll_wait检测到描述符IO事件发生并且通知给应用程序时，应用程序需要立即处理该事件，如果不立即处理，下次调用epoll_wait不会再次通知该事件。

ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用nonblocking socket，以避免由于一个文件句柄的阻塞读/阻塞写 *** 作把处理多个文件描述符的任务饿死。

【segmentfault】 Linux IO模式及 select、poll、epoll详解

【GitHub】 CyC2018/CS-Notes

---