io_uring + splice/tee：Linux 零拷贝数据传输的终极工程实践

在高性能网络服务器的演进史中，减少数据拷贝次数始终是核心命题。从 read/write 的两次拷贝，到 sendfile 的一次拷贝，再到 splice/tee 的零拷贝，Linux 内核不断突破 I/O 路径的性能天花板。当 io_uring 这个革命性异步 I/O 框架遇上零拷贝原语，会擦出怎样的工程火花？

一、数据传输的经典困境

以最常见的 HTTP 反向代理为例：磁盘文件 → 内核缓存 → 用户空间 → 内核 socket 缓冲区 → 网卡。传统 read/write 流程中，一次数据传输涉及： - 2 次 CPU 拷贝（内核→用户，用户→内核） - 2 次上下文切换（read + write 各一次） - 2 次 DMA 拷贝（磁盘→内核，网卡→内核，不计入 CPU 拷贝开销）

这意味着每一个请求，CPU 都要为同样一份数据做无用功。当 QPS 达到十几万，这些冗余拷贝消耗的 CPU 周期和时间将极其可观。

早期解决方案 sendfile() 将文件直接送入 socket，消除了用户空间的中转，但它有几个致命限制：源必须是文件（mmap 友好），目标是 socket，且不支持修改数据。

二、splice/tee/vmsplice 三件套

Linux 2.6.17（2006 年）引入的 splice() 系统调用，首次在用户态提供了一种「管道移动」语义：数据从一个文件描述符流入管道，再从管道流向另一个文件描述符，全程在内核空间完成，用户态零拷贝。

2.1 splice 的语义

#include <fcntl.h>

ssize_t splice(int fd_in, loff_t *off_in, int fd_out, loff_t *off_out,
               size_t len, unsigned int flags);

核心行为：将 fd_in 的数据"移动"到 fd_out，中间经过一个 pipe buffer。关键在于"移动"而非"复制"——内核通过页引用计数（page reference counting）实现 page stealing，数据页面的物理内存不做拷贝，仅转移所有权。

2.2 tee 的只读分流

ssize_t tee(int fd_in, int fd_out, size_t len, unsigned int flags);

tee 与 splice 类似，但不会消费源数据。数据被复制到管道后，源端页面仍然保留引用——这实现了类似 tee 命令的分流效果，同一份数据可以同时流向 socket 和日志文件，非常适合转发链中的数据镜像。

2.3 vmsplice 的用户态注入

ssize_t vmsplice(int fd_out, const struct iovec *iov,
                 unsigned long nr_segs, unsigned int flags);

vmsplice 将用户空间的内存页面"赠送"给管道（实际是 page donation）。配合 SPLICE_F_GIFT 标志，用户态页面所有权直接转移给内核，避免了一次用户→内核的拷贝。这是构建自定义协议栈时的关键原语——你需要处理数据后送入网络，而非简单转发。

三、内核实现：pipe buffer 与 page stealing

理解零拷贝性能的关键在于内核的 pipe 缓冲区实现。

3.1 Pipe buffer 环形队列

Linux 内核中，管道由一个环形 buffer 数组管理（struct pipe_inode_info），默认 16 个 page（64KB on x86_64）。每个页面有 struct pipe_buffer 描述，包含指向实际内存的 struct page *。

关键操作路径：

splice_read() → 获取源 fd 的页面引用 → 填充 pipe_buffer → 加入环形队列
splice_write() → 从环形队列取出 pipe_buffer → 写入目标 fd → 释放引用

当 splice 从文件读取数据时，它不会分配新页面，而是直接让 pipe_buffer->page 指向页面缓存（page cache）中的页面，并将该页面的引用计数加一。

3.2 页级所有权转移

splice 的零拷贝本质就是页所有权的转移——源端放弃引用，目标端获得引用，全过程中没有 memcpy 发生。但有一个临界条件：源 fd 提供的页面必须完整拥有（SPLICE_F_MOVE），否则内核退化为物理拷贝。

对于 socket 作为目标端，内核会将 pipe 中的页面直接传给协议的 sendpage 回调（如 tcp_sendpage）。TCP 层对这些页面做 GSO（Generic Segmentation Offload）分页后交给网卡驱动，整个过程用户态甚至不需要参与。

3.3 性能边界与限制

• PIPE_BUF 原子性保证：小于 PIPE_BUF（通常 4096 字节）的 splice 操作是原子的，但超过此限制的移动不保证原子性。
• 页面对齐要求：实际零拷贝需要页面完整。如果数据长度不是页的整数倍，末尾不对齐部分可能需要额外处理。
• 内核线程协同：大块数据 splice 涉及等待 pipe buffer 可用空间，可能引入调度延迟。

四、io_uring 中的 splice/tee 集成

io_uring 5.7+ 引入了 IORING_OP_SPLICE 和 IORING_OP_TEE，将零拷贝原语纳入异步提交-完成模型。其核心优势在于：批量提交多个零拷贝操作，仅需一次系统调用。

4.1 提交格式

struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);

// splice: fd_in → fd_out
sqe->opcode = IORING_OP_SPLICE;
sqe->fd = fd_out;              // 目标 fd
sqe->off = 0;                  // fd_in 偏移（in_fd 在内核通过 splice_fd_in 设置）
sqe->addr = 0;                 // 不使用用户缓冲区
sqe->len = len;                // 要移动的字节数
sqe->splice_flags = SPLICE_F_MOVE | SPLICE_F_MORE;

// 对于 tee
sqe->opcode = IORING_OP_TEE;

io_uring 的 splice 还需要通过 splice_fd_in 字段指定源 fd，在 5.7+ 内核中通过 sqe->splice_fd_in 设置。

4.2 实际代码：零拷贝 HTTP 代理

以下展示一个使用 io_uring + splice 构建的文件转发器，零用户态参与地将文件内容推向 socket：

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

#define QUEUE_DEPTH 64
#define BUF_SIZE 65536

struct splice_request {
    int fd_in;       // 源文件 fd
    int fd_out;      // socket fd
    off_t offset;    // 当前读取偏移
    size_t remain;   // 剩余待发送字节
};

int splice_file_to_socket(struct io_uring *ring, struct splice_request *req,
                          int pipefd[2]) {
    struct io_uring_sqe *sqe;
    struct io_uring_cqe *cqe;
    size_t chunk;
    int ret;

    while (req->remain > 0) {
        chunk = req->remain > BUF_SIZE ? BUF_SIZE : req->remain;

        // Step 1: 文件 → pipe (splice)
        sqe = io_uring_get_sqe(ring);
        if (!sqe) {
            fprintf(stderr, "SQE full\n");
            return -1;
        }
        io_uring_prep_splice(sqe, req->fd_in, req->offset,
                             pipefd[1], -1, chunk, SPLICE_F_MOVE | SPLICE_F_MORE);
        sqe->flags |= IOSQE_IO_LINK;  // 链接下一步

        // Step 2: pipe → socket (splice)
        sqe = io_uring_get_sqe(ring);
        if (!sqe) {
            fprintf(stderr, "SQE full\n");
            return -1;
        }
        io_uring_prep_splice(sqe, pipefd[0], -1,
                             req->fd_out, -1, chunk, SPLICE_F_MOVE);

        io_uring_submit(ring);
        ret = io_uring_wait_cqe(ring, &cqe);
        if (ret < 0) {
            fprintf(stderr, "wait_cqe: %s\n", strerror(-ret));
            return ret;
        }

        if (cqe->res < 0) {
            fprintf(stderr, "splice failed: %s\n", strerror(-cqe->res));
            io_uring_cqe_seen(ring, cqe);
            return cqe->res;
        }

        req->offset += cqe->res;
        req->remain -= cqe->res;
        io_uring_cqe_seen(ring, cqe);
    }
    return 0;
}

// 设置非阻塞 socket pipe
void setup_pipe(int pipefd[2]) {
    // 创建 pipe，设置 O_NONBLOCK 防止写端阻塞
    pipe2(pipefd, O_CLOEXEC | O_NONBLOCK);
    // 可选：增加 pipe buffer 容量以获得更高吞吐量
    fcntl(pipefd[0], F_SETPIPE_SZ, 1024 * 1024);  // 1MB
    fcntl(pipefd[1], F_SETPIPE_SZ, 1024 * 1024);
}

int main(int argc, char *argv[]) {
    struct io_uring ring;
    struct splice_request req;
    int pipefd[2];
    int file_fd, sock_fd;

    if (argc < 2) {
        fprintf(stderr, "Usage: %s <filename>\n", argv[0]);
        return 1;
    }

    // 初始化 io_uring
    if (io_uring_queue_init(QUEUE_DEPTH, &ring, 0) < 0) {
        perror("io_uring_queue_init");
        return 1;
    }

    // 打开源文件
    file_fd = open(argv[1], O_RDONLY);
    if (file_fd < 0) {
        perror("open");
        return 1;
    }

    // 连接目标 socket（示例：本地 8080）
    sock_fd = socket(AF_INET, SOCK_STREAM, 0);
    struct sockaddr_in addr = {
        .sin_family = AF_INET,
        .sin_port = htons(8080),
        .sin_addr.s_addr = htonl(INADDR_LOOPBACK)
    };
    connect(sock_fd, (struct sockaddr *)&addr, sizeof(addr));

    // 设置管道
    setup_pipe(pipefd);

    // 填充请求
    struct stat st;
    fstat(file_fd, &st);
    req = (struct splice_request){
        .fd_in = file_fd,
        .fd_out = sock_fd,
        .offset = 0,
        .remain = st.st_size
    };

    // 执行零拷贝传输
    splice_file_to_socket(&ring, &req, pipefd);

    close(file_fd);
    close(sock_fd);
    close(pipefd[0]);
    close(pipefd[1]);
    io_uring_queue_exit(&ring);
    return 0;
}

4.3 IOSQE_IO_LINK 链式提交

上面代码的关键在于 IOSQE_IO_LINK 标志——它将"文件→pipe"和"pipe→socket"两个 SQE 链接成一个原子操作序列。io_uring 会按顺序执行它们，且不会因为 SQE 缓冲区满而中断中间的链路。这比传统 pipe() + 两个独立 splice() 调用更可靠，也避免了用户态循环的调度开销。

对于更长链路（文件 → 加密 → tee → socket + 日志文件），可以用链式 splice + tee 实现：

// 链式：文件 → pipe1 (splice) → pipe2 (tee 分流) → socket (splice)
// pipe1 的出口同时是 pipe2 的入口，tee 保留了 pipe1 的数据供日志用

五、实战场景：从 proxy 到 log shipper

5.1 零拷贝反向代理

Nginx 在开启 sendfile on 时，静态文件转发走 sendfile() 零拷贝。但如果你需要同时做：文件读取 + 响应头拼接 + tee 日志，传统方案不得不回到 read/write。

io_uring + splice 提供了更优解：

[磁盘文件] --splice--> [pipe] --splice--> [socket]
                       |
                      tee
                       |
                  [log file]

关键实现点：

1. 响应头使用 vmsplice 直接注入 pipe：将 HTTP 响应头写入用户缓冲区，通过 vmsplice(SPLICE_F_GIFT) 将页面赠送给 pipe，后续 socket 端 splice 一并带走。
2. 文件主体用 splice 从 page cache 直接移动。
3. 日志分流通过 tee 同时流入日志 fd。

全链路用户态除了构造响应头和 splice 提交外，完全不触碰数据正文。

5.2 Log shipper 的高吞吐管道

Filebeat 等日志采集工具的瓶颈之一是文件→网络的拷贝开销。基于 io_uring + tee 的方案可以同时实现：

• 实时日志流式索引：pipe → splice → socket（发到 ES）
• 本地审计归档：tee 同一 pipe → splice → 本地日志文件

对比传统方案的双份 read，零拷贝 fork 数据流节省了约 50% 的内存带宽和 CPU 拷贝时间。

5.3 数据库 WAL 刷盘流水线

PostgreSQL 的 WAL 写入需要保证顺序性和持久性。利用 pipe buffer 的 FIFO 语义和 vmsplice 的 page donation，可以构建一个用户态→内核的 WAL 推送路径：

• walwriter 进程将 WAL 条目写入 vmsplice 页面
• splice 将这些页面推送到 WAL segment file
• 同一份数据通过 tee 同步发送到备库 socket

利用 SPLICE_F_MORE 标志告知内核后续还有更多数据，可以优化 TCP 的 Nagle 算法和 buffer 利用率。

六、性能分析与基准测试

在一台 16C32T Xeon、DDR4-3200 的机器上，io_uring + splice 与传统 read/write 的对比数据：

注：测试数据受内核版本、硬件、文件系统影响，仅作相对比较。

关键发现：

1. io_uring 批处理优势明显：单次 io_uring_submit 可以提交多个 splice 操作，系统调用开销被分摊。
2. splice 自身受 pipe buffer 默值限制：默认 64KB 管道在处理大文件时需要多次操作，通过 F_SETPIPE_SZ 调优可显著减少内核态调度次数。
3. page cache 亲和性：splice 对 page cache 中的文件零拷贝，但对未缓存文件会发生一次预读（read-ahead）。因此预热后的文件转发性能远优于冷数据。

七、常见陷阱与踩坑实录

7.1 splice 并非总是零拷贝

splice 的零拷贝保证取决于源页面的可移动性。以下情况会退化为物理拷贝： - 源数据来自某设备驱动私有内存（不是 page cache / 匿名页） - 源页面已被 mlock 锁定 - 目标需要 DMA scatter-gather 但页面不连续

退化后 splice 的行为类似于 read + write 但仍在内核态完成，性能不如直接使用 read/write（因为缺少用户态缓冲区的优化空间）。

7.2 pipe buffer 的 FIFO 语义陷阱

pipe buffer 严格 FIFO，你不能在已 splice 入 pipe 的数据中间插入 vmsplice 内容（vmsplice 会追加到 pipe 尾部）。如果你的协议要求"先头部后体"且体是文件数据，顺序是：

1. vmsplice(头部) → 入 pipe
2. splice(文件) → 入 pipe
3. splice(pipe → socket) → 取出（先头后体，符合协议）

如果顺序搞反，头和体会错位。

7.3 io_uring splice 的 fd 生命周期

IORING_OP_SPLICE 的源 fd 需要在提交前确认有效。io_uring 不会阻止你关闭一个已提交但未完成的 splice 对应 fd——结果是不可预测的。正确使用模式是：提交前 hold fd，完成回调后释放。

八、内核演进与未来方向

Linux 6.x 对 splice 路径持续优化：

• Pipe buffer 回收策略改进：减少 splice 过程中对页面的重复分配与释放。
• io_uring fixed buffer 与 splice 结合：命名操作（IORING_OP_SPLICE_FIXED）可能在未来的内核版本中支持预注册的 buffer 池。
• TCP splice offload：将 splice 操作完全卸载到支持 TCP offload 的 NIC，进一步释放 CPU。

此外，io_uring 正在探索 IORING_OP_SEND_ZC（零拷贝 socket send）与现有 splice 的组合，目标是构建"文件→NIC"的全链路硬件零拷贝。

九、总结

splice/tee/vmsplice 是 Linux 零拷贝数据传输的底层基石，而 io_uring 的集成让这些原语真正进入了高性能服务器的生产代码路径。

关键技术点回顾：

• splice 通过 page stealing 实现内核内零拷贝，适用于 fd 间数据移动。
• tee 允许不消费源数据的同时分流水流，适合多消费端场景。
• vmsplice + SPLICE_F_GIFT 让用户态页面直接注入内核管道，是实现自定义协议栈的关键。
• io_uring 通过批量提交和链式链接，将系统调用开销降到最低。
• IOSQE_IO_LINK 保证多步零拷贝操作的原子提交顺序。

在设计高吞吐网络中间件时，将文件 I/O、网络 I/O 和数据分流统一到 io_uring + splice 的框架下，可以达到接近硬件极限的传输性能，同时保持代码的可维护性和正确的语义边界。

本文代码示例已适配 Linux 6.1+ 内核与 liburing 2.4+ 版本。不同内核版本 API 可能存在微小差异，生产部署时请参考对应版本的头文件。