「网络模型」IO多路复用
文章目录
- 「网络模型」IO多路复用
- @[toc]
- 一、概述
- 二、多路复用实现
- 三、监听FD的方式
- select
- poll
- epoll
- 底层实现
- 四、总结
- 参考
一、概述
定义
IO多路复用是一种同步IO模型，实现一个线程可以监视多个文件句柄；一旦某个文件句柄就绪，就能够通知应用程序进行相应的读写操作；没有文件句柄就绪时会阻塞应用程序，交出cpu。多路是指网络连接，复用指的是同一个线程。
为什么有IO多路复用机制?
没有IO多路复用机制时，有BIO、NIO两种实现方式，但有一些问题。
同步阻塞（BIO）
- 服务端采用单线程，当accept一个请求后，在recv或send调用阻塞时，将无法accept其他请求（必须等上一个请求处recv或send完），无法处理并发。
- 服务器端采用多线程，当accept一个请求后，开启线程进行recv，可以完成并发处理，但随着请求数增加需要增加系统线程，大量的线程占用很大的内存空间，并且线程切换会带来很大的开销，10000个线程真正发生读写事件的线程数不会超过20%，每次accept都开一个线程也是一种资源浪费。
同步非阻塞（NIO）
- 服务器端当accept一个请求后，加入fds集合，每次轮询一遍fds集合recv(非阻塞)数据，没有数据则立即返回错误，每次轮询所有fd（包括没有发生读写事件的fd）会很浪费cpu。
详细请看「网络模型」堵塞IO（BIO）与非堵塞IO（NIO）
IO多路复用（现在的做法）
- 服务器端采用单线程通过select/epoll等系统调用获取fd列表，遍历有事件的fd进行accept/recv/send，使其能支持更多的并发连接请求
文件描述符（File Descriptor）：简称FD，是一个从0 开始的无符号整数，用来关联Linux中的一个文件。在Linux中，一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字（Socket）。
二、多路复用实现
如果是阻塞IO也就是BIO，那么在一个fd（文件描述符）没有数据的时候，就是阻塞一直等待，如果同时有多个fd，对于单线程来说，只能一直等第一个有数据，然后再接着处理第二个，效率很慢。
就像顾客点餐，要一直等到第一个人点完餐，后面的人才有机会。BIO也有个解决办法，一般是增加多线程，每个线程都维护一个fd，就相当于为每个顾客都添加一个点餐台。在fd足够多的情况下，会有大量的线程被创建，线程可是有上限的，开销也大（更多线程需要更多的内存空间）。
如果是非阻塞IO也就是NIO，会有顾客没点完餐，然后造成CPU一直在询问一直空转的情况。
因此引入了IO多路复用模型:利用单个线程来同时监听多个FD,并在某个FD可读、可写时得到通知,从而避免无效的等待，充分利用CPU资源。
在Linux中，一切皆文件,例如常规文件、视频、硬件设备等，当然也包括网络套接字(Socket)。
这时候每来一个顾客（FD），我们就会给他一个开关（注册进监听事件），一个服务员（一个线程）等待开关亮起（阻塞等待事件）。有顾客完成，就会按下开关，一定的频率下开关会亮起（事件通知），服务员会选取按下开关的一批人，给他们点餐（批量处理事件）。
用IO复用模式，可以确保去读数据的时候，数据是一定存在的，他的效率比原来的阻塞IO和非阻塞IO性能都要高。
三、监听FD的方式
IO多路复用是利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。不过监听FD的方式、通知的方式又有多种实现，常见的有：
- select
- poll
- epoll
其中select和pool相当于是当被监听的数据准备好之后，他会把你监听的FD整个数据都发给你，你需要到整个FD中去找，哪些是处理好了的，需要通过遍历的方式，所以性能也并不是那么好。
而epoll，则相当于内核准备好了之后，他会把准备好的数据，直接发给你，咱们就省去了遍历的动作。
select
select是Linux最早是由的I/O多路复用技术：
select函数执行流程
-
用户空间创建fd_set，把需要监听的位置1，比如 1，2，5 -
用户空间拷贝fd_set（注册的事件集合）到内核空间 -
内核遍历所有fd文件，并将当前进程挂到每个fd的等待队列中，当某个fd文件设备收到消息后，会唤醒设备等待队列上睡眠的进程，那么当前进程就会被唤醒 -
内核如果遍历完所有的fd没有I/O事件，则当前进程进入睡眠，当有某个fd文件有I/O事件或当前进程睡眠超时后，当前进程重新唤醒再次遍历所有fd文件 -
内核有事件产生，会把fd_set中有事件的位置保留为1，没有事件的位置擦除为0. -
内核拷贝fd_set给用户空间 -
用户空间线程被唤醒，遍历fd_set为1的位置，确认是哪些fd有就绪事件，然后开始处理 -
用户空间处理完事件，再一次将要监听的fd_set设置为1，重复之前的监听动作
根据上面可以很清楚的看出整个执行流程在用户空间和内核空间的切换。
select函数的缺点
- 单个进程所打开的FD是有限制的，通过 FD_SETSIZE 设置，默认1024
- 每次调用 select，都需要把 fd 集合从用户态拷贝到内核态，这个开销在 fd 很多时会很大
- 每次调用select都需要将进程加入到所有监视socket的等待队列，每次唤醒都需要从每个队列中移除
- select函数在每次调用之前都要对参数进行重新设定，这样做比较麻烦，而且会降低性能
- 进程被唤醒后，程序并不知道哪些socket收到数据，还需要遍历一次
poll
poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态， 但是它没有最大连接数的限制，原因是它是基于链表来存储的
poll运行流程
1.创建pollfd数组， 向其中添加关注的fd信息，数组大小自定义
2.调用poll函数，将pollfd数组拷贝到内核空间，转链表存储，无上限
3.内核遍历fd,判断是否就绪
4.数据就绪或超时后，拷贝pollfd数组到用户空间，返回就绪fd数量n
5.用户进程判断n是否大于0
6.大于0则遍历pollfd数组,找到就绪的fd
与select对比
- select模式中的fd_ set大小固定为1024,而pollfd在内核中采用链表，理论上无上限.
- 监听FD越多，每次遍历消耗时间也越久，性能反而会下降
poll还是没有解决需要遍历判断fd事件的方式，只是增加了监听数量，在fd很多的情况下，性能下降的更加严重
epoll
epoll模式是对select和poll的改进，它提供了三个函数：
eventpoll函数
他内部包含两个东西
1、红黑树-> 记录的事要监听的FD
2、一个是链表->一个链表，记录的是就绪的FD
epoll_ctl函数
紧接着调用epoll_ctl操作，将要监听的数据添加到红黑树上去，并且给每个fd设置一个监听函数，这个函数会在fd数据就绪时触发，就是准备好了，现在就把fd把数据添加到list_head中去
epoll_wait
调用epoll_wait函数就去等待，在用户态创建一个空的events数组，当就绪之后，我们的回调函数会把数据添加到list_head中去，当调用这个函数的时候，会去检查list_head，当然这个过程需要参考配置的等待时间，可以等一定时间，也可以一直等， 如果在此过程中，检查到了list_head中有数据会将数据添加到链表中，此时将数据放入到events数组中，并且返回对应的操作的数量，用户态的此时收到响应后，从events中拿到对应准备好的数据的节点，再去调用方法去拿数据。
流程：
- 调用epoll_create创建一个eventpoll结构体
- 调用epoll_ctl向eventpoll中注册一个监听连接的serverSocket，并关联上处理accept事件的函数
- 调用epoll_wait阻塞等待fd事件（等待客户端连接）
- 用户程序被唤醒，事件到来（现在只有连接事件）。根据生成的客户端的FD，调用epoll_ctl注册一个监听，并且关联上处理read事件的函数和处理write事件的函数。
- 继续调用epoll_wait阻塞等待fd事件（等待客户端连接或客户端命令执行请求）
- 用户程序被唤醒，事件到来（连接事件或者命令执行请求），假设是客户端执行请求事件，根据客户端的fd对应的read事件直接调用绑定的回调函数来处理，将结果再写回到fd缓存中。
- 继续调用epoll_wait等待accept，read，write事件。
epoll优点
- EPOLL支持的最大文件描述符上限是整个系统最大可打开的文件数目, 1G内存理论上最大创建10万个文件描述符
- 每个文件描述符上都有一个callback函数，当socket有事件发生时会回调这个函数将该fd的引用添加到就绪列表中，select和poll并不会明确指出是哪些文件描述符就绪，而epoll会。造成的区别就是，系统调用返回后，调用select和poll的程序需要遍历监听的整个文件描述符找到是谁处于就绪，而epoll则直接处理即可
- select、poll采用轮询的方式来检查文件描述符是否处于就绪态，而epoll采用回调机制。造成的结果就是，随着fd的增加，select和poll的效率会线性降低，而epoll不会受到太大影响，除非活跃的socket很多
底层实现
当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。
eventpoll结构体如下所示：
struct eventpoll{
……
/* 红黑树根节点，这棵树中存储着所有添加到epoll中需要监控的事件 */
struct rb_root rbr;
/* 双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件 */
struct list_head rdlist;
……
};每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂在红黑树中，如此，重复添加的事件就可以通过红黑树高效标识出来（红黑树插入事件效率是lgn，其中n为树的高度）。
而所有添加到epoll中的事件都会与设备（网卡）驱动程序建立回调关系，也就是说，当相应的事件发生时，会调用这个回调方法。这个回调方法在内核中ep_poll_callback，它会将发生的事件添加到rdlist双向链表中。
在epoll中，每个事件都会建立一个epitem结构体，如下所示：
struct epitem{
// 红黑树节点
struct rb_node rbn;
// 双向链表节点
struct list_head rdlist;
// 事件句柄信息
struct epoll_filefd ffd;
// 指向其所属的eventpoll对象
struct eventpoll *ep;
// 期待发生的事件类型
struct epoll_event event;
}当调用epoll_wait方法检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双向链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件的数量返回给用户。
优势：
- **不用重复传递。**我们调用epoll_wait时候就相当于以前调用select/poll，但这时却不用传递socket文件句柄给内核，因为内核已经在epoll_ctl中拿到了要监控的文件句柄列表。
- **在内核里，一切皆文件。**所以，epoll向内核注册了一个文件系统，用于存储上述被监控socket。当你调用epoll_create时，就会在这个虚拟的epoll文件系统中创建一个file结点。当然这个file不是普通的文件，它只服务于epoll。
- **极其高效的原因。**这是由于我们在调用epoll_create时候，内核除了帮我们在epoll文件系统中创建了file结点，在内核cache里创建了个红黑树用于储存以后epoll_ctl传来的socket外，还会再建立一个list链表，用于存储准备就绪的事件，当epoll_wait调用时候，仅仅观察这个list链表有没有数据即可。如果有数据就立即返回，没有数据就sleep，等到timeout时候，即使list没有数据也返回。所以epoll_wait非常高效。
epoll在被内核初始化时（操作系统启动），同时会开辟出epoll自己的内核高速cache区，用于安置我们每一个想要监控的socket，这些socket会以红黑树的形式保存在内核cache里，以支持快速的查找、插入、删除。这个内核高速cache区，就是建立连续的物理内存页，然后在此之上建立slab层，简单的说，就是物理上分配好你想要的size内存对象，每次使用都是使用空闲的已经分配好的对象。
这个准备就绪的list链表是怎么维护的呢？
当我们执行epoll_ctl时，除了把socket放到epoll文件系统里file对象对应的红黑树上之外，还会给内核中断处理程序注册一个回调函数，告诉内核，如果这个句柄的中断到了，就把它放到准备就绪的list链表里。所以，当一个socket上有数据到了，内核再把网卡中的数据copy到内核中后，就把socket插入到准备就绪的链表里了。（备注：好好理解这句话）
从上面可以看出，epoll基础就是回调。
如此，一颗红黑树，一张准备就绪的句柄链表，少量的内核cache，就帮我们解决了高并发下的socket处理问题。
执行epoll_create时，创建了红黑树和就绪链表，执行epoll_ctl时，如果增加socket句柄，则检查红黑树中是否存在，存在就立即返回，不存在则添加进红黑树，然后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数据。执行epoll_wait时，立刻返回准备就绪链表里的数据即可。
四、总结
select模式存在的三个问题：
- 能监听的FD最大不超过1024
- 每次select都需要把所有要监听的FD都拷贝到内核空间
- 每次都要遍历所有FD来判断就绪状态
poll模式的问题：
- poll利用链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如果监听较多，性能会下降
epoll模式中如何解决这些问题的？
- 基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高
- 每个FD只需要执行一次epoll_ctl添加到红黑树，以后每次epol_wait无需传递任何参数，无需重复拷贝FD到内核空间
- 利用ep_poll_callback机制来监听FD状态，无需遍历所有FD，因此性能不会随监听的FD数量增多而下降
参考
程序员阿斌
黑马程序员
