22、网络性能优化：零拷贝技术、TCP窗口调优、Nagle算法与C10K问题

说实话，网络编程做到一定阶段，你会发现瓶颈往往不在业务逻辑，而在数据怎么从网卡流到应用程序手里。我早年做网关项目时，一台机器扛几千连接就卡得不行，CPU全耗在数据拷贝上了。后来才明白，所谓的网络性能优化，本质上就是跟「数据搬运」这件事较劲。

这一讲，我们聊聊四个核心方向：零拷贝技术、TCP窗口调优、Nagle算法，以及那个经典的C10K问题。每个点我都踩过坑，咱们一个一个说。

22.1 零拷贝技术：少搬一次数据，快一倍

先问个问题：传统模式下，从磁盘读文件再通过socket发出去，数据在内存里被拷贝了几次？答案是四次。用户空间和内核空间之间来回倒腾，CPU还得参与。说白了，这就是浪费。

零拷贝技术的核心思路就一句话：让数据在内核空间直接流转，别经过用户态。Linux提供了两个系统调用：sendfile 和 splice。

22.1.1 sendfile：文件到socket的直通车

sendfile 是我用得最多的。它直接把文件描述符的数据发送到socket，全程不需要用户态缓冲区。我记得第一次用的时候，一个文件传输服务的CPU占用率从80%降到了15%。

#include <sys/sendfile.h>

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

参数很简单：out_fd 是socket，in_fd 是打开的文件，offset 指定从哪里开始读，count 是传输字节数。

看个实际例子：

int send_file(int client_fd, const char *filepath) {
    int file_fd = open(filepath, O_RDONLY);
    if (file_fd < 0) return -1;

    struct stat stat_buf;
    fstat(file_fd, &stat_buf);

    off_t offset = 0;
    ssize_t sent = sendfile(client_fd, file_fd, &offset, stat_buf.st_size);
    
    if (sent != stat_buf.st_size) {
        // 处理未发送完的情况
        perror("sendfile partial");
    }

    close(file_fd);
    return 0;
}

22.1.2 splice：更通用的零拷贝

splice 比 sendfile 更灵活。它可以在两个文件描述符之间移动数据，只要其中一个是管道。我曾经用它在代理服务器里做数据转发，效果不错。

#define _GNU_SOURCE
#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);

典型用法：

int pipe_fd[2];
pipe(pipe_fd);

// 从socket读数据到管道
ssize_t n = splice(client_fd, NULL, pipe_fd[1], NULL, 4096, SPLICE_F_MOVE);
// 从管道写到目标socket
splice(pipe_fd[0], NULL, target_fd, NULL, n, SPLICE_F_MOVE);

22.2 TCP窗口调优：别让带宽闲着

TCP窗口大小决定了发送端一次能发多少数据而不等确认。窗口太小，网络利用率低；窗口太大，可能造成拥塞。我见过一个案例，某团队把窗口设成默认值，结果跨洋传输只有几百KB/s，调大后直接跑到几十MB/s。

22.2.1 关键参数

参数	说明	建议值
tcp_rmem	接收缓冲区最小值、默认值、最大值	4096 87380 6291456
tcp_wmem	发送缓冲区最小值、默认值、最大值	4096 65536 4194304
tcp_window_scaling	启用窗口缩放因子（RFC 1323）	1（开启）
tcp_slow_start_after_idle	空闲后是否重置拥塞窗口	0（关闭）

调优命令示例：

# 调整接收缓冲区
echo "4096 87380 16777216" > /proc/sys/net/ipv4/tcp_rmem

# 开启窗口缩放
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling

# 关闭空闲后慢启动
echo 0 > /proc/sys/net/ipv4/tcp_slow_start_after_idle

22.3 Nagle算法：小包合并的艺术

Nagle算法的初衷是好的：避免网络里充斥大量小包。它规定，只有收到前一个包的ACK，或者数据累积到MSS大小，才能发送下一个包。但有时候，它好心办坏事。

我做过一个实时游戏服务器，玩家操作指令都是小包。Nagle一开，延迟直接飙到200ms。玩家骂声一片。后来果断关掉，延迟降到20ms。

22.3.1 关闭Nagle算法

int flag = 1;
setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));

就这么一行代码。但注意：不是所有场景都适合关。如果你做的是大文件传输或批量数据上报，开着Nagle反而能提高吞吐量。

22.4 C10K问题：一万个连接怎么扛？

C10K，即 Concurrent 10,000 Connections。这个问题的本质是：当连接数上万时，传统的select/poll模型撑不住了。为什么？

• select：每次调用都要遍历所有fd，O(n)复杂度。fd数量有限制（默认1024）。
• poll：没有数量限制，但仍然是O(n)遍历。连接越多，效率越低。

解决方案其实就一条路：事件驱动 + 非阻塞IO。Linux下就是epoll，BSD下是kqueue，Windows下是IOCP。

22.4.1 epoll的核心用法

int epfd = epoll_create(1);
struct epoll_event ev, events[1024];

ev.events = EPOLLIN | EPOLLET;  // 边缘触发
ev.data.fd = listen_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev);

while (1) {
    int nfds = epoll_wait(epfd, events, 1024, -1);
    for (int i = 0; i < nfds; i++) {
        if (events[i].data.fd == listen_fd) {
            // 处理新连接
        } else {
            // 处理读写事件
        }
    }
}

这里有个关键点：边缘触发（ET） vs 水平触发（LT）。我个人的习惯是：

• ET模式：必须一次性把数据读完，否则不会再触发。效率高，但容易丢数据。
• LT模式：没读完会一直触发。代码好写，但多一次系统调用。

22.5 知识体系总览

下面这张图把本章的核心逻辑串起来了。你可以看到，性能优化从数据路径、传输控制、并发模型三个维度展开。

你看，零拷贝解决的是数据路径太长的问题，TCP调优解决的是传输效率问题，Nagle算法解决的是小包堆积问题，而C10K解决的是并发模型问题。四个方向缺一不可。

最后说一句：优化不是盲目调参。我见过有人把缓冲区调到128MB，结果内存爆了。也有人关掉Nagle后吞吐量暴跌。每个改动都要有数据支撑，用 netstat -s、ss -i、perf 这些工具盯着看。这才是工程师该有的态度。

---