C++ 实现基于 Zero-Copy 零拷贝技术的异步大数据传输协议及其实战【源码】-C++-PHP中文网

零拷贝在c++网络传输中省去的是用户态与内核态之间重复的memcpy，典型如传统read/write路径中的“内核缓冲区→用户缓冲区→socket缓冲区”两趟cpu拷贝；sendfile/splice等系统调用可跳过用户态，直接在内核中完成fd间数据搬运。

c++ 实现基于 zero-copy 零拷贝技术的异步大数据传输协议及其实战【源码】

零拷贝在 C++ 网络传输中到底省了哪几趟 memcpy？

零拷贝不是“完全不拷贝”，而是避免用户态与内核态之间重复的 memcpy。典型场景如从磁盘读文件再发到网络，传统方式要经历：磁盘 → 内核缓冲区 → 用户缓冲区 → socket 发送缓冲区 → 网卡。Zero-Copy（如 sendfile、splice）能跳过用户态这一环，直接让内核把数据从一个 fd 搬到另一个 fd。

但 C++ 标准库不提供原生零拷贝 API，必须调用 POSIX 系统调用，且仅 Linux 支持完整能力；Windows 的 TransmitFile 语义类似，但接口和行为差异大。

sendfile() 适合文件 → socket，但 source fd 必须是普通文件（不支持 socket 或 pipe）
splice() 更灵活，支持 pipe 作为中转，可组合实现 socket-to-socket 零拷贝转发，但要求至少一端是 pipe
使用前需检查内核版本（splice 在 2.6.17+ 完善，sendfile 更早）
异步 I/O（如 io_uring）才能真正释放 CPU，单纯用 sendfile + 阻塞 socket 仍是同步等待

如何用 io_uring 实现真正的异步零拷贝发送？

io_uring 是 Linux 5.1+ 提供的高性能异步 I/O 接口，支持 IORING_OP_SENDFILE 和 IORING_OP_SPLICE，能把零拷贝操作提交为非阻塞任务，完成时通过 CQE 通知。

关键点不是“能不能用”，而是“怎么配才不出错”：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

必须用 IORING_SETUP_SQPOLL（需 CAP_SYS_ADMIN）或至少启用 IORING_SETUP_IOPOLL 才能绕过 syscall 开销
sendfile 提交时，off 参数必须对齐文件系统块大小（常见 4K），否则返回 -EINVAL
目标 socket 必须已连接且处于 non-blocking 模式，否则 io_uring 提交会失败（错误码 -EAGAIN 而非阻塞）
不要在同一个 io_uring 实例里混用 read/write 和 sendfile——后者不走 page cache，若文件被 mmap 修改，可能看到脏数据

示例片段（简化）：

struct iovec iov = { .iov_base = nullptr, .iov_len = 0 };
struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
io_uring_prep_sendfile(sqe, sockfd, file_fd, &offset, count, 0);
io_uring_sqe_set_data(sqe, user_ctx);
io_uring_submit(&ring);

为什么 mmap + writev 有时比 sendfile 更慢？

有人尝试用 mmap 映射文件 + writev 多段发送，以为能零拷贝，实际常更差。根本原因是：mmap 只是虚拟地址映射，真正触发页加载（page fault）时仍要拷贝进 page cache；而 sendfile 可直通 page cache，甚至利用硬件 offload（如 TCP segmentation offload）。

mmap 后调用 writev 会强制触发缺页中断，尤其大文件首次访问时延迟尖刺明显
writev 本身不零拷贝——它仍要把用户态地址里的数据 copy 到 socket send buffer
若文件被其他进程修改，mmap 区域可能被 kernel 重映射，导致 writev 出现 -EAGAIN 或数据错乱
真正可行的替代是 IORING_OP_READV + IORING_OP_WRITEV 组合，但中间 buffer 仍在用户态，不算零拷贝

实战中容易忽略的边界条件

零拷贝协议落地最常崩在边界而非主干逻辑。比如传输 2MB 文件，99% 成功，但遇到 4097 字节就 hang 住——往往是因为没处理好 partial completion。

sendfile 返回值可能小于请求长度（尤其网络拥塞或接收端 RCVBUF 满），必须循环调用并更新 offset，不能只看一次返回
splice 对 pipe 容量敏感：默认 pipe buffer 是 64KB，若一次 splice 超过该值，会阻塞或截断，需提前 fcntl(pipefd[1], F_SETPIPE_SZ, size)
文件被 truncate 时，sendfile 可能返回 -EINVAL 或静默截断，需监听 inotify 或定期 stat 校验文件大小
异步场景下，io_uring 的 CQE 可能乱序完成，若依赖发送顺序（如协议头+体），必须用 IORING_F_IO_LINK 显式串行化