从 epoll 到 io_uring：Linux 网络异步 I/O 的范式转移与深度实战

Linux 网络编程在过去二十年间经历了从 select 到 poll 再到 epoll 的演进，epoll 以其 O(1) 事件通知和边缘/水平触发模式，成为 Nginx、Redis、Node.js 等高性能网络框架的基石。然而，当连接数突破千万级、延迟进入微秒级竞争时，epoll 模型中那些曾经被忽略的"小开销"逐渐汇聚成了不可忽视的性能瓶颈。

io_uring 的出现，将 Linux 异步 I/O 带入了一个全新的时代。它不仅仅是一个新的系统调用接口，更是一种重新设计的内核-用户态通信范式。本文将深入分析 epoll 模型在网络场景下的固有局限，阐述 io_uring 如何在网络异步 I/O 领域实现范式转移，并通过完整的 C 代码实战展示如何基于 liburing 构建一个高性能 TCP 服务器。

epoll 的瓶颈：被"高效"遮蔽的真相

epoll 的核心设计思路是事件驱动：注册关注的文件描述符，当内核检测到就绪事件时通知用户态程序处理。这比 select/poll 的轮询方式确实高效得多，但仔细审视其在网络 I/O 中的工作方式，会发现几个结构性问题。

每次 I/O 都是一次系统调用

一个典型的 epoll-based 网络服务器处理一个 TCP 连接的数据时，流程是这样的：调用 epoll_wait() 等待事件，获得可读事件后调用 recv()，处理完数据后调用 send()。这意味着每处理一个连接至少需要三次跨越用户态-内核态的上下文切换。在高并发场景下，千万级连接意味着每秒数千万次的系统调用开销。虽然单次系统调用的纳秒级开销看似微小，但当它与 CPU 流水线冲刷、TLB 失效、安全隔离边界检查（Spectre/Meltdown 缓解措施）叠加时，累积效应变得显著。

半异步半阻塞的尴尬

epoll 模型中，epoll_wait() 本身是阻塞的（或设置超时），recv() 和 send() 如果工作在阻塞模式下更是会阻塞整个事件循环。虽然可以通过设置 O_NONBLOCK 标志让 socket 变成非阻塞模式，但这引入了复杂的部分读写（partial read/write）处理逻辑。更关键的是，即使 socket 被设置为非阻塞，当内核发送缓冲区满时，send() 仍然会立即返回 EAGAIN，用户态程序需要自行管理发送缓冲区和重试逻辑，这增加了代码复杂度和状态机维护成本。

固定大小的事件数组

epoll_wait() 需要预先分配一个固定大小的事件数组来接收就绪事件。在高并发场景下，如果一瞬间有数千个连接同时就绪，单次调用可能无法处理完所有事件。这就带来了"惊群效应"和事件饥饿问题——活跃连接可能持续获得处理机会，而新建立的连接因为事件数组已满而被延迟处理。

io_uring 的范式：从"通知型"到"提交-完成型"

io_uring（通常读作 "eye-oh you-ring"）由 Jens Axboe 于 2019 年提出并在 Linux 5.1 中引入，它的核心思想极其优雅：通过两个共享在内核和用户态之间的环形缓冲区（ring buffer）来完全消除系统调用的提交和收割开销。

双环形缓冲区架构

io_uring 使用两个环形缓冲区：

• Submission Queue（SQ）：用户态将 I/O 请求（Submission Queue Entry, SQE）写入 SQ，内核从 SQ 中消费请求。只有当 SQ 满或用户显式调用 io_uring_enter() 时，才会触发系统调用来通知内核有新请求。
• Completion Queue（CQ）：内核将完成事件（Completion Queue Entry, CQE）写入 CQ，用户态程序从 CQ 中读取结果。与 SQ 类似，内核可以通过 IORING_SETUP_SQPOLL 模式在后台轮询 SQ，完全免去用户态的系统调用。

这种设计的精妙之处在于：用户态程序可以在一个循环中批量提交多个 SQE，然后只需一次 io_uring_enter() 就能通知内核。同样，一次 io_uring_enter() 调用可以收割数十甚至上百个 CQE，极大地摊薄了系统调用的固定开销。

真正的异步网络 I/O

与 epoll 的"通知-响应"模式不同，io_uring 提供的是真正的异步 I/O 原语。当你提交一个 IORING_OP_READ（对应 recv）操作时，io_uring 会在内核侧完成从 socket 缓冲区到用户缓冲区的数据拷贝，然后通过 CQE 通知你"数据已经就绪"。整个过程不需要你参与数据拷贝，也不需要调用任何系统调用来触发 I/O。

更强大的是，io_uring 支持链接操作（linked operations）：你可以将 recv() 和 send() 串联在一起，告诉内核"读完这个数据后直接发送到另一个 socket"。这种零拷贝转发模式在高性能代理和负载均衡器中极具价值。

内核轮询模式的威力

IORING_SETUP_SQPOLL 模式让 io_uring 的性能优势进一步放大。在该模式下，io_uring 会创建一个内核线程持续轮询 SQ。当用户态程序写入新的 SQE 后，根本不需要调用任何系统调用，内核线程会自动发现并执行这些请求。同样，完成事件会被内核线程自动写入 CQ，用户态程序只需在需要时读取即可。

这种模式下的 I/O 路径从"用户态调用 syscall → 内核处理 → 返回用户态"变成了"用户态写入内存 → 内核轮询线程读取内存 → 内核处理 → 写入完成队列 → 用户态读取内存"。系统调用开销被彻底消除，延迟的确定性大幅提升。

代码实战：基于 liburing 的高性能 TCP Echo Server

接下来，我们通过一个完整的 TCP Echo Server 来展示 io_uring 在网络编程中的实际应用。这个服务器将使用 IORING_SETUP_SQPOLL 模式，实现完全无系统调用的 I/O 处理。

项目结构与依赖

首先，我们需要安装 liburing 库。在 Ubuntu/Debian 系统上：

sudo apt-get install liburing-dev

编译我们即将编写的服务器：

gcc -o uring_echo_server uring_echo_server.c -luring -O2

完整实现代码

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <liburing.h>

#define MAX_CONNECTIONS  4096
#define BUF_SIZE         2048
#define BUF_GROUP_ID     0
#define ENTER_TIMEOUT_MS 1_000
#define BACKLOG          4096

// 连接状态枚举
enum conn_state {
    CONN_STATE_ACCEPT,
    CONN_STATE_READ,
    CONN_STATE_WRITE,
    CONN_STATE_CLOSE,
};

// 每个连接的管理结构
struct conn {
    int              fd;
    enum conn_state  state;
    int              buf_idx;   // 在 registered buffer pool 中的索引
};

// 全局连接表
static struct conn g_conns[MAX_CONNECTIONS];
// Registered buffer pool（固定缓冲区池）
static char        g_buf_pool[MAX_CONNECTIONS][BUF_SIZE] __attribute__((aligned(4096)));
// 空闲 buffer 栈
static int         g_free_bufs[MAX_CONNECTIONS];
static int         g_free_buf_count = 0;

// 分配一个空闲 buffer
static int alloc_buffer(void) {
    if (g_free_buf_count <= 0) return -1;
    return g_buf_pool[--g_free_buf_count];
}

// 归还一个 buffer
static void free_buffer(int idx) {
    g_free_bufs[g_free_buf_count++] = idx;
}

// 初始化连接表与 buffer pool
static void init_conns(void) {
    for (int i = 0; i < MAX_CONNECTIONS; i++) {
        g_conns[i].fd     = -1;
        g_conns[i].state  = CONN_STATE_CLOSE;
        free_buffer(i);
    }
}

// 获取一个空闲连接槽位
static struct_conn *get_conn(struct io_uring *ring) {
    for (int i = 0; i < MAX_CONNECTIONS; i++) {
        if (g_conns[i].fd == -1) return &g_conns[i];
    }
    return NULL;
}

// 提交 accept 请求：监听新连接
static int submit_accept(struct io_uring *ring, int listen_fd,
                         struct sockaddr_in *client_addr,
                         socklen_t *client_len) {
    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
    if (!sqe) {
        fprintf(stderr, "无法获取 SQE (accept)\n");
        return -1;
    }

    io_uring_prep_accept(sqe, listen_fd,
                         (struct sockaddr *)client_addr, client_len, 0);
    io_uring_sqe_set_data(sqe, &(struct conn){ .fd = listen_fd, .state = CONN_STATE_ACCEPT });
    return 0;
}

// 提交 recv 请求：从连接读取数据
static int submit_recv(struct io_uring *ring, struct conn *c) {
    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
    if (!sqe) {
        fprintf(stderr, "无法获取 SQE (recv)\n");
        return -1;
    }

    int buf_idx = alloc_buffer();
    if (buf_idx < 0) {
        fprintf(stderr, "Buffer pool 耗尽\n");
        return -1;
    }
    c->buf_idx = buf_idx;

    io_uring_prep_recv(sqe, c->fd, g_buf_pool[buf_idx], BUF_SIZE, 0);
    sqe->buf_group = BUF_GROUP_ID;
    io_uring_sqe_set_data(sqe, c);
    return 0;
}

// 提交 send 请求：向连接写入数据
static int submit_send(struct io_uring *ring, struct conn *c,
                       int bytes_written) {
    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
    if (!sqe) {
        fprintf(stderr, "无法获取 SQE (send)\n");
        return -1;
    }

    io_uring_prep_send(sqe, c->fd, g_buf_pool[c->buf_idx], bytes_written, 0);
    // 链接操作：send 完成后是否继续读取
    sqe->flags |= IOSQE_IO_LINK;
    io_uring_sqe_set_data(sqe, c);
    return 0;
}

// 提交 close 请求
static int submit_close(struct io_uring *ring, struct conn *c) {
    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
    if (!sqe) return -1;

    io_uring_prep_close(sqe, c->fd);
    io_uring_sqe_set_data(sqe, c);
    return 0;
}

// 初始化监听 socket
static int init_listen_socket(int port) {
    int fd = socket(AF_INET, SOCK_STREAM, 0);
    if (fd < 0) { perror("socket"); return -1; }

    int opt = 1;
    setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
    setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &opt, sizeof(opt));

    struct sockaddr_in addr = {
        .sin_family      = AF_INET,
        .sin_port        = htons(port),
        .sin_addr.s_addr = INADDR_ANY,
    };

    if (bind(fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("bind"); close(fd); return -1;
    }

    if (listen(fd, BACKLOG) < 0) {
        perror("listen"); close(fd); return -1;
    }

    printf("[*] 监听端口 %d，backlog=%d\n", port, BACKLOG);
    return fd;
}

int main(int argc, char **argv) {
    int port = (argc > 1) ? atoi(argv[1]) : 9000;

    // 1. 初始化 io_uring
    struct io_uring ring;
    struct io_uring_params params;
    memset(&params, 0, sizeof(params));
    params.flags |= IORING_SETUP_SQPOLL;          // 启用内核轮询模式
    params.sq_thread_idle  = 2000;                 // 空闲 2s 后内核线程睡眠

    if (io_uring_queue_init_params(QUEUE_DEPTH, &ring, &params) < 0) {
        perror("io_uring_queue_init_params");
        return 1;
    }

    // 注册固定缓冲区（避免每次注册的映射开销）
    struct iovec iovecs[MAX_CONNECTIONS];
    for (int i = 0; i < MAX_CONNECTIONS; i++) {
        iovecs[i].iov_base = g_buf_pool[i];
        iovecs[i].iov_len  = BUF_SIZE;
    }
    io_uring_register_buffers(&ring, iovecs, MAX_CONNECTIONS);

    // 注册固定文件（对 listen socket 也做可选优化）
    int fds[] = {-1}; // placeholder
    io_uring_register_files(&ring, fds, 1);

    // 2. 初始化监听 socket
    int listen_fd = init_listen_socket(port);
    if (listen_fd < 0) return 1;

    // 3. 初始化连接表
    init_conns();

    // 4. 提交初始 accept 请求
    struct sockaddr_in client_addr;
    socklen_t client_len = sizeof(client_addr);
    submit_accept(&ring, listen_fd, &client_addr, &client_len);

    printf("[*] Echo Server 启动，等待连接...\n");

    // 5. 主事件循环
    while (1) {
        // 提交所有 SQ 中的请求并等待至少一个完成事件
        io_uring_submit_and_wait(&ring, 1);

        // 收割完成队列
        struct io_uring_cqe *cqe;
        unsigned int       head;
        unsigned int       count = 0;

        io_uring_for_each_cqe(&ring, head, cqe) {
            count++;
            struct conn *c = (struct conn *)io_uring_cqe_get_data(cqe);
            int          res = cqe->res; // 操作结果：正数=字节数，负数=errno

            if (!c) goto next_cqe;

            switch (c->state) {
            case CONN_STATE_ACCEPT: {
                if (res >= 0) {
                    // 新连接建立
                    int new_fd = res;
                    struct conn *new_c = get_conn(&ring);
                    if (new_c) {
                        new_c->fd    = new_fd;
                        new_c->state = CONN_STATE_READ;
                        // 开启 TCP_NODELAY 减少小包延迟
                        int flag = 1;
                        setsockopt(new_fd, IPPROTO_TCP, TCP_NODELAY,
                                   &flag, sizeof(flag));
                        submit_recv(&ring, new_c);
                        printf("[+] 新连接 fd=%d\n", new_fd);
                    } else {
                        // 连接表满，直接关闭
                        close(new_fd);
                        fprintf(stderr, "! 连接表满，拒绝 fd=%d\n", new_fd);
                    }
                    // 重新提交 accept 请求
                    submit_accept(&ring, listen_fd, &client_addr, &client_len);
                } else {
                    fprintf(stderr, "! accept 错误: %s\n", strerror(-res));
                }
                break;
            }

            case CONN_STATE_READ: {
                if (res > 0) {
                    // 收到数据，回复 echo
                    c->state = CONN_STATE_WRITE;
                    submit_send(&ring, c, res);
                } else if (res == 0) {
                    // 对端关闭
                    free_buffer(c->buf_idx);
                    c->state = CONN_STATE_CLOSE;
                    submit_close(&ring, c);
                } else {
                    // 读取错误
                    if (res == -EAGAIN || res == -EINTR) {
                        // 非致命错误，重新提交 recv
                        free_buffer(c->buf_idx);
                        submit_recv(&ring, c);
                    } else {
                        fprintf(stderr, "! recv fd=%d 错误: %s\n",
                                c->fd, strerror(-res));
                        free_buffer(c->buf_idx);
                        c->state = CONN_STATE_CLOSE;
                        submit_close(&ring, c);
                    }
                }
                break;
            }

            case CONN_STATE_WRITE: {
                if (res >= 0) {
                    // 发送成功，继续读取下一批数据
                    free_buffer(c->buf_idx);
                    c->state = CONN_STATE_READ;
                    submit_recv(&ring, c);
                } else {
                    // 发送错误
                    free_buffer(c->buf_idx);
                    c->state = CONN_STATE_CLOSE;
                    submit_close(&ring, c);
                }
                break;
            }

            case CONN_STATE_CLOSE: {
                // 连接已关闭，释放资源
                g_conns[c - g_conns].fd    = -1;
                g_conns[c - g_conns].state = CONN_STATE_CLOSE;
                printf("[-] 连接 fd=%d 已关闭\n", c->fd);
                break;
            }
            }

next_cqe:
            io_uring_cqe_seen(&ring, cqe);
        } // end io_uring_for_each_cqe

        if (count == 0) {
            // 无完成事件，可做一些定时任务或短暂 pause
            // usleep(1); // 减少 CPU 空转
        }
    } // end while(1)

    // 清理（实际上主循环不会退出）
    io_uring_queue_exit(&ring);
    close(listen_fd);
    return 0;
}

代码解析：几个关键设计点

1. SQPOLL 模式的威力

代码中使用 IORING_SETUP_SQPOLL 创建 io_uring 实例。这意味着内核会启动一个后台线程（io_uring_sq_thread）持续轮询 SQ。用户态程序提交 SQE 后，不需要调用任何系统调用，内核线程会"自动发现"并执行。在我们的 echo server 中，主循环只调用一次 io_uring_submit_and_wait()，这是整个程序中唯一可能触发系统调用的点（用于等待至少一个 CQE 到来）。

2. 固定缓冲区池

代码使用 io_uring_register_buffers() 预先注册一组固定大小的缓冲区。之后每次 I/O 操作直接使用这些已注册的缓冲区，避免了 get_user_pages() 的开销（内核需要在每次 I/O 时将用户态内存页固定到内核地址空间）。在实际的高性能场景中，这是不可忽视的优化。

3. 基于状态的连接管理

每个连接的状态（accept → read → write → close）通过 CQE 的返回结果驱动转换。这种设计让代码结构清晰，同时充分利用了 io_uring 的异步特性——每个状态转换都能以最小的开销完成，不会阻塞事件循环。

4. Buffer group 优化

代码设置了 sqe->buf_group = BUF_GROUP_ID，这启用了 io_uring 的缓冲区组（Buffer Group）机制。在该模式下，recv 操作可以自动从预注册的缓冲区组中选择一个空闲缓冲区，recv 完成后 CQE 返回实际使用的缓冲区索引。这避免了每次 recv 前手动分配的延迟。

性能特征：epoll vs io_uring 的全面对比

理解两种模型的性能差异需要从多个维度进行分析。

系统调用频率

这是最直观的差异。epoll 模型中，每个连接每轮数据收发至少需要两次系统调用（recv() + send()），再加上 epoll_wait() 的开销。io_uring 使用中，SQPOLL 模式下整个 I/O 路径可以完全零系统调用。即使不使用 SQPOLL，io_uring_enter() 的批量提交能力也能将系统调用频率降低一个数量级。

内存带宽与拷贝

在 epoll 模型中，recv() 将数据从内核 TCP 缓冲区拷贝到用户态缓冲区，send() 再将数据从用户态拷贝回内核。每次跨越用户态-内核态边界都伴随着一次内存拷贝和可能的 TLB 刷新。io_uring 虽然也不能避免从内核到用户态的数据拷贝（这是 TCP 协议栈本身的限制），但固定缓冲区注册机制避免了频繁的页面映射/解映射操作，在大流量场景下内存带宽利用率更高。

延迟确定性

SQPOLL 模式下，I/O 请求的处理延迟极其稳定——内核线程以固定频率（受 sq_thread_idle 控制）轮询 SQ，不受用户态调度抖动的影响。这种确定性延迟在金融交易系统、实时音视频传输等场景中至关重要。

适用场景差异

io_uring 在网络编程中并非万能的银弹，它在以下场景中优势最为明显：

• 高并发、短连接：如 HTTP API 服务器，连接数多但每次交互数据量不大。io_uring 的批量提交/收割机制能极大降低系统调用开销。
• 高吞吐代理/负载均衡器：NGINX、Envoy 等代理需要在多个 socket 间转发数据。io_uring 的链接操作可以将"从上游读取 → 写入下游"串联起来，减少状态切换开销。
• 实时音视频流：需要稳定的低延迟和高并发连接管理能力。
• 存储+Samba/NFS 服务：网络协议加本地 I/O 的组合场景，io_uring 的异步 I/O 优势更加突出。

但在以下场景中，epoll 仍然是一个更好的选择：

• 极低吞吐量、长期空闲的连接：如长轮询、WebSocket 心跳场景，大部分时间没有数据流动，SQPOLL 内核线程的空转反而浪费 CPU。
• 简单的服务端程序：代码复杂度不值得引入 io_uring 的额外概念。
• 兼容性要求高：需要运行在较老的内核（早于 5.1）上。

生产实践：io_uring 网络应用的工程经验

1. 连接数不是越多越好

io_uring 的 SQE 和 CQE 数量在创建 ring 时固定（或动态扩展但有上限）。当连接数超过 SQE 数量时，未处理的请求会被排队。实际生产中，推荐将 SQE 数量设置为最大连接数的 2-3 倍，以应对突发流量。同时，io_uring_submit_and_wait() 的等待时间应该根据业务延迟需求仔细调优——过短会导致 CPU 空转，过长会增加请求延迟。

2. Buffer 管理是性能关键

使用 IORING_OP_PROVIDE_BUFFERS 模式时，内核会在 recv 完成后自动归还 buffer 到池中，减少了用户态的 buffer 管理代码。但需要注意 buffer 归还的时机——如果应用逻辑需要将 buffer 中的数据异步传递给另一个协程处理，需要在数据传递完成后才能归还 buffer，否则会出现 use-after-free。

3. 与 epoll 协同使用

很多生产场景是将 io_uring 用于数据面 I/O，用 epoll 管理控制面事件（如新连接到达）。具体做法是将 epoll fd 作为 io_uring 的一个 fd 来监听——提交 IORING_OP_POLL_ADD 监听监听 socket，当有新连接时由内核通知，然后再用 io_uring 处理后续的数据读写。这种混合模式兼顾了灵活性和性能。

4. 内核版本选择

io_uring 的发展非常迅速。Linux 5.10 引入了 IORING_FEAT_FAST_POLL，使得 io_uring 在 socket I/O 中甚至比 epoll 更高效（内核直接轮询 socket 缓冲区，无需等待 epoll 事件）。Linux 5.15+ 修复了 SQPOLL 模式下的多个稳定性问题，建议生产环境至少使用 5.15 内核。Linux 5.19 引入了 MSG_ZEROCOPY 与 io_uring 的深度整合，实现了网络发送方向的真正零拷贝。

5. 监控与可观测性

SQPOLL 内核线程的存在意味着传统的监控工具（如 strace、lsof）可能无法完整追踪 io_uring 应用的行为。推荐使用 bpftrace 跟踪 io_uring 相关的 tracepoint：

# 跟踪 io_uring 提交事件
bpftrace -e 'tracepoint:io_uring:io_uring_submit_sqe { 
    printf("submit: fd=%d, op=%d, pid=%d\n", args->fd, args->op, pid); 
}'

# 跟踪 io_uring 完成事件
bpftrace -e 'tracepoint:io_uring:io_uring_complete { 
    printf("complete: res=%d, op=%d\n", args->res, args->op); 
}'

前沿趋势：io_uring 与下一代网络栈

io_uring 正在持续演进，几个值得关注的方向：

• IORING_OP_SENDMSG_ZC / IORING_OP_RECVMSG_ZC：支持零拷贝 sendmsg/recvmsg，允许应用层协议头和数据分开发送时避免额外的内存拷贝。
• io_uring 与 io_uring 实例嵌套：允许在一个 io_uring 的 CQE 处理中直接提交新的 SQE，实现完全在内核态的操作链。
• 与 QUIC 协议协同：QUIC 作为新一代传输协议，由用户态实现协议栈。io_uring 可以高效地将加密/解密后的数据直接交给 QUIC 实现，同时利用共享缓冲区减少与协议引擎之间的拷贝。
• io_uring for Windows/Linux 跨平台：微软已经开始在 Windows 上实现 io_uring 兼容层，这意味着基于 io_uring 的高性能网络代码未来可能跨平台运行。

总结

io_uring 不仅仅是对 epoll 的替代，而是 Linux 异步 I/O 范式的根本性变革。它通过共享环形缓冲区消除了系统调用的固定开销，通过 SQPOLL 模式实现了真正的零系统调用 I/O，通过链接操作和固定缓冲区机制让复杂的网络处理流水线变得简洁高效。

对于追求极致性能的网络应用开发者而言，理解并掌握 io_uring 的编程模型已经从"可选技能"变成了"必备能力"。它要求的思维转变——从"我告诉内核什么时候做"到"我提前说好怎么做，内核自己执行"——正是异步编程的终极形态。

当然，io_uring 也不是没有门槛。它的 API 概念较多（SQE/CQE/SQPOLL/Buffer Group/Linked Operations 等），学习曲线比 epoll 陡峭。但回报也是丰厚的：在正确的场景下，io_uring 能带来数倍的性能提升和数量级的延迟稳定性改善。如果你的应用正在触达 epoll 的性能天花板，io_uring 值得你投入时间深入探索。