网络编程优化：epoll vs select/poll，零拷贝技术（sendfile），TCP_NODELAY
网络编程这块，说白了就是跟数据收发较劲。我早年做嵌入式网关的时候，一台设备要扛几百路TCP连接，那时候用的还是select，结果CPU动不动就飙到80%。后来换成epoll，同样的硬件，CPU直接降到15%。你说这差距大不大？
今天咱们就聊聊网络编程里三个最关键的优化点：I/O多路复用的选型、零拷贝技术、以及那个容易被忽略的TCP_NODELAY。这三个东西，任何一个没用好，你的网络程序性能都会大打折扣。
1. I/O多路复用：从select到epoll的进化
先说说select。这玩意儿是POSIX标准里的老古董了。它的工作方式很简单——你把一堆文件描述符丢给它，它一个个轮询，看哪个有数据来了。问题在哪？
- 最大连接数限制：默认1024，改内核参数也有限
- 每次都要全量拷贝：把fd_set从用户态拷到内核态，再拷回来
- O(n)轮询：连接越多，轮询越慢
poll呢？它解决了1024的限制，但O(n)轮询的问题还在。说白了，poll就是select的"大号版"，本质没变。
epoll就不一样了。它是Linux 2.6之后引入的，专门为高并发设计的。它的核心思想是——只通知你"哪些fd就绪了"，而不是让你自己去查。
关键区别：
- select/poll：每次调用都要把全部fd传给内核，内核遍历一遍，返回就绪的fd
- epoll：注册一次，内核维护一个事件表，有事件发生时主动回调，只返回就绪的fd
我当年在做一个物联网平台的时候，设备连接数从500涨到2000，select直接扛不住了。换成epoll的ET模式（边缘触发），配合非阻塞I/O，CPU占用反而降了。嗯，这里有个坑——ET模式必须循环读取直到返回EAGAIN，否则会漏事件。
// epoll 使用示例（边缘触发 + 非阻塞）
int epfd = epoll_create1(0);
struct epoll_event ev, events[64];
ev.events = EPOLLIN | EPOLLET; // 边缘触发
ev.data.fd = listen_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev);
while (1) {
int n = epoll_wait(epfd, events, 64, -1);
for (int i = 0; i < n; i++) {
if (events[i].events & EPOLLIN) {
// 必须循环读，直到 EAGAIN
char buf[4096];
while (1) {
ssize_t r = read(events[i].data.fd, buf, sizeof(buf));
if (r == -1 && errno == EAGAIN) break;
// 处理数据...
}
}
}
}我的建议：
新项目直接上epoll，别犹豫。如果是在嵌入式Linux上，内核版本够的话也用epoll。select/poll只适合连接数很少（几十个以内）的简单场景。
2. 零拷贝技术：sendfile 与 mmap
传统的数据发送流程是什么样的？你从磁盘读文件，然后通过socket发出去。这中间数据要拷贝好几次：
- 磁盘 → 内核缓冲区（DMA拷贝）
- 内核缓冲区 → 用户缓冲区（CPU拷贝）
- 用户缓冲区 → socket缓冲区（CPU拷贝）
- socket缓冲区 → 网卡（DMA拷贝）
四次拷贝！而且步骤2和3还涉及两次上下文切换（用户态↔内核态）。
零拷贝技术就是要把中间那两次CPU拷贝干掉。sendfile就是干这个的——它直接把数据从内核缓冲区送到socket缓冲区，完全绕过用户空间。
// 传统方式：先读再写
char buf[4096];
int n = read(file_fd, buf, sizeof(buf));
write(sock_fd, buf, n);
// 两次系统调用，两次拷贝
// 零拷贝方式：sendfile
off_t offset = 0;
sendfile(sock_fd, file_fd, &offset, file_size);
// 一次系统调用，零次CPU拷贝我记得有一次做视频流媒体服务器，文件传输占用了大量CPU。换成sendfile之后，CPU占用直接降了60%。而且sendfile还支持DMA硬件加速，如果你的网卡支持，性能还能再上一个台阶。
还有一个零拷贝技术叫mmap。它把文件映射到进程地址空间，读写文件就像读写内存一样。但mmap有个坑——如果文件被截断或修改，映射区域会出问题。我在项目中遇到过，mmap映射一个大日志文件，结果日志轮转时程序直接段错误。所以mmap适合只读场景，或者你能保证文件不被修改的场景。
注意：
sendfile在Linux 2.6.33之后支持跨文件系统传输。如果源文件和目标socket不在同一个文件系统，某些老内核版本可能不支持。建议先检查内核版本。
3. TCP_NODELAY：别让Nagle算法坑了你
TCP默认开启Nagle算法。这个算法的目的是——攒够了数据再发，减少小包数量。但问题来了：如果你的应用需要低延迟，比如游戏、实时控制、交互式协议，Nagle算法反而成了绊脚石。
Nagle算法的规则很简单：
- 如果发送的数据小于MSS（最大报文段大小），且还有未确认的数据，那就等
- 等到之前的数据确认了，或者攒够了MSS，再发
你想想看，如果你的协议是"发一个请求，等一个响应"这种模式，Nagle算法会导致每个请求都延迟几十毫秒。这就是所谓的Nagle延迟确认综合征。
// 关闭 Nagle 算法
int flag = 1;
setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));
// 之后每次 write 都会立即发送
write(sock_fd, data, len); // 不再等待攒包我做过一个工业控制协议，要求响应时间在10ms以内。一开始没关Nagle，结果延迟经常跳到50ms以上。查了半天才发现是Nagle在作怪。关了之后，延迟稳定在3-5ms。
但也不是所有场景都适合关Nagle。如果你传输的是大文件或者流媒体，Nagle反而能提高吞吐量。我的原则是：交互式、低延迟场景关掉它；批量传输场景保持默认。
避坑指南：
我曾经在一个项目中，同时用了TCP_NODELAY和TCP_CORK，结果两个选项冲突，导致发送行为异常。TCP_CORK是"攒包发送"的极端版，跟NODELAY正好相反。这两个不要同时用。
4. 实战建议：如何组合使用
在实际项目中，这三个优化点往往是组合使用的。我总结了一个简单的决策表：
| 场景 | I/O模型 | 数据传输 | TCP选项 |
|---|---|---|---|
| 高并发Web服务器 | epoll（水平触发） | sendfile（静态文件） | 默认（Nagle开启） |
| 实时控制/游戏 | epoll（边缘触发） | 直接write（小包） | TCP_NODELAY |
| 文件传输服务 | epoll（水平触发） | sendfile | 默认或TCP_CORK |
| 嵌入式低功耗设备 | epoll（边缘触发） | mmap（只读数据） | TCP_NODELAY |
最后说一句，网络优化不是一锤子买卖。我习惯先用perf或者strace看看系统调用开销，找到瓶颈再针对性优化。有时候你费了半天劲优化了epoll，结果发现瓶颈在磁盘I/O上，那就白干了。先测量，再优化，这是铁律。