不卖关子，直接聊正事。

网络编程这块，如果让新手列一个最头疼的清单，多路复用和IO模型肯定排前几。上一弹我们讲完了socket的基础流程：socket()、bind()、listen()、accept()、send()/recv()，这一套下来，能跑通一个客户端连服务端的简单Demo。但那只算入门，真到线上环境，阻塞IO和高并发这两个坎儿直接卡死一大半人。

这一弹的内容，核心就三件事：怎么控制IO的等待时间、怎么用多路复用处理大量连接、以及一套拿得出手的epoll实战写法。适合刚把socket流程跑通、想进一步接触高并发的人，也适合项目里被连接数困扰、想重构网络层的同学。

1. 先想清楚：为什么阻塞IO撑不住高并发

很多人写网络程序，第一个能跑通的模型就是“一次accept，然后recv等数据”。这种方式在连接数少、交互不频繁的场景下没问题，但一旦连接多了，立刻原形毕露。

1.1 阻塞IO的致命缺陷

阻塞IO的核心问题是：一个线程在一个时刻只能等一个文件描述符。当程序执行到recv()时，如果对面没发数据，整个线程就挂在那里，啥也干不了。如果你用“一个连接一个线程”的模型，那1000个连接就是1000个线程，这还不算完——线程切换的时间、内存占用、锁竞争，都会把服务器拖垮。

我做过一个模拟项目X，早期版本就是这种模型。压测到200个连接时，CPU使用率冲到90%以上，但吞吐量低得可怜。用top看，大部分CPU都耗在线程切换上，真正干活的没多少。后来我深刻明白一个道理：高并发不是靠多线程堆出来的，而是让有限的线程去服务尽可能多的连接。

1.2 非阻塞IO的引入

非阻塞IO就是解决这个问题的初步手段。你把socket设为非阻塞，recv()调用后如果没数据，不会傻等，而是直接返回错误码，通常是EAGAIN或EWOULDBLOCK。这样线程不会被卡住，可以去处理其他事情。

但这就带来一个新问题：你什么时候知道某个连接上有数据可读？你不能凭空猜，也不能一轮一轮地轮询所有连接（那样CPU消耗依然很大）。于是就有了多路复用：select、poll、epoll。它们做的事情本质上是一样的——帮你盯着所有关注的fd，当某个fd就绪时，告诉你“可以处理了”。

2. 超时控制：别让程序无限期傻等

在进入多路复用之前，先说一个看似简单但坑很多的问题：超时控制。阻塞IO下，recv()可能一直等不到数据，如果对端异常断连，程序就永久卡死。所以网络编程里，任何可能导致无限等待的操作，都必须加超时。

2.1 通过socket选项设置超时

Linux提供了两个socket选项：SO_RCVTIMEO和SO_SNDTIMEO，分别控制接收和发送超时。使用方式：

struct timeval tv; tv.tv_sec = 5; tv.tv_usec = 0; setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));

设置之后，recv()如果在5秒内没有收到数据，就会返回-1，errno是EAGAIN。这个方案的好处是简单、粒度细（针对单个fd），缺点是你必须为每个连接单独设置，而且超时后你只能自己处理后续逻辑。

注意：EAGAIN和EWOULDBLOCK在Linux上通常是同一个值，但代码里两个宏都判断一下比较稳妥，毕竟不同平台的处理不完全一致。

2.2 更常用的：多路复用的超时参数

多路复用函数本身就带超时参数，这也是我实际项目中更偏爱的方案。以select为例：

struct timeval timeout = {5, 0}; // 5秒 int ret = select(fd + 1, &readfds, NULL, NULL, &timeout);

select和poll的超时精度到毫秒级，epoll_wait的timeout参数单位是毫秒。用多路复用的超时参数，好处是当超时发生时，你可以统一处理所有连接的状态，比如发送心跳包、清理空闲连接，而不用在每个连接上分别设置socket超时。

2.3 超时时间设置的几个经验值

超时值的具体设定，跟业务场景强相关。这里分享我的几个实践参考：

• 连接建立超时：一般3~5秒。太短容易在老网络环境下误判，太长会堆积大量半连接。
• 读超时：如果协议是“请求-响应”模式，读超时可设15~30秒。如果数据量大或者链路慢，适当放宽。
• 写超时：写超时通常比读超时小，5~10秒足够。写操作超时多半意味着对端接收窗口满了，或者连接已经异常。

注意：超时时间不是越小越好。设置过短，正常处理稍慢的业务会被迫中断；设置过长，故障检测的速度跟不上，用户就会卡在等待里。建议根据业务接口的P99耗时来推算，给接口耗时上限留出至少2~3倍的余量。

3. 多路复用三兄弟：select、poll、epoll怎么选

多路复用这个词听着高大上，理解它的本质只需一句话：我们让内核帮我们检查一堆fd是否有事件发生，有的话告诉我。三兄弟的效率差异和适用场景差别很大，选错了后面会很难受。

3.1 select：简单但上限太低

select是资历最老的多路复用函数，核心是把关注的可读、可写、异常fd集合传给内核，内核检测后返回就绪的fd。

问题也很明显：

• fd上限被FD_SETSIZE限制，默认是1024。1024对现代服务器来说太小了，动辄上万连接的需求直接不满足。
• 每次调用都要把fd集合从用户态拷贝到内核态，调用频率越高，拷贝开销越大。
• 内核检测fd就绪是线性扫描，复杂度O(n)，fd一多，哪怕只有几个就绪，也要遍历完整个集合。

select适合的场景：连接数不多（几十个）、逻辑足够简单的小工具。说句实话，我工作这些年在生产环境已经很少见到select作为主力了，更多是教学场景或嵌入式环境下使用。

3.2 poll：突破了上限，但问题依旧

poll可以看作select的改进版：用pollfd数组代替fd集合，突破了1024的限制。但O(n)扫描的低效、每次调用重新传数组的拷贝开销，本质上没解决。

poll的额外好处是水平触发（LT）模式上处理起来比较直观：只要fd就绪，每次poll都会返回，不会丢事件。poll适合连接数在几千左右的场景，如果数量不大、没有超高性能要求，poll简单粗暴反而容易维护。

3.3 epoll：高并发下的主流答案

epoll是Linux专属的高性能IO多路复用方案。跟select/poll最大的差异在于事件通知机制：不是每次调用都要把fd列表传进去，而是先用epoll_ctl注册fd，之后epoll_wait专门等事件。

epoll的核心优势有三点：

1. 复杂度从O(n)降到O(1)：注册进去的fd由内核红黑树管理，就绪的fd通过回调机制挂到就绪链表上。epoll_wait只把就绪链表里的fd取出来，跟总fd数量无关。
2. 拷贝开销大幅降低：fd的信息在注册时就已经进入内核空间，不需要每次调用都重复拷贝。
3. 两种触发模式：水平触发（LT）和边沿触发（ET）。LT模式下，只要fd还有数据没读完，epoll_wait就会持续返回该fd；ET模式下，只有状态发生变化（比如从无数据变为有数据）时才通知一次。这个区别是很多bug的源头，后面我会详细展开。

3.4 三兄弟对比速查表

4. epoll实战：从接口到完整代码

前面讲了一堆原理，真正动手才是硬道理。下面这份代码是从某个跨平台系统的网络模块简化过来的，展示了epoll的核心使用方法。

4.1 epoll三件套：create、ctl、wait

epoll的使用就是三个函数：epoll_create1、epoll_ctl、epoll_wait。极简示例：

// 1. 创建epoll实例 int epfd = epoll_create1(EPOLL_CLOEXEC); if (epfd == -1) { perror("epoll_create1"); return -1; } // 2. 注册一个fd struct epoll_event ev; ev.events = EPOLLIN; // 关注可读事件 ev.data.fd = listen_fd; // 需要携带的私有数据，这里先用fd本身 epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev); // 3. 等待事件 #define MAX_EVENTS 64 struct epoll_event events[MAX_EVENTS]; int n = epoll_wait(epfd, events, MAX_EVENTS, -1); // -1表示永久阻塞 for (int i = 0; i < n; i++) { // 处理events[i] }

这里有几点要注意，都是以前踩过的坑：

• epoll_create1(EPOLL_CLOEXEC)比老式的epoll_create(0)更推荐，多了一个CLOEXEC标志，避免fork子进程后意外继承epoll fd。
• epoll_ctl有三个操作码：EPOLL_CTL_ADD、EPOLL_CTL_MOD、EPOLL_CTL_DEL。重复ADD会出错，删除之后再ADD又得重新填结构体。
• events数组的大小决定了单次epoll_wait最多能取回多少就绪事件，一般设置成与连接数相近的值，但也不必过大，64~256在多数场景够用。如果单批处理不过来，剩下的下次继续取。

4.2 完整的事件循环骨架

一个典型的epoll服务器长这样：

int main() { int listen_fd = make_socket_and_listen(8080); // 非阻塞 set_nonblocking(listen_fd); int epfd = epoll_create1(EPOLL_CLOEXEC); struct epoll_event ev, events[256]; ev.events = EPOLLIN; ev.data.fd = listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev); while (1) { int n = epoll_wait(epfd, events, 256, -1); for (int i = 0; i < n; i++) { int fd = events[i].data.fd; if (fd == listen_fd) { // 处理新连接 int conn_fd = accept(listen_fd, NULL, NULL); if (conn_fd < 0) continue; set_nonblocking(conn_fd); ev.events = EPOLLIN | EPOLLET; // 边沿触发 ev.data.fd = conn_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev); } else { // 处理普通连接的可读事件 handle_read(epfd, events[i]); } } } }

4.3 非阻塞socket的标准设置

epoll配合非阻塞IO是标配，听我一句劝：哪怕你打算用水平触发，也请把socket设为非阻塞。原因很简单——万一某个事件触发了，但你的业务逻辑里又调用了一个阻塞接口，整个事件循环就堵死了，后面所有fd都别想处理。

设置非阻塞的标准姿势：

void set_nonblocking(int fd) { int flags = fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK); }

先用F_GETFL取现有标志，再叠加O_NONBLOCK，不要直接赋值覆盖，否则会丢掉之前设置的标志位。

4.4 边沿触发（ET）的正确处理姿势

ET模式是epoll性能最好的模式，但也是最容易写bug的模式。核心原因是：ET模式下，fd状态发生变化时才通知一次，如果一次没把数据读完，剩余数据不会再次触发通知。

所以ET模式的接收循环必须一次性把数据读干净：

void handle_read(int epfd, struct epoll_event ev) { int fd = ev.data.fd; char buf[4096]; ssize_t n; while (1) { n = read(fd, buf, sizeof(buf)); if (n > 0) { // 处理数据 } else if (n == -1 && errno == EAGAIN) { // 数据读完了，正常退出循环 break; } else if (n == 0) { // 对端关闭，清理fd epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); close(fd); break; } else { // 其他错误，按连接异常处理 break; } } }

关键点就在EAGAIN的处理。read()返回-1且errno为EAGAIN时，说明socket缓冲区里的数据已经读空了，这是退出循环的正常信号。判断n == 0表示对端优雅关闭，记得从epoll里删除并close。

注意：read()返回0和对端正常关闭并不完全是一回事，但处理逻辑一样——关闭连接、释放资源。还有一种容易忽略的情况是EOF之前还有未读数据，此时read返回0但缓冲区里可能有残留，要结合协议层的数据完整性来判断是否需要处理。

4.5 LT和ET应该怎么选

这是很多人在选型上纠结的问题。我的建议非常直接：

• 第一次接触epoll，或者业务逻辑复杂、不想趟坑：用LT。它是默认模式，数据没读完就会持续通知，代码写起来省心，不容易漏数据。
• 追求性能、连接数巨大（比如上万级别）、并且你能保证每次事件触发都把数据处理完：用ET。

实际上，性能差异在连接数不多时几乎感知不到。ET多出来的那点性能提升，往往不如它带来的编码复杂度多。我见过太多人一上来就大张旗鼓上ET，结果数据没读完导致分包错乱，回头查半天才意识到是对模式理解有误。

5. 高并发单线程模型：一个线程如何扛住上万连接

有一个很经典的疑问：epoll明明只搞定了“监听多个fd”这一步，但真正处理数据还是在单个线程里，一个线程处理上万连接真的不会卡死吗？

5.1 事件循环的秘密：快进快出

关键思路是在事件循环里尽量不做耗时操作。每个fd的事件处理都应该像流水线一样：能直接处理的就直接处理，处理不了的就缓存起来，等条件满足再继续。比如一个HTTP请求，解析完请求头发现还没收完包体，就把半截数据放到这个连接对应的缓冲里，等下次可读事件来了接着解析。

只要事件处理函数能在微秒级别内返回，即使一个循环里同时有几百个就绪事件，处理完一轮也不会太慢。这就是为什么单线程epoll能扛住高并发——它不靠并行，靠的是切换速度快。

5.2 计算密集型业务怎么办

如果一个事件处理中需要执行耗时任务，比如压缩图片、加解密、跑算法，直接在事件循环里执行就会把后续所有连接堵住。这时候需要把任务丢到一个线程池里异步处理。

线程池方案下，epoll线程只做收包、解析协议、分发任务，真正干重活的在线程池中。处理完成后，线程池通过管道或eventfd向epoll发送一个唤醒信号，把结果塞回写缓冲区，让epoll线程统一执行发送。

5.3 eventfd：线程间通信与事件唤醒

在线程池和epoll线程协作时，eventfd是个好东西。它本质上是一个内核维护的计数器fd，可以写入数据来唤醒epoll_wait：

int wake_fd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC); // 线程池完成处理后： uint64_t one = 1; write(wake_fd, &one, sizeof(one)); // 唤醒epoll_wait

epoll主循环把wake_fd注册进去，一旦线程池写入，epoll_wait立即返回，主线程就能去检查任务队列、执行后续发送。这种设计的巧妙之处在于避免了锁竞争和忙等，唤醒成本极低。

6. 高频踩坑点：连接处理、EOF、惊群与fd耗尽

下面这部分是真正值钱的，都是我调试过的真实问题和方法论。每一条都有血泪教训在里面。

6.1 accept之后必须判断是否该立即注册读事件

新手常见的错误：accept拿到新连接，立刻注册EPOLLIN，就等数据来。但有些连接上来后根本不发数据，或者很久才发，这个连接就一直挂在epoll里。

更稳妥的做法是：accept后先设置非阻塞，然后注册一个EPOLLOUT或EPOLLIN事件，根据业务决定合适的时机。比如有些服务会主动发送欢迎语，那就在注册EPOLLOUT时顺手发送；如果完全没有数据要下发，就不必急着注册读事件。

6.2 正确处理accept返回的EAGAIN

在非阻塞模式下，accept也可能返回EAGAIN。典型场景：有连接到达，但还没等你的代码accept，另一个线程已经把它处理了。此时accept()会返回-1，errno是EAGAIN或ECONNABORTED。

正确姿势：

while (1) { int conn_fd = accept(listen_fd, NULL, NULL); if (conn_fd < 0) { if (errno == EAGAIN || errno == ECONNABORTED) { break; // 没有新连接了 } // 其他错误需要处理 continue; } // 处理这个conn_fd... }

忽略EAGAIN可能导致accept陷入无限空转，这点在多线程同时listen的场景下尤其突出。

6.3 惊群问题：多个线程/进程同时epoll_wait

如果你用多个线程或进程同时epoll_wait同一个epoll fd，一个连接到达时，可能多个等待者同时被唤醒，但只有一个能accept成功，其余人白醒一场，这就是惊群（thundering herd）。

Linux 2.6之后通过内核机制已经解决了大部分场景，但为了绝对稳妥，还是建议：只有一个线程负责listen和accept，其他线程通过任务队列获取已连接的fd。如果要多进程分摊accept压力，可以用SO_REUSEPORT让内核在多个监听socket之间做负载均衡。

6.4 fd耗尽：处理连接数上限

默认情况下，进程的文件描述符上限可能只有1024，这就是为什么你明明注册了成千上万的连接，程序却报“Too many open files”。需要调整两个地方：

# 调整系统级限制 sysctl -w fs.file-max=100000 # 调整进程级限制（临时） ulimit -n 100000

需要永久生效就改/etc/security/limits.conf，把nofile的硬限制和软限制都调大。调完之后记得重启进程，因为ulimit对已启动的进程无效。

还有一个容易忽略的点：net.core.somaxconn控制listen队列的长度。如果并发连接数大，但accept处理速度跟不上，连接就会在等待队列里积压，给客户端表现为连接超时。需要调大：

sysctl -w net.core.somaxconn=1024

同时，listen()的backlog参数也要相应增大，这个参数真正决定了单个socket的等待队列长度。

6.5 半关闭状态与TIME_WAIT

如果一个连接上收到了EOF但你还想往对端发送数据，就需要用到shutdown(fd, SHUT_RD)，只关闭读方向，保留写能力。注意，TCP协议下，主动关闭连接的一方在连接close后，socket会进入TIME_WAIT状态，持续2*MSL（通常约2分钟）。

服务器作为主动关闭方时，大量TIME_WAIT会导致端口资源紧张。解决方法是：

• 代码层面尽量由客户端主动关闭连接，或者设置SO_LINGER主动丢弃。
• 系统层面设置net.ipv4.tcp_tw_reuse = 1，允许复用TIME_WAIT状态的连接（只对主动发起连接一方有效）。

6.6 EPOLLIN和EPOLLOUT同时注册的副作用

有些人为了减少epoll_ctl调用次数，把EPOLLIN和EPOLLOUT一起注册。但实际运行时，如果socket缓冲区一直有空闲，EPOLLOUT会一直触发，导致你的循环凭空多出大量无用唤醒。正确的做法是：平时只关注EPOLLIN，需要发送数据时再采用EPOLL_CTL_MOD临时加上EPOLLOUT，数据发完再改回去。

7. 一个完整的回显服务器：可直接抄的作业

说了这么多，用一个完整的回显服务器把前面知识点串起来。这个Demo用单线程epoll+LT模式，数据读多少回多少，代码粒度小、逻辑清晰。

#define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <errno.h> #include <sys/epoll.h> #include <sys/socket.h> #include <netinet/in.h> #include <netinet/tcp.h> #define PORT 8080 #define MAX_EVENTS 256 static void set_nonblocking(int fd) { int flags = fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main(void) { int listen_fd = socket(AF_INET, SOCK_STREAM, 0); if (listen_fd < 0) { perror("socket"); return 1; } int opt = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); struct sockaddr_in addr; memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_addr.s_addr = htonl(INADDR_ANY); addr.sin_port = htons(PORT); if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) { perror("bind"); return 1; } if (listen(listen_fd, 64) < 0) { perror("listen"); return 1; } set_nonblocking(listen_fd); int epfd = epoll_create1(EPOLL_CLOEXEC); if (epfd < 0) { perror("epoll_create1"); return 1; } struct epoll_event ev, events[MAX_EVENTS]; ev.events = EPOLLIN; ev.data.fd = listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev); printf("echo server listening on port %d\n", PORT); while (1) { int n = epoll_wait(epfd, events, MAX_EVENTS, -1); if (n < 0) { if (errno == EINTR) continue; // 信号中断，重新等待 perror("epoll_wait"); break; } for (int i = 0; i < n; i++) { int fd = events[i].data.fd; if (fd == listen_fd) { // 处理新连接 while (1) { int conn_fd = accept(listen_fd, NULL, NULL); if (conn_fd < 0) { if (errno == EAGAIN || errno == ECONNABORTED) break; continue; } set_nonblocking(conn_fd); ev.events = EPOLLIN; ev.data.fd = conn_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev); } } else { // 可读：读出所有数据再原样写回 char buf[4096]; ssize_t rn, wn, off = 0; while (1) { rn = read(fd, buf + off, sizeof(buf) - off); if (rn > 0) { off += rn; continue; } if (rn == 0) { // EOF，关闭连接 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); close(fd); break; } if (errno == EAGAIN) { // 数据读完了，写入返回 while (off > 0) { wn = write(fd, buf + off, off); if (wn > 0) { memmove(buf, buf + wn, off - wn); off -= wn; } else if (wn < 0 && errno == EAGAIN) { continue; // 写缓冲区满，等下次 } else { // 写失败，异常关闭 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); close(fd); off = 0; break; } } off = 0; break; } // 其他读错误 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); close(fd); break; } } } } return 0; }

这份代码虽然简化了一些错误分支，但在实际环境中跑起来是没问题的。你可以用nc或ab压测工具去连接测试。我调试这份代码时还发现一个有意思的坑：如果发送的数据量远超接收缓冲区，read会持续返回EAGAIN吗？不会。它只会在缓冲区的数据快读完时才返回空闲。所以在写事件里稍微处理了一下，避免缓冲区写满时死等。

8. 调试技巧与工具：如何肉眼定位问题

代码写完之后，真正痛苦的是调试。这里分享几个我常用的调试思路和工具。

8.1 strace：网络程序调试的第一选择

strace能追踪进程的系统调用，让你看到每一次read/write/epoll_wait的确切行为。使用方式：

strace -f -e trace=network,epoll,read,write -p 1234

-f跟踪子进程，-e trace指定要追踪的系统调用类型，-p指定进程号。当你怀疑数据没有被正确读取、或者epoll没有触发时，strace的输出能让你一眼看出问题所在。比如你发现epoll_wait一直返回，但没有对应的accept调用，那八成是epoll_ctl注册时出了错。

8.2 ss和lsof：检查连接状态

排查连接问题最常用的两个命令：

ss -antp | grep 8080 lsof -i :8080

ss显示当前连接状态，lsof展示哪些进程占用了端口。如果你看到大量ESTABLISHED连接但程序没反应，往往是accept速度跟不上，或者事件循环里的处理逻辑阻塞住了。

8.3 tcpdump + Wireshark

当问题在应用层排查不清时，用tcpdump抓包看TCP层行为：

tcpdump -i any port 8080 -w echo.pcap

抓到包之后用Wireshark打开，能直接看到SYN、ACK、PSH、FIN这些标志位的时序。如果客户端发了数据，但服务端一直不回ACK，说明内核协议栈那一层就有问题；如果ACK正常但应用层没有输出，那个问题一定出在你的event loop里。

8.4 善用日志：连接生命周期记录法

线上调试最有效的方法之一，是给每个连接维护一个简单的状态机，在关键节点打日志：

• 连接accept：记录对端IP、端口、fd编号
• 数据到达：记录当前socket缓冲区里累积的数据量
• 数据发送完成：记录本次发送了多大数据
• 连接关闭：记录关闭原因、连接生命周期总长

有了这些日志，你再配合前端展示连接状态，就能快速定位“数据哪去了”的问题。

9. 性能调优进阶：从能用走到好用

最后聊聊性能调优的进阶方向。这部分没有标准答案，但有一些经过验证的思路。

9.1 一个线程真的够吗

单线程epoll能扛住大量并发连接，但扛不住多核CPU的计算能力。现代服务器动辄几十核，单线程模型相当于只用了一颗核。如果你的服务是纯IO密集型的，单线程也许够用；但一旦涉及协议解析、业务计算，建议采用线程池+epoll混合模型。

一个稳妥的架构是：

• 1个主线程：负责accept、分发连接
• N个工作线程：各自维护独立epoll实例，处理被分发的连接

这种模式下，每个连接固定归某个线程管理，天然避免锁竞争。连接按fd取模或哈希分配到线程，实现很直接。

9.2 SO_REUSEPORT：多进程负载均衡

如果嫌线程不够，可以用多进程模型，每个进程独立listen同一个端口。设置SO_REUSEPORT后，内核会把新连接平分给各个进程。这样能充分利用多核，而且某个进程崩溃不会导致整个服务挂掉。

int reuse = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEPORT, &reuse, sizeof(reuse));

注意，所有进程必须在listen之前就设置这个选项，否则第二次bind会失败。

9.3 零拷贝：sendfile与splice

如果你有大量静态文件需要发送（比如文件服务器），每次从内核缓冲区复制到用户态再写回，等于白做两次拷贝。Linux提供sendfile()系统调用，数据直接在内核空间从文件拷贝到socket，不在用户态停留。

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

splice则能实现两个fd之间的数据重定向，不经过用户态。这些零拷贝手段对性能提升非常显著，尤其在大规模文件传输场景下，CPU占用可能直接降一个数量级。

9.4 读写缓冲区的合理设置

socket内核缓冲区大小对性能影响也很大。默认的接收缓冲区可能才几十KB，高吞吐场景下会造成频繁的通知和拷贝。可以通过SO_RCVBUF和SO_SNDBUF调大：

int rcvbuf = 1024 * 1024; // 1MB setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &rcvbuf, sizeof(rcvbuf));

注意，内核会把这个值翻倍（因为结构体开销），并且有上下限，不是你填多少就一定是多少。设置完后用getsockopt回读一下，确认实际生效值。

结尾的个人经验

这一弹写到这里，核心的知识点都覆盖了。我个人在实际项目里踩过一次大坑，就是一开始太迷信ET模式，结果数据没读完就退出循环，导致客户端收到的响应被截断，排查了一整天才发现是对ET语义理解不到位。后来我学乖了：没有足够必要，绝不轻易在核心链路上用ET模式，性能差异远不像理论分析里那么大，但编码复杂度却是实打实的。

另外想提醒一点，学习网络编程最好的方式是复现+改造。找一份小而精的epoll服务端代码（就像上面那份回显服务器），先把它跑通，然后逐步往里面加协议解析、连接池、超时机制、日志输出。当你把它改造成一个完整的业务服务时，你对事件驱动模型的理解就真正到位了。

最后小技巧分享：在调试网络程序时，先保证系统调用这一层不犯错，再去看业务逻辑。我排查问题的顺序永远是：strace看系统调用行为，ss看连接状态，tcpdump看数据包，最后才去看业务代码。按这个套路来，绝大多数疑难杂症都能在30分钟内定位到根因。