一文读懂 Linux 网络 IO 模型_linux iocp

1.C10K 问题

在说网络 IO 之前，先聊一下互联网发展历史上，曾经著名的 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 使用固定长度的 Bitmap，表示文件描述符集合，而且所支持的文件描述符的个数是有限制的，在 Linux 系统中，由内核中的 FD_SETSIZE 限制， 默认最大值为 1024，只能监听 0~1023 的文件描述符。

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

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

5.2 poll

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

比如 poll 不再用 Bitmap 来存储所关注的文件描述符，取而代之用动态数组，以链表形式来组织，突破了 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）使用事件驱动机制。

采用事件驱动，避免了 select 和 poll 中的轮询开销，只在发生事件时通知应用程序，减少无效遍历。

（3）使用就绪链表。

内核里维护了一个双向链表来记录就绪事件。当某个 socket 有事件发生时，通过回调函数内核会将其加入到这个就绪事件列表。当用户调用 epoll_wait() 函数时，只会返回有事件发生的 socket，不像 select/poll 那样，需要用户程序再次描整个 socket 集合，大大提高了检测效率。

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

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

5.4 两种事件触发模式

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

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

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

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

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

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

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

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

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

6.epoll 的使用

当使用 epoll 进行事件驱动的高效网络 IO 编程时，一般会涉及三个主要的系统调用：epoll_create、epoll_ctl 和 epoll_wait。

epoll_create

epoll_create() 函数用于创建并初始化一个 eventpoll 对象。

int epoll_create(int size);
1

参数 size 指定了 epoll 实例的大小，即该实例可以同时监视的文件描述符数量上限。这个参数在 Linux 2.6.8 之后已经被忽略，所以可以将其设置为任何正整数。通常可以将其设置为一个较大的值，以便应对大量文件描述符。

struct eventpoll {
    spinlock_t lock;  			// 自旋锁，保护对该结构的访问
    struct mutex mtx; 			// 这个互斥锁用于确保epoll使用文件时文件不会被删除
    wait_queue_head_t wq; 		// 调用 epoll_wait() 等待事件到来的进程队列
    wait_queue_head_t poll_wait;// 另一个等待队列。当被监视的文件是一个 epoll 类型时，需要用这个等待队列来处理递归唤醒
    struct list_head rdllist;   // 就绪的文件描述符列表
    struct rb_root rbr;			// 红黑树的根用来存储受监控的fd结构
    struct epitem *ovflist; 	// 临时收集新事件的 epitem 链表
    struct wakeup_source *ws;	// 当 ep_scan_ready_list 运行时使用的唤醒源
    struct user_struct *user;   // 创建 eventpoll 描述符的用户
    struct file *file;			// 用于指向与事件相关的文件对象

    // 用于优化环路检测
    int visited;				
    struct list_head visited_list_link;
};
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

epoll_ctl

通过 epoll_ctl() 函数把被监听的文件描述符（如 socket 对象）封装成 epitem 对象，然后添加到 eventpoll 对象的红黑树中进行管理。此外，还需要设置关注的事件类型（如可读、可写等）。

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
1

epfd 为使用 epoll_create 系统调用创建的 epoll 实例。

fd 为待添加、修改或删除的文件描述符。

op 表示操作类型，添加（EPOLL_CTL_ADD）、修改（EPOLL_CTL_MOD）和删除（EPOLL_CTL_DEL）。

event 指针表示文件描述符关注的事件。

相关数据结构如下：

struct epoll_event {
    uint32_t events;    // 表示关注的事件，可以是 EPOLLIN、EPOLLOUT、EPOLLERR 等
    epoll_data_t data;  // 用户数据，可以是一个指针，用于关联用户自定义数据
};

typedef union epoll_data {
    void *ptr;
    int fd;
    uint32_t u32;
    uint64_t u64;
} epoll_data_t;

struct epitem {
	struct rb_node rbn;			// 红黑树节点用于将该结构链接到 eventpoll RB 树
	struct list_head rdllink;	// 将此结构链接到 eventpoll 就绪链表的链表头
	struct epitem *next;		// 与“struct eventpoll”->ovflist 一起工作构成单链表
	struct epoll_filefd ffd;	// 该项所指的文件描述符信息
	int nwait;					// 附加到轮询操作的活动等待队列的数量
	struct list_head pwqlist;	// 轮询等待队列的列表
	struct eventpoll *ep;		// 该项所属的 eventpoll
	struct list_head fllink;	// 用于将此结构链接到“struct file”链表的链表头
	struct wakeup_source *ws;	// 设置 EPOLLWAKEUP 时使用的唤醒源
	struct epoll_event event;	// 描述感兴趣的事件和源 fd 的结构
};
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

epoll_wait

通过 epoll_wait() 阻塞当前进程，直到指定的 eventpoll 实例上有事件发生，或者超时。

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);
1

epfd 是通过 epoll_create() 创建的 epoll 实例。

events 是一个指向 epoll_event 结构数组的指针，用于存储发生的事件信息：发生事件的文件描述符和事件类型等信息。

maxevents 是 events 数组的大小，即最多可以存储多少个事件。

timeout 是等待超时时间，单位是毫秒。如果 timeout 为正数，表示等待指定的毫秒数；如果 timeout 为 0，表示立即返回；如果 timeout 为负数，表示一直阻塞直到有事件发生。

epoll_wait() 成功时返回发生事件的文件描述符的数量，失败时返回-1，并设置 errno 来指示错误类型。

当被监听的文件状态发生改变时（如 socket 接收到数据）会把文件句柄对应 epitem 对象添加到 eventpoll 对象的就绪队列 rdllist 中。并且把就绪队列的文件列表复制到 events 参数中。最后操作系统会唤醒调用 epoll_wait() 被阻塞（睡眠）的线程。

一下是一个简单示例，演示了如何使用 epoll 监视一个 socket 上的可读事件：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/epoll.h>

#define MAX_EVENTS 10
#define BUF_SIZE 1024

int main() {
    int epoll_fd, nfds, n;
    struct epoll_event event, events[MAX_EVENTS];
    char buf[BUF_SIZE];

    // 创建 epoll 实例
    epoll_fd = epoll_create(1);
    if (epoll_fd == -1) {
        perror("epoll_create");
        exit(EXIT_FAILURE);
    }

    // 添加文件描述符到 epoll 实例
    event.events = EPOLLIN;
    event.data.fd = STDIN_FILENO; // 监视标准输入
    if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, STDIN_FILENO, &event) == -1) {
        perror("epoll_ctl");
        exit(EXIT_FAILURE);
    }

    // 等待事件
    while (1) {
        nfds = epoll_wait(epoll_fd, events, MAX_EVENTS, -1);
        if (nfds == -1) {
            perror("epoll_wait");
            exit(EXIT_FAILURE);
        }

        // 处理事件
        for (n = 0; n < nfds; ++n) {
            if (events[n].data.fd == STDIN_FILENO) {
                // 从标准输入读取数据
                ssize_t bytes_read = read(STDIN_FILENO, buf, BUF_SIZE);
                if (bytes_read == -1) {
                    perror("read");
                    exit(EXIT_FAILURE);
                }
                printf("Read %zd bytes: %.*s\n", bytes_read, (int)bytes_read, buf);
            }
        }
    }

    return 0;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

---

参考文献

C10K 问题
程序员怎么会不知道C10K 问题呢？- Medium
I/O 多路复用：select/poll/epoll - 小林 coding
io-multiplexing(多路复用) - Colingo碎碎念
epoll_create(2) - Linux manual page
十个问题理解Linux epoll工作原理 - 腾讯云