关于linux:说透IO多路复用模型

作者：京东批发石向阳

在说 IO 多路复用模型之前，咱们先来大抵理解下 Linux 文件系统。在 Linux 零碎中，不论是你的鼠标，键盘，还是打印机，甚至于连贯到本机的 socket client 端，都是以文件描述符的模式存在于零碎中，诸如此类，等等等等，所以能够这么说，所有皆文件。来看一下零碎定义的文件描述符阐明：

从下面的列表能够看到，文件描述符 0,1,2 都曾经被零碎占用了，当系统启动的时候，这三个描述符就存在了。其中 0 代表规范输出，1 代表规范输入，2 代表谬误输入。当咱们创立新的文件描述符的时候，就会在 2 的根底上进行递增。能够这么说，文件描述符是为了治理被关上的文件而创立的零碎索引，他代表了文件的身份 ID。对标 windows 的话，你能够认为和句柄相似，这样就更容易了解一些。

因为网上对 linux 文件这块的原理形容的文章曾经十分多了，所以这里我不再做过多的赘述，感兴趣的同学能够从 Wikipedia 翻阅一下。因为这块内容比较复杂，不属于本文遍及的内容，倡议读者另行自研，这里我十分举荐马士兵老师将 linux 文件系统这块，解说的真的十分好。

此模型是 IO 多路复用的最晚期应用的模型之一，距今曾经几十年了，然而当初仍旧有不少利用还在采纳此种形式，可见其长生不老。首先来看下其具体的定义（来源于 man 二类文档）：

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *errorfds, struct timeval *timeout);

这里解释下其具体参数：

参数一：nfds，也即 maxfd，最大的文件描述符递增一。这里之所以传最大描述符，为的就是在遍历 fd_set 的时候，限定遍历范畴。

参数二：readfds，可读文件描述符汇合。

参数三：writefds，可写文件描述符汇合。

参数四：errorfds，异样文件描述符汇合。

参数五：timeout，超时工夫。在这段时间内没有检测到描述符被触发，则返回。

上面的宏解决，能够对 fd_set 汇合（精确的说是 bitmap，一个描述符有变更，则会在描述符对应的索引处理 1）进行操作：

FD_CLR(inr fd,fd_set* set) 用来革除形容词组 set 中相干 fd 的位，即 bitmap 构造中索引值为 fd 的值置为 0。

FD_ISSET(int fd,fd_set *set) 用来测试形容词组 set 中相干 fd 的位是否为真，即 bitmap 构造中某一位是否为 1。

FD_SET（int fd,fd_set*set）用来设置形容词组 set 中相干 fd 的位，行将 bitmap 构造中某一位设置为 1，索引值为 fd。

FD_ZERO（fd_set *set）用来革除形容词组 set 的全副位，行将 bitmap 构造全副清零。

首先来看一段服务端采纳了 select 模型的示例代码：

// 创立 server 端套接字，获取文件描述符
    int listenfd = socket(PF_INET,SOCK_STREAM,0);
    if(listenfd < 0) return -1;
    // 绑定服务器
    bind(listenfd,(struct sockaddr*)&address,sizeof(address));
    // 监听服务器
    listen(listenfd,5); 
    struct sockaddr_in client;
    socklen_t addr_len = sizeof(client);
    // 接管客户端连贯
    int connfd = accept(listenfd,(struct sockaddr*)&client,&addr_len);
    // 读缓冲区
    char buff[1024]; 
    // 读文件操作符
    fd_set read_fds;  
    while(1)
    {memset(buff,0,sizeof(buff));
        // 留神：每次调用 select 之前都要从新设置文件描述符 connfd，因为文件描述符表会在内核中被批改
        FD_ZERO(&read_fds);
        FD_SET(connfd,&read_fds);
        // 留神：select 会将用户态中的文件描述符表放到内核中进行批改，内核批改结束后再返回给用户态，开销较大
        ret = select(connfd+1,&read_fds,NULL,NULL,NULL);
        if(ret < 0)
        {printf("Fail to select!\n");
            return -1;
        }
        // 检测文件描述符表中相干申请是否可读
        if(FD_ISSET(connfd, &read_fds))
        {ret = recv(connfd,buff,sizeof(buff)-1,0);
            printf("receive %d bytes from client: %s \n",ret,buff);
        }
    }

下面的代码我加了比拟具体的正文了，大家应该很容易看明确，说白了大略流程其实如下：

首先，创立 socket 套接字，创立结束后，会获取到此套接字的文件描述符。

而后，bind 到指定的地址进行监听 listen。这样，服务端就在特定的端口启动起来并进行监听了。

之后，利用开启 accept 办法来监听客户端的连贯申请。一旦有客户端连贯，则将获取到以后客户端连贯的 connection 文件描述符。

单方建设连贯之后，就能够进行数据互传了。须要留神的是，在循环开始的时候，务必每次都要从新设置以后 connection 的文件描述符，是因为文件描描述符表在内核中被批改过，如果不重置，将会导致异样的状况。

从新设置文件描述符后，就能够利用 select 函数从文件描述符表中，来轮询哪些文件描述符就绪了。此时零碎会将用户态的文件描述符表发送到内核态进行调整，行将准备就绪的文件描述符进行置位，而后再发送给用户态的利用中来。

用户通过 FD_ISSET 办法来轮询文件描述符，如果数据可读，则读取数据即可。

举个例子，假如此时连贯上来了 3 个客户端，connection 的文件描述符别离为 4,8,12，那么其 read_fds 文件描述符表（bitmap 构造）的大抵构造为 00010001000100000….0，因为 read_fds 文件描述符的长度为 1024 位，所以最多容许 1024 个连贯。

而在 select 的时候，波及到用户态和内核态的转换，所以整体转换形式如下：

所以，综合起来，select 整体还是比拟高效和稳固的，然而出现进去的问题也不少，这些问题进一步限度了其性能施展：

文件描述符表为 bitmap 构造，且有长度为 1024 的限度。
fdset 无奈做到重用，每次循环必须从新创立。
频繁的用户态和内核态拷贝，性能开销较大。
须要对文件描述符表进行遍历，O(n) 的轮询工夫复杂度。

思考到 select 模型的几个限度，起初进行了改良，这也就是 poll 模型，既然是 select 模型的改进版，那么必定有其亮眼的中央，一起来看看吧。当然，这次咱们仍旧是先翻阅 linux man 二类文档，因为这是官网的文档，对其有着最为精准的定义。

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

其实，从运行机制上说来，poll 所做的性能和 select 是基本上一样的，都是期待并检测一组文件描述符就绪，而后在进行后续的 IO 解决工作。只不过不同的是，select 中，采纳的是 bitmap 构造，长度限定在 1024 位的文件描述符表，而 poll 模型则采纳的是 pollfd 构造的数组 fds，也正是因为 poll 模型采纳了数组构造，则不会有 1024 长度限度，使其可能接受更高的并发。

pollfd 构造内容如下：

struct pollfd {
    int   fd;         /* 文件描述符 */
    short events;     /* 关怀的事件 */
    short revents;    /* 理论返回的事件 */
};

从下面的构造能够看出，fd 很显著就是指文件描述符，也就是当客户端连贯上来后，fd 会将生成的文件描述符保留到这里；而 events 则是指用户想关注的事件；revents 则是指理论返回的事件，是由零碎内核填充并返回，如果以后的 fd 文件描述符有状态变动，则 revents 的值就会有相应的变动。

events 事件列表如下：

revents 事件列表如下：

从列表中能够看出，revents 是蕴含 events 的。接下来联合示例来看一下：

// 创立 server 端套接字，获取文件描述符
    int listenfd = socket(PF_INET,SOCK_STREAM,0);
    if(listenfd < 0) return -1;
    // 绑定服务器
    bind(listenfd,(struct sockaddr*)&address,sizeof(address));
    // 监听服务器
    listen(listenfd,5); 
    struct pollfd pollfds[1];
    socklen_t addr_len = sizeof(client);
    // 接管客户端连贯
    int connfd = accept(listenfd,(struct sockaddr*)&client,&addr_len);
    // 放入 fd 数组
    pollfds[0].fd = connfd;
    pollfds[0].events = POLLIN;
    // 读缓冲区
    char buff[1024]; 
    // 读文件操作符
    fd_set read_fds;  
    while(1)
    {memset(buff,0,sizeof(buff));
        /**
         ** SELECT 模型专用
         ** 留神：每次调用 select 之前都要从新设置文件描述符 connfd，因为文件描述符表会在内核中被批改
         ** FD_ZERO(&read_fds);
         ** FD_SET(connfd,&read_fds);
        ** 留神：select 会将用户态中的文件描述符表放到内核中进行批改，内核批改结束后再返回给用户态，开销较大
        ** ret = select(connfd+1,&read_fds,NULL,NULL,NULL);
        **/
        ret = poll(pollfds, 1, 1000);
        if(ret < 0)
        {printf("Fail to poll!\n");
            return -1;
        }
        /**
         ** SELECT 模型专用
         ** 检测文件描述符表中相干申请是否可读
         ** if(FD_ISSET(connfd, &read_fds))
         ** {**   ret = recv(connfd,buff,sizeof(buff)-1,0);
         **   printf("receive %d bytes from client: %s \n",ret,buff);
         ** }
         **/
        // 检测文件描述符数组中相干申请
        if(pollfds[0].revents & POLLIN){pollfds[0].revents = 0;
            ret = recv(connfd,buff,sizeof(buff)-1,0);
            printf("receive %d bytes from client: %s \n",ret,buff);
        }
    }

因为源码中，我做了比拟具体的正文，同时将和 select 模型不一样的中央都列了进去，这里就不再具体解释了。总体说来，poll 模型比 select 模型要好用一些，去掉了一些限度，然而依然防止不了如下的问题：

用户态和内核态仍须要频繁切换，因为 revents 的赋值是在内核态进行的，而后再推送到用户态，和 select 相似，整体开销较大。
仍须要遍历数组，工夫复杂度为 O（N）。

如果说 select 模型和 poll 模型是晚期的产物，在性能上有诸多不尽人意之处，那么自 linux 2.6 之后新增的 epoll 模型，则彻底解决了性能问题，一举使得单机接受百万并发的课题变得极为容易。当初能够这么说，只须要一些简略的设置更改，而后配合上 epoll 的性能，实现单机百万并发轻而易举。同时，因为 epoll 整体的优化，使得之前的几个比拟消耗性能的问题不再成为羁绊，所以也成为了 linux 平台上进行网络通讯的首选模型。

解说之前，还是 linux man 文档镇楼：linux man epoll 4 类文档 linux man epoll 7 类文档，俩文档联合着读，会对 epoll 有个大略的理解。和之前提到的 select 和 poll 不同的是，此二者皆属于零碎调用函数，然而 epoll 则不然，他是存在于内核中的数据结构，能够通过 epoll_create，epoll_ctl 及 epoll_wait 三个函数联合来对此数据结构进行操控。

说道 epoll_create 函数，其作用是在内核中创立一个 epoll 数据结构实例，而后将返回此实例在零碎中的文件描述符。此 epoll 数据结构的组成其实是一个链表构造，咱们称之为 interest list，外面会注册连贯上来的 client 的文件描述符。

其简化工作机制如下：

说道 epoll_ctl 函数，其作用则是对 epoll 实例进行增删改查操作。有些相似咱们罕用的 CRUD 操作。这个函数操作的对象其实就是 epoll 数据结构，当有新的 client 连贯上来的时候，他会将此 client 注册到 epoll 中的 interest list 中，此操作通过附加 EPOLL_CTL_ADD 标记来实现；当已有的 client 掉线或者被动下线的时候，他会将下线的 client 从 epoll 的 interest list 中移除，此操作通过附加 EPOLL_CTL_DEL 标记来实现；当有 client 的文件描述符有变更的时候，他会将 events 中的对应的文件描述符进行更新，此操作通过附加 EPOLL_CTL_MOD 来实现；当 interest list 中有 client 曾经筹备好了，能够进行 IO 操作的时候，他会将这些 clients 拿进去，而后放到一个新的 ready list 外面。

其简化工作机制如下：

说道 epoll_wait 函数，其作用就是扫描 ready list，解决准备就绪的 client IO，其返回后果即为筹备好进行 IO 的 client 的个数。通过遍历这些筹备好的 client，就能够轻松进行 IO 解决了。

下面这三个函数是 epoll 操作的根本函数，然而，想要彻底了解 epoll，则须要先理解这三块内容，即：inode，链表，红黑树。

在 linux 内核中，针对以后关上的文件，有一个 open file table，外面记录的是所有关上的文件描述符信息；同时也有一个 inode table，外面则记录的是底层的文件描述符信息。这里如果文件描述符 B fork 了文件描述符 A，尽管在 open file table 中，咱们看新增了一个文件描述符 B，然而实际上，在 inode table 中，A 和 B 的底层是截然不同的。这里，将 inode table 中的内容了解为 windows 中的文件属性，会更加贴切和易懂。这样存储的益处就是，无论下层文件描述符怎么变动，因为 epoll 监控的数据永远是 inode table 的底层数据，那么我就能够始终可能监控到文件的各种变动信息，这也是 epoll 高效的根底。更多详细信息，请参阅这两篇文章：Nonblocking IO & The method to epoll’s madness.

简化流程如下：

数据存储这块解决了，那么针对连贯上来的客户端 socket，该用什么数据结构保留进来呢？这里用到了红黑树，因为客户端 socket 会有频繁的新增和删除操作，而红黑树这块工夫复杂度仅仅为 O(logN)，还是挺高效的。有人会问为啥不必哈希表呢？当大量的连贯频繁的进行接入或者断开的时候，扩容或者其余行为将会产生不少的 rehash 操作，而且还要思考哈希抵触的状况。尽管查问速度确实能够达到 o(1)，然而 rehash 或者哈希抵触是不可控的，所以基于这些考量，我认为红黑树占优一些。

客户端 socket 怎么治理这块解决了，接下来，当有 socket 有数据须要进行读写事件处理的时候，零碎会将曾经就绪的 socket 增加到双向链表中，而后通过 epoll_wait 办法检测的时候，其实查看的就是这个双向链表，因为链表中都是就绪的数据，所以防止了针对整个客户端 socket 列表进行遍历的状况，使得整体效率大大晋升。整体的操作流程为：

首先，利用 epoll_create 在内核中创立一个 epoll 对象。其实这个 epoll 对象，就是一个能够存储客户端连贯的数据结构。

而后，客户端 socket 连贯上来，会通过 epoll_ctl 操作将后果增加到 epoll 对象的红黑树数据结构中。

而后，一旦有 socket 有事件产生，则会通过回调函数将其增加到 ready list 双向链表中。

最初，epoll_wait 会遍历链表来解决曾经筹备好的 socket，而后通过事后设置的程度触发或者边缘触发来进行数据的感知操作。

从下面的细节能够看出，因为 epoll 外部监控的是底层的文件描述符信息，能够将变更的描述符间接退出到 ready list，无需用户将所有的描述符再进行传入。同时因为 epoll_wait 扫描的是曾经就绪的文件描述符，防止了很多有效的遍历查问，使得 epoll 的整体性能大大晋升，能够说当初只有议论 linux 平台的 IO 多路复用，epoll 曾经成为了不二之选。

下面说到了 epoll，次要解说了 client 端怎么连进来，然而并未具体的解说 epoll_wait 怎么被唤醒的，这里我未来具体的解说一下。

程度触发，意即 Level Trigger，边缘触发，意即 Edge Trigger，如果单从字面意思上了解，则不太容易，然而如果将硬件设计中的程度沿，回升沿，降落沿的概念引进来，则了解起来就容易多了。比方咱们能够这样认为：

如果将上图中的方块看做是 buffer 的话，那么了解起来则就更加容易了，比方针对程度触发，buffer 只有是始终有数据，则始终告诉；而边缘触发，则 buffer 容量发生变化的时候，才会告诉。尽管能够这样简略的了解，然而实际上，其细节解决局部，比图示中展示的更加精密，这里来具体的说一下。

边缘触发

针对读操作，也就是以后 fd 处于 EPOLLIN 模式下，即可读。此时意味着有新的数据到来，接收缓冲区可读，以下 buffer 都指接收缓冲区：

buffer 由空变为非空，意即有数据进来的时候，此过程会触发告诉。

buffer 本来有些数据，这时候又有新数据进来的时候，数据变多，此过程会触发告诉。

buffer 中有数据，此时用户对操作的 fd 注册 EPOLL_CTL_MOD 事件的时候，会触发告诉。

针对写操作，也就是以后 fd 处于 EPOLLOUT 模式下，即可写。此时意味着缓冲区能够写了，以下 buffer 都指发送缓冲区：

buffer 满了，这时候发送进来一些数据，数据变少，此过程会触发告诉。

buffer 本来有些数据，这时候又发送进来一些数据，数据变少，此过程会触发告诉。

这里就是 ET 这种模式触发的几种情景，能够看出，基本上都是围绕着接收缓冲区或者发送缓冲区的状态变动来进行的。

艰涩难懂？不存在的，举个栗子：

在服务端，咱们开启边缘触发模式，而后将 buffer size 设为 10 个字节，来看看具体的表现形式。

服务端开启，客户端连贯，发送单字符 A 到服务端，输入后果如下：

-->ET Mode: it was triggered once

get 1 bytes of content: A

-->wait to read!

能够看到，因为 buffer 从空到非空，边缘触发告诉产生，之后在 epoll_wait 处阻塞，持续期待后续事件。

这里咱们变一下，输出 ABCDEFGHIJKLMNOPQ，能够看到，客户端发送的字符长度超过了服务端 buffer size，那么输入后果将是怎么样的呢？

-->ET Mode: it was triggered once

get 9 bytes of content: ABCDEFGHI

get 8 bytes of content: JKLMNOPQ

-->wait to read!

能够看到，这次发送，因为发送的长度大于 buffer size，所以内容被折成两段进行接管，因为用了边缘触发形式，buffer 的状况是从空到非空，所以只会产生一次告诉。

程度触发

程度触发则简略多了，他蕴含了边缘触发的所有场景，简而言之如下：

当接收缓冲区不为空的时候，有数据可读，则读事件会始终触发。

当发送缓冲区未满的时候，能够持续写入数据，则写事件始终会触发。

同样的，为了使表白更清晰，咱们也来举个栗子，依照上述入输出形式来进行。

服务端开启，客户端连贯并发送单字符 A，能够看到服务端输入状况如下：

-->LT Mode: it was triggered once!

get 1 bytes of content: A

这个输入后果，毋庸置疑，因为 buffer 中有数据，所以程度模式触发，输入了后果。

服务端开启，客户端连贯并发送 ABCDEFGHIJKLMNOPQ，能够看到服务端输入状况如下：

-->LT Mode: it was triggered once!

get 9 bytes of content: ABCDEFGHI

-->LT Mode: it was triggered once!

get 8 bytes of content: JKLMNOPQ

从后果中，能够看出，因为 buffer 中数据读取结束后，还有未读完的数据，所以程度模式会始终触发，这也是为啥这里程度模式被触发了两次的起因。

有了这两个栗子的比对，不晓得聪慧的你，get 到二者的区别了吗？

在理论开发过程中，实际上 LT 更易用一些，毕竟零碎帮忙咱们做了大部分校验告诉工作，之前提到的 SELECT 和 POLL，默认采纳的也都是这个。然而须要留神的是，当有成千上万个客户端连贯上来开始进行数据发送，因为 LT 的个性，内核会频繁的解决告诉操作，导致其绝对于 ET 来说，比拟的消耗系统资源，所以，随着客户端的增多，其性能也就越差。

而边缘触发，因为监控的是 FD 的状态变动，所以整体的零碎告诉并没有那么频繁，高并发下整体的性能体现也要好很多。然而因为此模式下，用户须要踊跃的解决好每一笔数据，带来的保护代价也是相当大的，略微不留神就有可能出错。所以应用起来须要十分小心才行。

至于二者如何抉择，诸位就仁者见仁智者见智吧。

行文到这里，对于 epoll 的解说基本上结束了，大家从中是不是学到了很多干货呢？因为从 netty 钻研到 linux epoll 底层，其难度十分大，能够用曲高和寡来形容，所以在这块摸索的文章是比拟少的，很多货色须要本人照着 man 文档和源码一点一点的推敲（linux 源码详见 eventpoll.c 等）。这里我来纠正一下搜索引擎上，说 epoll 高性能是因为利用 mmap 技术实现了用户态和内核态的内存共享，所以性能好，我后期被这个观点误导了良久，起初下来了 linux 源码，翻了一下，并没有在 epoll 中翻到 mmap 的技术点，所以这个观点是谬误的。这些错误观点的文章，国内不少，国外也不少，心愿大家能审慎抉择，防止被谬误带偏。

所以，epoll 高性能的根本就是，其高效的文件描述符解决形式加上颇具个性边的缘触发解决模式，以极少的内核态和用户态的切换，实现了真正意义上的高并发。

作者：京东批发 石向阳

select 模型

poll 模型

epoll 模型

程度触发和边缘触发

边缘触发

程度触发

作者：京东批发石向阳