一文读懂 Linux 网络 IO 模型

1.从一个问题说起

互联网发展历史上，曾经有一个著名的问题：C10K 问题。

C 是 Client 单词首字母缩写，10K 指 1 万，C10K 指单机同时处理 1 万个并发连接问题。

C10K 问题最早是在 1999 年由 Dan Kegel 提出并发布于其个人站点（ http://www.kegel.com/c10k.html ）。

C10K 问题是一个优化网络套接字以同时处理大量客户端连接的问题。注意这里的并发连接和每秒请求数不同，虽然它们是相似的： 每秒处理许多请求需要很高的吞吐量（快速处理它们），但是更大的并发连接数需要高效的连接调度。

为了解决该问题，研究方向首先是网络 IO 模型的优化，具体的思路就是通过单个进程或线程服务于多个客户端请求，通过异步编程和事件触发机制替换轮询，IO 采用非阻塞的方式，减少不必要的性能损耗，等等。

现在已经解决了 C10K 的问题。 epoll、kqueue、iocp 就是 IO 模型优化的一些最佳实践，这几种技术实现分别对应于不同的系统平台。

epoll 主要用于 Linux 系统。使用一个文件描述符管理多个文件描述符的 I/O 事件。提供水平触发（Level Triggered）和边缘触发（Edge Triggered）两种模式。

kqueue 主要用于 BSD 系统，如 FreeBSD、OpenBSD 和 macOS。使用一个内核事件队列管理多个文件描述符的 I/O 事件。支持水平触发和边缘触发，也支持过滤器（Filter）概念，可以监控多种类型的事件。

iocp (Input/Output Completion Port) 主要用于 Windows 系统。使用 I/O 完成端口来实现异步 I/O 多路复用。异步 I/O 模型，采用回调方式，支持 OVERLAPPED 结构体。

2.多进程模型

如果服务器要支持多个客户端连接，其中比较传统的方式，就是使用多进程模型，也就是为每个客户端分配一个进程来处理请求。

服务器的主进程负责监听客户的连接，一旦与客户端连接完成，accept() 函数就会返回一个「已连接 Socket」，这时就通过 fork() 函数创建一个子进程，实际上把父进程所有相关的东西都复制一份，包括文件描述符、内存地址空间、程序计数器、执行的代码等。

这两个进程刚复制完的时候，几乎一摸一样。不过，会根据返回值来区分是父进程还是子进程，如果 fork() 返回值是 0，则是子进程；如果返回值是其他的整数，则是父进程。

正因为子进程会复制父进程的文件描述符，于是就可以直接使用「已连接 Socket 」和客户端通信了，可以发现，子进程不需要关心「监听 Socket」，只需要关心「已连接 Socket」；父进程则相反，将客户服务交给子进程来处理，因此父进程不需要关心「已连接 Socket」，只需要关心「监听 Socket」。

下面这张图描述了从连接请求到连接建立，父进程创建生子进程为客户服务。

另外，当「子进程」退出时，实际上内核里还会保留该进程的一些信息，也会占用内存，如果不做好“回收”工作，就会变成僵尸进程。随着僵尸进程越多，会慢慢耗尽系统资源。

因此，父进程要“善后”自己的孩子，怎么善后呢？那么有两种方式可以在子进程退出后回收资源，分别是调用 wait() 和 waitpid() 函数。

这种用多个进程来应付多个客户端的方式，在应对 100 个客户端还是可行的，但是当客户端数量高达一万时，肯定扛不住的，因为每产生一个进程，必会占据一定的系统资源，而且进程间上下文切换的“包袱”是很重的，性能会大打折扣。

进程的上下文切换涉及到保存和恢复大量的状态信息，不仅包含了虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的资源。

3.多线程模型

既然进程间上下文切换的“包袱”很重，那我们就搞个比较轻量级的模型来应对多用户的请求 —— 多线程模型。

线程是运行在进程中的一个“逻辑流”，单进程中可以运行多个线程，同一个进程里的线程可以共享进程的部分资源，比如地址空间（代码段、数据段和堆等）、文件描述符列表、共享库等，这些共享些资源在上下文切换时是不需要切换，而只需要切换线程的私有数据，比如寄存器、栈等不共享的数据，因此同一个进程下的线程上下文切换的开销要比进程小得多。

当服务器与客户端 TCP 完成连接后，通过 pthread_create() 函数创建线程，然后将「已连接 Socket」的文件描述符传递给线程函数，接着在线程里和客户端进行通信，从而达到并发处理的目的。

如果每来一个连接就创建一个线程，线程运行完后，还得操作系统销毁线程。虽说线程切换的上写文开销不大，但是如果频繁创建和销毁线程，系统开销也是不小的。

那么，我们可以使用线程池的方式来避免线程的频繁创建和销毁。所谓的线程池，就是提前创建若干个线程，这样当由新连接建立时，将这个已连接的 Socket 放入到一个队列里，然后线程池里的线程负责从队列中取出已连接 Socket 进行处理。

需要注意的是，这个队列是全局的，每个线程都会操作，为了避免多线程竞争，线程在操作这个队列前要加锁。

上面基于进程或者线程模型的，其实还是有问题的。新到来一个 TCP 连接，就需要分配一个进程或者线程，那么如果要达到 C10K，意味着要一台机器维护 1 万个连接，相当于要维护 1 万个进程/线程，操作系统就算死扛也是扛不住的。

4.I/O 多路复用

既然为每个请求分配一个进程/线程的方式不合适，那有没有可能只使用一个进程来维护多个 Socket 呢？

答案是有的，那就是 I/O 多路复用技术。

I/O 多路复用是通过一种机制（通常是系统调用）同时监视多个文件描述符（sockets、文件、设备等）的技术。它允许单个进程能够管理多个 I/O 操作，而不必为每个 I/O 操作创建一个单独的线程或进程。

I/O 多路复用的 “多路” 指的是多个 I/O 操作（通常是多个文件描述符），复用指使用一个进程来处理多个 I/O 操作。

Linux 下有三种提供 I/O 多路复用的 API，分别是： select、poll、epoll。

5.select、poll、epoll 的区别？

select、poll 和 epoll 都是 Linux 实现 IO 多路复用提供的系统调用，都能实现 C10K 吗？接下来，我们分别说说它们。

5.1 select

IO 多路复用这个概念被提出来以后， select 是第一个实现 （1983 左右在 BSD 里面实现）。

select 实现多路复用的方式是，将已连接的 Socket 都放到一个文件描述符集合，然后调用 select 函数将文件描述符集合拷贝到内核里，让内核来检查是否有网络事件产生，检查的方式很粗暴，就是通过遍历文件描述符集合的方式，当检查到有事件产生后，将此 Socket 标记为可读或可写， 接着再把整个文件描述符集合拷贝回用户态里，然后用户态还需要再通过遍历的方法找到可读或可写的 Socket，然后再对其处理。

所以，对于 select 这种方式，需要进行 2 次「遍历」文件描述符集合，一次是在内核态里，一个次是在用户态里 ，而且还会发生 2 次「拷贝」文件描述符集合，先从用户空间传入内核空间，由内核修改后，再传出到用户空间中。

select 使用固定长度的 BitsMap，表示文件描述符集合，而且所支持的文件描述符的个数是有限制的，在 Linux 系统中，由内核中的 FD_SETSIZE 限制， 默认最大值为 1024，只能监听 0~1023 的文件描述符。

select 被实现以后，很快暴露出了很多问题。

• select 只能监视 1024 个连接，Linux 定义在头文件中的，参见 FD_SETSIZE。
• 2 次「遍历」文件描述符集合，性能低下。
• 2 次「拷贝」文件描述符集合，性能低下。

5.2 poll

因为 select 的诸多问题，14 年后（1997年）一帮人又实现了 poll，修复了 select 的很多问题。

比如 poll 不再用 BitsMap 来存储所关注的文件描述符，取而代之用动态数组，以链表形式来组织，突破了 select 的文件描述符个数限制，当然还会受到系统文件描述符数量限制。

但是 poll 和 select 并没有太大的本质区别，都是使用「线性结构」存储进程关注的 Socket 集合，因此都需要遍历文件描述符集合来找到可读或可写的 Socket，时间复杂度为 O(n)，而且也需要在用户态与内核态之间拷贝文件描述符集合，这种方式随着并发数上来，性能的损耗会呈指数级增长。

5.3 epoll

于是 5 年以后（2002 年）, 大神 Davide Libenzi 实现了 epoll。

epoll 可以说是 IO 多路复用最新的一个实现，epoll 修复了 poll 和 select 绝大部分问题，比如：

（1）高效的数据结构。
epoll 在内核里使用红黑树跟踪进程所有待检测的文件描述符，把需要监控的 socket 通过 epoll_ctl() 函数加入内核中的红黑树里，红黑树是个高效的数据结构，增删查一般时间复杂度是 O(logn)，通过对这棵黑红树进行操作，这样就不需要像 select/poll 每次操作时都传入整个 socket 集合，只需要传入一个待检测的 socket，减少了内核和用户空间大量的数据拷贝和内存分配。

（2）使用事件驱动机制。
内核里维护了一个链表来记录就绪事件，当某个 socket 有事件发生时，通过回调函数内核会将其加入到这个就绪事件列表中，当用户调用 epoll_wait() 函数时，只会返回有事件发生的 socket，不需要像 select/poll 那样轮询扫描整个 socket 集合，大大提高了检测效率。

也就是 epoll 现在不仅告诉你 Socket 组里面数据，还会告诉你具体哪个 Socket 有数据，不用自己去找了。

从下图你可以看到 epoll 相关的接口作用：

epoll 监听的 Socket 数量越多，效率不会大幅度降低，能够同时监听的 Socket 的数目非常的多，上限为系统定义的进程打开的最大文件描述符个数。因而，epoll 被称为解决 C10K 问题的利器。

5.4 两种事件触发模式

epoll 支持两种事件触发模式，分别是边缘触发（edge-triggered，ET）和水平触发（level-triggered，LT）。

这两个术语还挺抽象的，其实它们的区别还是很好理解的。

• 使用边缘触发模式时，当被监控的 Socket 描述符上有可读事件发生时，服务器端只会从 epoll_wait 中苏醒一次，即使进程没有调用 read 函数从内核读取数据，也依然只苏醒一次，因此我们程序要保证一次性将内核缓冲区的数据读取完。
• 使用水平触发模式时，当被监控的 Socket 上有可读事件发生时，服务器端不断地从 epoll_wait 中苏醒，直到内核缓冲区数据被 read 函数读完才结束，目的是告诉我们有数据需要读取。

举个例子，你的快递被放到了一个快递箱里，如果快递箱只会通过短信通知你一次，即使你一直没有去取，它也不会再发送第二条短信提醒你，这个方式就是边缘触发；如果快递箱发现你的快递没有被取出，它就会不停地发短信通知你，直到你取出了快递，它才消停，这个就是水平触发的方式。

这就是两者的区别，水平触发的意思是只要满足事件的条件，比如内核中有数据需要读，就一直不断地把这个事件传递给用户；而边缘触发的意思是只有第一次满足条件的时候才触发，之后就不会再传递同样的事件了。

如果使用水平触发模式，当内核通知文件描述符可读写时，接下来还可以继续去检测它的状态，看它是否依然可读或可写。所以在收到通知后，没必要一次执行尽可能多的读写操作。

如果使用边缘触发模式，I/O 事件发生时只会通知一次，而且我们不知道到底能读写多少数据，所以在收到通知后应尽可能地读写数据，以免错失读写的机会。因此，我们会循环从文件描述符读写数据。如果文件描述符是阻塞的，没有数据可读写时，进程会阻塞在读写函数那里，程序就没办法继续往下执行。所以，边缘触发模式一般和非阻塞 I/O 搭配使用，程序会一直执行 I/O 操作，直到系统调用（如 read 和 write）返回错误，错误类型为 EAGAIN 或 EWOULDBLOCK。

一般来说，边缘触发的效率比水平触发的效率要高，因为边缘触发可以减少 epoll_wait 的系统调用次数，系统调用也有开销，毕竟也存在上下文的切换。

select/poll 只有水平触发模式，epoll 默认是水平触发，但可以根据应用场景设置为边缘触发模式。

---

参考文献

C10K 问题
程序员怎么会不知道C10K 问题呢？- Medium
I/O 多路复用：select/poll/epoll - 小林 coding
io-multiplexing(多路复用) - Colingo碎碎念