最值得推荐一看的文章
http://www.sohu.com/a/317847036_463994
1 I/O模型
首先回顾一下上节内容
unix有5种如下io模型:
- 阻塞式i/o
- 非阻塞式i/o
- i/o复用(select和poll)
- 信号驱动i/o
- 异步i/o
一个输入操作通常包括两个不同的阶段:
等待数据准备好;从内核向进程复制数据;
第一个通常涉及到等待数据从网络中到达.当所有等待分组到达时,它被复制到内核中的某个缓冲区,第二步就是把数据从内核缓冲区复制到应用进程缓冲区
2 C10K问题
2.1 什么是c10k问题？
主要参考：http://www.52im.net/thread-566-1-1.html
最初的服务器都是基于进程/线程模型的，新到来一个TCP连接，就需要分配1个进程（或者线程）。而进程又是操作系统最昂贵的资源，一台机器无法创建很多进程。如果是C10K就要创建1万个进程，那么单机而言操作系统是无法承受的（往往出现效率低下甚至完全瘫痪）。如果是采用分布式系统，维持1亿用户在线需要10万台服务器，成本巨大，也只有Facebook、Google、雅虎等巨头才有财力购买如此多的服务器。
基于上述考虑，如何突破单机性能局限，是高性能网络编程所必须要直面的问题。这些局限和问题最早被Dan Kegel 进行了归纳和总结，并首次成系统地分析和提出解决方案，后来这种普遍的网络现象和技术局限都被大家称为 C10K 问题。
C10K问题本质
C10K问题本质上是操作系统的问题。对于Web1.0/2.0时代的操作系统而言， 传统的同步阻塞I/O模型都是一样的，处理的方式都是requests per second，并发10K和100的区别关键在于CPU。
创建的进程线程多了，数据拷贝频繁（缓存I/O、内核将数据拷贝到用户进程空间、阻塞）， 进程/线程上下文切换消耗大， 导致操作系统崩溃，这就是C10K问题的本质！
解决C10K问题的关键就是尽可能减少这些CPU等核心计算资源消耗，从而榨干单台服务器的性能，突破C10K问题所描述的瓶颈。
2.2 c10k问题解决方案
要解决这一问题，从纯网络编程技术角度看，主要思路有两个：
- 一个是对于每个连接处理分配一个独立的进程/线程；
- 另一个思路是用同一进程/线程来同时处理若干连接。
- 思路一:每个进程/线程处理一个连接
这一思路最为直接。但是由于申请进程/线程会占用相当可观的系统资源，同时对于多进程/线程的管理会对系统造成压力，因此这种方案不具备良好的可扩展性。
因此，这一思路在服务器资源还没有富裕到足够程度的时候，是不可行的。即便资源足够富裕，效率也不够高。总之，此思路技术实现会使得资源占用过多，可扩展性差。
- 每个进程/线程同时处理多个连接（IO多路复用）
- 循环处理多个连接—
任何句柄不成功会阻塞整个应用; - select方案—
轮询文件句柄前先检查状态,仅处理ready—存在上限\连接数很多（文件句柄个数很多）的时候，逐个检查状态就很慢了 - poll方案 — 相对于select
1-去除了上限 2-使用不同字段分别分别标注关注事件和发生事件,避免重复初始化—轮询句柄状态仍然效率不高 - epoll方案 —
异步回调:- 调用返回的时候只给应用提供发生了状态变化（很可能是数据 ready）的文件句柄; –依赖特定平台linux
2 select和poll
select函数准许进程指示内核等待多个事件中的任何一个发送，并只在有一个或多个事件发生或经历一段指定的时间后才唤醒
poll的机制与select类似，与select在本质上没有多大差别，管理多个描述符也是进行轮询，根据描述符的状态进行处理，但是poll没有最大文件描述符数量的限制。poll和select同样存在一个缺点就是，包含大量文件描述符的数组被整体复制于用户态和内核的地址空间之间，而不论这些文件描述符是否就绪，它的开销随着文件描述符数量的增加而线性增大。
pollfd的结构体定义如下:
struct pollfd {
int fd; /* 文件描述符 */
short events; /* 等待的事件 */
short revents; /* 实际发生了的事件 */
} ;
2.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.2 poll
poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。
它没有最大连接数的限制，原因是它是基于链表来存储的，但是同样有一个缺点：
1、大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。
2、poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。
3 EPOLL
select和poll的低效原因是将维护等待队列和阻塞进程两个步骤合二为一，每次调用select都需要这两步操作：
- 调用 Select： 都需要将进程加入到所有监视 Socket 的等待队列
- 唤醒操作：当 Socket 收到数据后，中断程序会给 eventpoll 的“就绪列表”添加 Socket 引用。
Epoll则将两个操作分开，先用epoll_ctl来维护等待队列，在调用epoll_wait 来阻塞进程，如果有就绪通道则直接返回进行处理！这里有两个好处：
- 避免了每次重复维护等待队列
- 可由就绪列表直接返回，省去轮询所有socket的工作！
Epoll有两种工作模式：
- 水平触发（Level Triggered）
- 边缘触发（Edge Triggered）
LT（level triggered）是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表。
ET （edge-triggered）是高速工作方式，只支持non-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了（比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作（从而导致它再次变成未就绪），内核不会发送更多的通知（only once），不过在TCP协议中，ET模式的加速效用仍需要更多的benchmark确认。
ET和LT的区别就在这里体现，LT事件不会丢弃，而是只要读buffer里面有数据可以让用户读，则不断的通知你。而ET则只在事件发生之时通知。可以简单理解为LT是水平触发，而ET则为边缘触发。LT模式只要有事件未处理就会触发，而ET则只在高低电平变换时（即状态从1到0或者0到1）触发。
epoll的优点：
1、没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）；
2、效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数；
即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll。
3、 内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销。
select、poll、epoll 区别总结：
本文参考内容
https://www.cnblogs.com/yxmx/articles/1600736.html
https://www.cnblogs.com/aspirant/p/9166944.html
https://segmentfault.com/a/1190000003063859
http://www.52im.net/thread-566-1-1.html
转载：https://blog.csdn.net/xinquanv1/article/details/102489010