网络框架的两种设计模式，无论操作系统的网络 I/O 模型的设计，还是上层网络框架的网络I/O模型的设计，用的都是这两种设计模式之一。

（1）Reactor模式：主动模式。

应用程序不断地轮询，询问操作系统或者网络框架、I/O是否就绪。Linux系统下的select、poll、epoll就属于主动模式，需要应用程序中有一个循环一直轮询；Java中的NIO也属于这种模式。在这种模式下，实际的I/O操作还是应用程序执行的。

（2）Proactor模式：被动模式。应用程序把read和write函数操作全部交给操作系统或者网络框架，实际的 I/O 操作由操作系统或网络框架完成，之后再回调应用程序。

asio 库就是典型的Proactor模式。“异步I/O”是Proactor模式。

select、epoll的LT与ET

1.select

（1）因为fd是一个int值，所以fd_set其实是一个bit数组，每1位表示一个fd是否有读事件或者写事件发生。

（2）第一个参数是readfds或者writefds的下标的最大值+1。因为fd从0开始，+1才表示个数。

（3）返回结果还在readfds和writefds里面，操作系统会重置所有的bit位，告知应用程序到底哪个fd上面有事件，应用程序需要自己从0到maxfds-1遍历所有的fd，然后执行相应的read/write操作。

（4）每次当select调用返回后，在下一次调用之前，要重新维护readfds和writefds。

select、poll每次调用都需要应用程序把fd的数组传进去，这个fd的数组每次都要在用户态和内核态之间传递，影响效率。为此，epoll设计了“逻辑上的epfd”。epfd是一个数字，把fd数组关联到上面，然后每次向内核传递的是epfd这个数字。

整个epoll的过程分成三个步骤：

（1）事件注册。通过函数epoll_ctl实现。对于服务器而言，是accept、read、write 三种事件；对于客户端而言，是connect、read、write 三种事件。

（2）轮询这三个事件是否就绪。通过函数epoll_wait实现。有事件发生，该函数返回。（3）事件就绪，执行实际的I/O操作。通过函数accept/read/write实现。这里要特别解释一下什么是“事件就绪”：

1）read事件就绪：远程有新数据来了，socket读取缓存区里有数据，需要调用read函数处理。

2）write事件就绪：是指本地的socket写缓冲区是否可写。如果写缓冲区没有满，则一直是可写的，write事件一直是就绪的，可以调用write函数。只有当遇到发送大文件的场景，socket写缓冲区被占满时，write事件才不是就绪状态。

3）accept事件就绪：有新的连接进入，需要调用accept函数处理。

epoll里面有两种模式：LT（水平触发）和ET（边缘触发）。

水平触发又称条件触发，边缘触发又称状态触发。

水平触发：读缓冲区只要不为空，就会一直触发读事件；写缓冲区只要不满，就会一直触发写事件。

边缘触发：读缓冲区的状态，从空转为非空的时候触发一次；写缓冲区的状态，从满转为非满的时候触发一次。

（1）对于 LT 模式，要避免“写的死循环”问题：写缓冲区为满的概率很小，即“写的条件”会一直满足，所以当用户注册了写事件却没有数据要写时，它会一直触发，因此在 LT 模式下写完数据一定要取消写事件。

（2）对于ET模式，要避免“short read”问题：例如用户收到100个字节，它触发1次，但用户只读到了50个字节，剩下的50个字节不读，它也不会再次触发。因此在ET模式下，一定要把“读缓冲区”的数据一次性读完。

在实际开发中，都倾向于用LT，这也是默认的模式，

Java NIO用的也是epoll的LT模式。因为ET容易漏事件，一次触发如果没有处理好，就没有第二次机会了。虽然LT重复触发可能有少许的性能损耗，但代码写起来更安全。