HikariTish

1.1 传统文件发送路径#

1
磁盘 → 内核 buffer → 用户 buffer → socket buffer → 网卡

涉及两次 syscall（read + write）和两次跨态拷贝（kernel → user + user → kernel）。

1.2 sendfile 路径#

1
磁盘/Page Cache → socket → 网卡

用户态不接触数据，全程在内核态完成。

1.3 关于”零拷贝”#

严格来说，现代 Linux 的 sendfile 更多是减少拷贝而非绝对零拷贝——部分场景仍可能经过 DMA buffer 或 socket buffer。但效果等价：用户态不持有数据，CPU 不参与搬运。

1.4 sendfile 函数签名#

1
#include <sys/sendfile.h>
2

3
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

限制：Linux 2.6.33 之前 out_fd 必须是 socket；之后该限制放宽，但实际使用场景几乎都是 file → socket。

2.1 io.Copy 的自动优化#

1
file, _ := os.Open("video.mp4")
2
conn, _ := net.Dial("tcp", "127.0.0.1:8080")
3

4
io.Copy(conn, file) // ← 底层自动调用 sendfile()

触发条件：

• 源是 *os.File
• 目标是 *net.TCPConn（Go 1.4+）
• 操作系统为 Linux（macOS 使用类似的 sendfile 系统调用）

内部实现位于 src/net/sendfile_linux.go，io.Copy 会检测 ReaderFrom / WriterTo 接口——net.TCPConn 实现了 ReadFrom，而 ReadFrom 内部检测到源是 *os.File 后，直接走 sendfile 路径。

2.2 http.ServeFile 路径#

1
http.HandleFunc("/download", func(w http.ResponseWriter, r *http.Request) {
2
    http.ServeFile(w, r, "large_file.zip")
3
})

http.ServeFile 内部调用 io.CopyN(w, f, size) → 最终走到 sendfile。这也是 Go 静态文件服务性能不低的根本原因。

2.3 net.TCPConn.ReadFrom#

1
// net.TCPConn.ReadFrom 是 sendfile 的直接入口
2
func (c *TCPConn) ReadFrom(r io.Reader) (int64, error)

当 r 是 *os.File 时，直接进入 src/net/sendfile_linux.go 的快速路径。即使 r 不是 *os.File，Go 也会尝试通过 io.LimitedReader 等方式适配。

2.4 内部实现摘要#

1
// src/net/sendfile_linux.go (Go 1.23+)
2

3
func sendFile(c *netFD, r io.Reader) (written int64, err error, handled bool) {
4
    // 1. 确认源是 *os.File
5
    f, ok := r.(*os.File)
6
    if !ok {
7
        return 0, nil, false // 回退到普通 read/write
8
    }
9

10
    // 2. 获取底层 fd
11
    sc, err := f.SyscallConn()
12
    // ...
13

14
    // 3. 循环调用 sendfile syscall
15
    for {
16
        n, err := syscall.Sendfile(c.fd.Sysfd, int(f.Fd()), &remain, maxChunk)
17
        // ...
18
    }
19
}

关键点：如果 sendfile 某次调用只传输了部分数据（例如被信号中断），Go 会自动重试剩余部分，对调用方透明。

3.1 手动调用 vs 自动优化#

推荐：绝大多数场景直接用 io.Copy 即可。手动调用只在性能分析（pprof）显示 io.Copy 路径不够时才考虑。

4.1 经典用例#

4.2 Kafka 如何利用 sendfile#

Kafka 的经典之处：消息写入是顺序写磁盘（segment 文件），消费者拉取时直接 sendfile，消息数据从不进入用户态。

1
Producer → Broker (顺序写 segment 文件)
2
                          ↓
3
Consumer ← Broker (sendfile: segment → socket)

所以 Kafka 即使吞吐极高，CPU 占用仍然很低——数据搬运完全在内核态完成。

4.3 Nginx 与 sendfile#

Nginx 配置中有：

1
sendfile on;
2
tcp_nopush on;

这同样是直接调用 sendfile(2)，Go 的 http.ServeFile 在 Linux 上走的是同一条内核路径。

5.1 数据不可修改#

因为数据不进入用户态，任何需要处理数据的场景都不适用：

5.2 TLS 对 sendfile 的影响#

1
纯 HTTP:   文件 → sendfile → socket → 网卡        ✅ 零拷贝
2
HTTPS:     文件 → 用户态 TLS 加密 → socket → 网卡   ❌ 必须经过用户态

HTTPS 场景下 sendfile 效果大幅下降，因为 TLS 加密必须在用户态完成。

5.3 kTLS（Kernel TLS）#

kTLS 原理：将 TLS 会话密钥传入内核，由内核完成加密后直接 sendfile，从而在 HTTPS 场景下恢复零拷贝能力。

Go 与 kTLS：Go 1.23 时标准库尚未默认启用 kTLS（Go 使用自己的 crypto/tls 实现，不依赖 OpenSSL）。如果你需要 kTLS + sendfile 的 HTTPS 零拷贝，可以考虑 Caddy（使用 Go 但通过其他方式集成），或使用 Envoy/Nginx 做 TLS 终止。

5.4 sendfile 失败的常见原因#

Go 在 sendfile 失败时会自动回退到 read/write 循环，对调用方透明。

6.1 版本演进总览#

6.2 低版本注意事项#

1
// ⚠️ Go 1.21 及之前：某些边缘场景可能不会触发 sendfile
2
// 例如：通过 io.LimitedReader 包装的 *os.File
3
// 建议做性能验证，必要时通过 pprof 确认是否走 sendfile 路径

1
// ⚠️ Go 1.19 之前：HTTP Range 请求可能不会走 sendfile 优化
2
// 如果你的服务大量处理分段下载，建议升级到 1.19+

1
// ⚠️ 这些版本已停止维护，sendfile 相关优化相比新版有显著差距
2
// 强烈建议升级到 Go 1.23+

6.3 验证 sendfile 是否生效#

1
# 方法一：strace 观察
2
strace -e sendfile -f go run main.go 2>&1 | grep sendfile
3

4
# 方法二：pprof CPU profile
5
# 如果 sendfile 生效，read/write 的 CPU 消耗应该极低
6
go tool pprof http://localhost:6060/debug/pprof/profile
7

8
# 方法三：查看 Go 内部追踪
9
GODEBUG=schedtrace=1000 ./server

6.4 跨平台差异#

7.1 技术栈组合#

1
             ┌──────────┐
2
             │  Nginx   │
3
             │  Kafka   │
4
             │  Envoy   │
5
             │  Go 网关  │
6
             └────┬─────┘
7
                  │
8
    ┌─────────────┼─────────────┐
9
    │             │             │
10
    ▼             ▼             ▼
11
 epoll       sendfile       mmap
12
(连接管理)   (文件传输)    (大文件随机访问)
13
    │             │             │
14
    └─────────────┼─────────────┘
15
                  │
16
            io_uring (下一代)

7.2 你可能会用到的组合#

做 Go 网关 / IM / netpoll 方向时，这套技术栈会逐步接触：

• bufio → 用户态缓冲，减少小读小写
• sendfile → 静态文件传输零拷贝
• writev → HTTP 响应头 + body 的 scatter/gather IO
• splice → 代理场景（客户端 ↔ 后端）的零拷贝转发
• mmap → 日志文件、索引文件的高效访问
• epoll → Go runtime 的 netpoller 底层
• io_uring → 未来替代 epoll + 更多能力