sendfile 在 Linux 下可实现真正零拷贝，但仅限普通文件到 TCP socket 的直接传输，不经过用户态内存；源 fd 需 O_RDONLY 打开，目标 fd 必须为已连接 socket，且内核需 ≥2.6.33。
sendfile 系统调用在 Linux 下是否真能零拷贝
能，但仅限于「文件描述符之间」的直接搬运，且目标必须是支持 splice 语义的 socket（如 TCP 套接字），中间不经过用户态内存。一旦你用 send() 或 write() 中转，就立刻退化为传统拷贝路径。
关键限制：源 fd 必须是普通文件（O_RDONLY 打开），不能是管道、socket 或 /proc 下的特殊文件；目标 fd 必须是 socket 且处于阻塞或非阻塞模式均可，但非阻塞时要处理 EAGAIN。
- Linux 内核 2.6.33+ 对 TCP socket 的
sendfile支持完整零拷贝（跳过内核态 socket 缓冲区拷贝） - 如果目标 socket 已关闭、对端断连或发送缓冲区满，
sendfile可能只写入部分字节，需检查返回值，不能假设一次传完 -
sendfile不支持 TLS/SSL socket —— OpenSSL 的BIO或SSL_write()底层仍是用户态加密+write()，无法穿透
如何正确调用 sendfile 实现文件到 socket 传输
核心是构造合法的 fd 对，并处理边界条件。C++ 里没有封装，直接用系统调用即可，无需额外库。
典型流程：open() 文件 → socket() + connect() → sendfile() → 检查返回值并重试（如需要）→ close()。
立即学习“C++免费学习笔记（深入）”；
- 源 fd 必须用
O_RDONLY打开，且不能是O_APPEND；建议加O_NOATIME避免更新访问时间 - 目标 socket 必须已连接（
connect()成功或由accept()返回），未连接的 socket 会触发ENOTCONN - 偏移量参数（
off_t*）若为nullptr，则从当前文件偏移开始，并自动更新；若传入有效指针，需确保其指向的值在调用前已初始化 - 传入的字节数（
size_t count）不能超过SSIZE_MAX（通常为 2GB 左右），超长文件需分段调用
示例片段：
ssize_t n = sendfile(sockfd, file_fd, &offset, count);
if (n == -1) {
if (errno == EAGAIN || errno == EWOULDBLOCK) {
// 非阻塞模式下缓冲区满，需等待可写事件再试
} else if (errno == EINTR) {
// 被信号中断，可重试
}
} else if (n < count) {
// 只传了部分，offset 已更新，下次从新 offset 继续
}
为什么 sendfile 有时 fallback 到内核拷贝甚至失败
不是所有 socket 类型都支持真正零拷贝。Linux 对不同协议栈的支持程度差异很大。
- TCP over IPv4/IPv6：完全支持，路径为 page cache → TCP send queue（无 copy）
- Unix domain socket：支持，但仅限同一主机，且需两端都启用
SOCK_STREAM - UDP socket：不支持 ——
sendfile对 UDP 返回ESPIPE，因为 UDP 是无连接、无顺序的报文接口，无法做流式搬运 - 监听 socket（
listen()后未accept()的 fd）：不支持，会返回ENOTCONN - 某些容器环境（如早期 runC）或 cgroup v1 网络隔离下，可能因 socket 创建上下文受限导致
sendfile失败
一个容易被忽略的点：如果文件系统是 XFS 并启用了 DAX（Direct Access），sendfile 可能因 page cache 不存在而失败，此时应改用 read()+write() 或 splice() 组合。
sendfile 和 splice + tee 的性能差异在哪
sendfile 是单向专用接口，简单直接；splice 更底层、更灵活，但使用门槛高。实际吞吐差异在千兆网以上才明显。
-
sendfile最大优势是语义清晰、出错路径少、glibc 封装稳定 -
splice可以实现 pipe 中转、多路复用（比如同时发往两个 socket），但要求至少一端是 pipe；且splice不能跨不同挂载点的文件系统（会 fallback） - 如果要带校验（如边发边算 CRC）、加 header、或动态截断，
sendfile无能为力，必须切回用户态缓冲 - 在高并发小文件场景下，反复
open()/sendfile()/close()的 syscall 开销可能比用mmap()+write()更高，这时要考虑 fd 复用或 sendfile64 配合 pread
真正影响落地的是错误处理粒度：sendfile 返回已写字节数，而 splice 在管道满时可能只搬一半数据，调试难度更高。
