了解 epoll 的原理

nginx 相比 apache，在高并发情况下依然应付自如。

阻塞

TCP连接建立后，服务器等待客户消息到来。在大部分时间，客户是不活跃的。阻塞模型就只能等待，此时其他客户就无法进入。即便采用多线程，线程过多反而导致效率低下。

Select

一个线程建立多个连接（Windows最大为WSA_MAXIMUM_WAIT_EVENTS（64），Linux最大为1024），轮询这些连接（CPU都用来轮询了，所以这样理解的话还是阻塞的）。为了支持更多并发，也需要多线程，但这还是达不到百万并发。

Windows中的WSAAsyncSelect一种异步通知模型，当有消息到来时，系统通知对应窗口句柄。一个窗口句柄等待一个连接，效率可想而知。WSAEventSelect 则使用Event对象接收消息（即WSAWaitForMultipleEvents 方法，并阻塞），而且Event对象限制为WSA_MAXIMUM_WAIT_EVENTS（64）。

这里所谓异步，即数据IO由操作系统完成，再将结果返回给应用程序；同步IO：数据IO由程序去执行（这个过程中，由于CPU速度远快于其他速度，因此效率不高）

epoll

建立了大量连接后（系统使用红黑树+双链表以实现快速查询），当有事件到来时，系统在众多连接中找出对应的连接（O(lgN)）给用户处理。

综上所述，本来就应该直接出现epoll，其他种种不合理的模型貌似根本就没有存在的理由。而且epoll本身也不是太难。

epoll 或者 kqueue 的原理是什么？

高并发网络编程之epoll详解

epoll 

Linux 开发，使用多线程还是用 IO 复用 select/epoll？

epoll基本原理及使用框架