1. 先说清楚：为什么我还要写一份Linux网络编程指南
做了这么多年Linux后端和嵌入式开发，我太清楚网络编程这摊水有多深了。市面上的资料要么是教科书式的理论推演，要么是复制粘贴的demo堆砌，真正能从"客户端connect上服务器"讲到"高并发下epoll为什么还是被Linux内核调度器坑了"的文章少得可怜。这篇东西就是把我这些年踩过的坑、验证过的结论、以及面试时最喜欢问的底层细节一次性整理出来，希望能帮那些刚入门的兄弟少走弯路，也让有一定基础的朋友对着查漏补缺。
先说清楚这篇文章覆盖的内容范围：从Socket编程模型入手，讲到TCP协议栈行为对应用层的真实约束，然后花大篇幅拆IO多路复用的演进逻辑——从select到poll再到epoll，每层都解释"为什么需要它、它解决了什么、它又引入了什么新问题"，最后聊几个真正影响线上业务的高级特性，比如TCP_NODELAY、SO_REUSEADDR、非阻塞IO与LT/ET模式配合时的注意点。整篇文章以Linux C/Python混合视角来写，重点放在原理和实战取舍上，而不是API手册复读。
如果你是刚刚接触网络编程，或者已经被select、epoll这些概念绕晕了，又或者写了好几年业务代码但说不清"为什么服务端必须listen、客户端不需要"这类问题，这篇文章都适合你。我尽量做到每个结论都能追溯到内核行为或协议规范，而不是"大家都这么写所以这么写"。
2. Socket编程底层逻辑：从一次connect看TCP状态机的真实运转
2.1 服务器端Socket全流程：每一个系统调用背后发生了什么
先来一个最常见的服务端初始化代码，我用C语言写，因为最贴近内核接口。
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <arpa/inet.h> #include <sys/socket.h> int main() { int listen_fd = socket(AF_INET, SOCK_STREAM, 0); if (listen_fd < 0) { perror("socket"); exit(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_port = htons(8080); addr.sin_addr.s_addr = htonl(INADDR_ANY); if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) { perror("bind"); exit(1); } if (listen(listen_fd, 128) < 0) { perror("listen"); exit(1); } while (1) { struct sockaddr_in client_addr; socklen_t len = sizeof(client_addr); int conn_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &len); if (conn_fd < 0) { perror("accept"); continue; } printf("accept connection from %s:%d\n", inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port)); close(conn_fd); } return 0; }这段代码里每一步都有讲究。socket()创建的不是连接，而是一个文件描述符，它对应内核中的一个socket对象，这个对象内部维护着发送缓冲区、接收缓冲区、等待队列等一系列数据结构。bind()把socket对象和一个具体的IP:端口绑定，注意INADDR_ANY表示监听所有网卡地址，如果你只希望某个内网网卡提供服务，这里就要改成具体IP。
listen()做了两件关键的事情：第一，把socket状态从CLOSED切换到LISTEN；第二，创建全连接队列（accept队列）和半连接队列（SYN队列），参数128表示全连接队列的最大长度。这个参数在很多老代码里写的是5或者10，但在高并发场景下，如果accept处理速度跟不上连接建立速度，这个队列一旦满了，内核就会丢弃新的SYN包，客户端表现就是connect超时。
这里有个很多新手完全没意识到的问题：accept()返回的不是你调用listen()的那个fd，而是一个全新的fd。listen_fd始终留在监听状态，每个新连接都有自己独立的conn_fd，有自己的读写缓冲区，互不干扰。所以服务端的fd数量会随着连接数增长，这就是为什么高并发服务必须考虑文件描述符上限。
2.2 客户端视角：connect的阻塞与超时阈值
客户端代码相对简单：
int sock_fd = socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in server_addr; memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_port = htons(8080); inet_pton(AF_INET, "127.0.0.1", &server_addr.sin_addr); int ret = connect(sock_fd, (struct sockaddr *)&server_addr, sizeof(server_addr)); if (ret < 0) { perror("connect"); close(sock_fd); return -1; }connect()内部发生的是TCP三次握手：客户端发送SYN，服务端回复SYN+ACK，客户端再回ACK。三次握手完成前，客户端这个fd的状态是SYN_SENT，服务端对应连接状态是SYN_RECV。
一个非常实际的问题：connect超时时间到底由谁决定？Linux内核里，TCP的SYN重传次数由/proc/sys/net/ipv4/tcp_syn_retries控制，默认是6次，加上指数退避算法，总超时时间大约127秒。这就是为什么你connect一个不存在的IP时，程序会卡在那里一分多钟才报错。如果你写的是客户端工具，建议给connect设置超时，方法是将fd设为非阻塞，然后通过select/poll/epoll等待可写事件，再调用getsockopt(SO_ERROR)获取真实的连接结果。
// 非阻塞connect超时控制核心逻辑 int ret = connect(fd, ...); if (ret < 0 && errno == EINPROGRESS) { struct timeval tv = {3, 0}; // 3秒超时 fd_set wset; FD_ZERO(&wset); FD_SET(fd, &wset); if (select(fd + 1, NULL, &wset, NULL, &tv) > 0) { int err = 0; socklen_t len = sizeof(err); getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &len); if (err == 0) { // 连接成功 } } }这里的核心原理是：非阻塞connect发起后，握手过程在内核协议栈中继续，用户态通过等待"可写事件"来感知握手完成。但可写事件也可能是连接失败（比如对端RST），所以必须用SO_ERROR确认结果，这是高手和新手之间一个很明显的分界线。
2.3 TIME_WAIT、CLOSE_WAIT：让无数人栽跟头的两个状态
先看一段线上排障的经典输出：
$ ss -ant | head -20 State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* ESTAB 0 0 192.168.1.10:8080 192.168.1.20:54321 TIME_WAIT 0 0 192.168.1.10:8080 192.168.1.20:54322 CLOSE_WAIT 14 0 192.168.1.10:8080 192.168.1.20:54323TIME_WAIT是被动关闭方（通常是先发送FIN的一方）的状态，需要等待2MSL（默认60秒）后才彻底消失。存在意义有两个：一是确保最后的ACK能到达对端，如果ACK丢失，对端会重发FIN，此时如果连接已经销毁，对端会收到RST而不是正常关闭；二是防止旧连接的延迟数据包干扰新连接，因为不会有相同四元组的新连接在2MSL内被建立。
但是CLOSE_WAIT就是另一个故事了。CLOSE_WAIT意味着对端已经发了FIN，而本端程序还没调用close()关闭这个fd。大部分CLOSE_WAIT堆积的根因是业务代码忘了关闭fd，比如某个分支里read返回0或-1之后没有close，或者用了多线程但每个线程持有同一个fd的副本，只关闭了其中一个。
我记得有一次排查一个Java网关大量CLOSE_WAIT，最后发现是HTTP keep-alive连接被对端关闭后，框架内部的连接池没有及时感知，重试逻辑又把旧连接拿出去用。这种问题靠调内核参数是治标不治本，必须从业务代码层面保证"所有路径最终都会close"。
3. 数据收发与缓冲区：read/write的语义远比你想的复杂
3.1 流式协议没有消息边界：这是TCP最反直觉的特性
TCP是流协议，不是消息协议。这句话我强调多少遍都不过分。很多新手写了个send()就以为对端会一次性recv()到同样长度的数据，实测经常出现：客户端连续发送三次"hello"共15字节，服务端一次recv()可能返回10字节，第二次返回5字节。反过来，客户端一次发送100KB，服务端可能分10次recv()才能读完。
原因在于数据从应用层到内核缓冲区，再到网卡、传输链路的每一层都会做了拆分和合并。TCP有MSS（最大分段大小，默认1460字节）约束，超过就要分段；Nagle算法会把小包合并成大包再发；接收方的内核缓冲区也可能因为调度顺序把连续的数据一次性交给应用层。
所以TCP编程必须自己处理粘包和半包。常用方案有三种：
- 固定长度消息：每个消息固定N字节，不足补零，适合指令类场景。
- 长度前缀法：消息头固定4字节（uint32_t网络字节序）表示消息体长度，然后跟上消息体。这是最通用的方案。
- 特殊分隔符：消息以\n或\r\n结尾，适合文本协议，但要注意消息体里不能出现该分隔符。
我实测过一个典型场景：用Python的socket发送结构化的二进制协议数据，如果不用长度前缀做分包，对端C语言程序解析会崩得一塌糊涂。后来统一改为"4字节长度头+payload"格式，再也没出过问题。这个约定最好在做架构设计时就定下来，而不是等到联调出问题再补。
3.2 缓冲区与阻塞语义：为什么read返回0就表示对端关闭
每个TCP socket在内核里都有两个缓冲区：发送缓冲区（send buffer）和接收缓冲区（recv buffer）。write()/send()调用实际上是把数据从用户空间拷贝到内核发送缓冲区，然后内核协议栈异步地把数据发出去。read()/recv()则是把内核接收缓冲区里的数据拷贝到用户空间。
一个关键细节：阻塞模式下，read()返回0的唯一含义是对端关闭了连接（收到了FIN），不要把它和"没有数据"混为一谈。如果对端只是暂时没发数据，read()会一直阻塞在那里，直到有数据或者连接关闭。
非阻塞模式下，read()返回-1且errno==EAGAIN或EWOULDBLOCK才表示"当前没有数据可读"，此时需要等待可读事件再次触发。这个ECONNRESET的errno也常见，意思是对端发送RST强制关闭连接，通常是因为对端进程崩溃、或者往一个已经关闭的连接上写数据。
还有一点很多人忽略：write()成功并不等于数据到达对端。它只表示数据拷贝到了本端内核缓冲区，之后可能丢失（比如中途网络断开对端没收到）。TCP只能保证"如果连接存在且最终正常关闭，数据不重不漏"，无法保证实时到达。对于强一致性场景，必须业务层做ACK确认。
3.3 SO_SNDBUF和SO_RCVBUF：修改缓冲区会影响什么
内核默认的收发缓冲区大小可以通过/proc/sys/net/ipv4/tcp_rmem和tcp_wmem查看，默认一般在几十KB到几百KB范围内动态调整。但业务上经常需要主动控制：
int send_buf_size = 1024 * 1024; // 1MB setsockopt(sock_fd, SOL_SOCKET, SO_SNDBUF, &send_buf_size, sizeof(send_buf_size)); int recv_buf_size = 1024 * 1024; setsockopt(sock_fd, SOL_SOCKET, SO_RCVBUF, &recv_buf_size, sizeof(recv_buf_size));注意，内核实际设置的缓冲区大小会是设定值的两倍，因为内核要为sk_buff等管理结构预留额外空间。你设1MB，实际可用可能是2MB。调大接收缓冲区可以减少因缓冲区满导致的内核丢弃数据包，提升吞吐；调大发送缓冲区则能提高write()的吞吐峰值，让应用层写入更少被阻塞。
不过缓冲区不是越大越好。太大意味着单连接占用的内存多，高并发下内存压力剧增；而且缓冲区太大在延迟敏感场景下会让报文积压，反而增加了端到端延迟。一般的建议是，先跑业务压测，观察ss -anp里每个socket的Send-Q和Recv-Q是否经常处于接近上限的值，如果经常满，才需要调整。
4. IO多路复用：从select到epoll，不只是API换了
4.1 select的局限：为什么它撑不起高并发
select是最早的多路复用接口，它的工作方式是：每次调用都传入三个fd集合（可读、可写、异常），内核遍历这些fd，检查是否有事件发生，然后把就绪的fd集合返回给用户态，用户态还要再次遍历去处理。
fd_set read_fds; FD_ZERO(&read_fds); FD_SET(listen_fd, &read_fds); FD_SET(conn_fd, &read_fds); struct timeval timeout = {5, 0}; int ret = select(max_fd + 1, &read_fds, NULL, NULL, &timeout); if (ret > 0) { for (int fd = 0; fd <= max_fd; fd++) { if (FD_ISSET(fd, &read_fds)) { // 处理该fd的可读事件 } } }select的问题至少有四个：第一，fd集合大小有上限，通常1024，改内核宏重新编译才能扩大；第二，每次调用都要把整个fd集合从用户态拷贝到内核态，fd多时开销惊人；第三，内核需要线性扫描所有fd，时间复杂度O(n)；第四，用户态拿到结果后，不知道具体是哪些fd就绪，又要线性扫描一遍。
所以select在几百个并发连接时还能勉强撑住，上千就开始明显吃力，上万基本不可用。但不少老项目还在用select跑长连接，主要是代码改动成本太高，属于历史包袱。
4.2 poll：修掉了上限，但没修掉性能
poll把fd_set换成了struct pollfd数组，摆脱了1024上限，改成了动态数组的fd数目，但每次调用仍然要把整个数组从用户态拷贝到内核态，内核仍然要线性遍历所有fd检查事件，用户态仍需遍历数组找到就绪的fd。时间复杂度还是O(n)，只是n的上限变大了。
struct pollfd fds[1024]; fds[0].fd = listen_fd; fds[0].events = POLLIN; int ret = poll(fds, 1024, 5000); if (ret > 0) { for (int i = 0; i < 1024; i++) { if (fds[i].revents & POLLIN) { // 处理 } } }poll在几千个连接时比select稍微从容点，但没有改变"海量fd无差别遍历"的本质问题。另一个小坑是POLLIN和POLLOUT的事件处理要特别注意共存的极端情况：一个socket同时可读可写时，如果代码里只处理了POLLIN忘了处理POLLOUT，会导致写事件一直pending，在某些内核版本上可能表现为性能抖动甚至活锁。虽然不是普遍问题，但我确实见过线上代码靠反复全面poll掩盖了处理逻辑遗漏。
4.3 epoll：事件驱动到底赢在哪
epoll是Linux特有的高效IO多路复用方案，核心数据结构是红黑树+就绪链表。每次epoll_ctl()注册一个新的fd监听事件时，在内核里向红黑树插入一个节点；当fd上有事件发生时，内核通过回调机制把fd挂载到就绪链表中。epoll_wait()调用时只是把就绪链表里的fd返回给用户态，如果没有就绪事件，进程睡眠。
int epfd = epoll_create(1024); struct epoll_event ev; ev.events = EPOLLIN; ev.data.fd = listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev); struct epoll_event events[1024]; while (1) { int n = epoll_wait(epfd, events, 1024, -1); for (int i = 0; i < n; i++) { int fd = events[i].data.fd; if (fd == listen_fd) { // accept新连接 } else if (events[i].events & EPOLLIN) { // 处理读事件 } } }对比select/poll，epoll有三个本质区别：第一，拷贝开销消失：fd集合在注册时就已经交给内核，不需要每次调用重复拷贝；第二，扫描开销消失：内核只需要维护就绪链表，epoll_wait返回的数量最多是就绪事件数，而不是总fd数；第三，时间复杂度：注册O(log n)，等待O(就绪数)，基本只受事件数影响。
但epoll有两个典型陷阱。第一个是EPOLLET边缘触发：默认是水平触发（LT），只要缓冲区有数据就会持续通知；ET模式下，fd从不可读到可读只会通知一次，如果这次没读完，后续不会再通知，必须循环read直到EAGAIN。ET的好处是减少系统调用次数，坏处是一旦代码处理不当，数据会滞留在缓冲区里永远没机会被处理。我见过生产事故：一个ET模式网关程序某次read循环没判断EAGAIN就退出，结果该连接上后续数据全部卡死，客户端以为服务器hang住了。第二个陷阱是在多线程模型里，多个线程同时对同一个epoll fd调用epoll_wait()时，如果一个fd事件被唤醒，多个线程可能同时被唤醒并处理同一事件，需要额外的锁或者busy loop检查来避免重复处理。
4.4 epoll + 非阻塞IO的正确组合
高并发服务几乎都是"epoll + 非阻塞IO + 事件循环"的搭配。原因很简单：如果socket是阻塞的，当epoll_wait告诉你这个fd可读，你调用read()可能需要一次或多次才能读完；如果数据量很大，比如100MB，阻塞read会阻塞整个事件循环线程，其他fd的事件无法及时处理，整个服务就停了。
标准做法是：accept返回的新conn_fd立刻设置O_NONBLOCK，然后在事件循环里用read/write处理，每次read循环到EAGAIN为止。这里有个细节：accept()本身也要考虑EAGAIN。如果你用LT模式，accept前最好再确认一下listen_fd确实可读；如果用ET模式，accept需要循环调用直到返回EAGAIN，否则可能只accept了队列里的一小部分连接，剩下的连接虽然全连接队列里排着队，但不会再次触发可读事件，客户端就会一直等待服务端accept。
// ET模式下accept的正确姿势 while (1) { int conn_fd = accept(listen_fd, (struct sockaddr *)&cli_addr, &len); if (conn_fd < 0) { if (errno == EAGAIN || errno == EWOULDBLOCK) { break; } else { perror("accept"); break; } } set_nonblocking(conn_fd); epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev); }这个"循环accept到EAGAIN"的细节，是ET模式最容易踩的坑之一，也是面试官最喜欢追问的细节。
5. 高级特性实战：把每个选项参数的含义彻底搞清楚
5.1 TCP_NODELAY：Nagle算法和延迟ACK的相爱相杀
Nagle算法是TCP层为了减少小包数量设计的：如果发送缓冲区里有未被ACK的数据，新数据必须拼接到旧数据后面一起发，核心逻辑是"一次只能有一个未确认的小包"。这个算法在处理交互式命令（比如Telnet）时能合并大量小包，减轻网络拥塞。但在现代业务里，它经常成为延迟的元凶。
问题是Nagle算法和TCP延迟ACK机制会互相配合产生额外的等待：Nagle等ACK才发新数据，延迟ACK最多等40ms才回ACK（为了把ACK和数据一起捎带），两个机制叠加，就可能出现一个小的写请求多等40ms的情况。虽然实际中两个机制有时会因为"半关闭"或数据量等条件被打破，但延迟问题确实难以彻底避免。
对低延迟要求高的场景（比如RPC调用、游戏服务端），建议直接关闭：
int flag = 1; setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));这个选项的作用是禁用Nagle算法，让每个write()都立即触发TCP段发送，不用等ACK合并。代价是可能导致大量小包，增加网络开销。但如果每次write的数据本来就接近MSS，关闭Nagle的影响就很小。
5.2 SO_REUSEADDR和SO_REUSEPORT：别再被bind失败折磨
做过服务端的人应该都遇到过"bind: Address already in use"。最典型场景是服务崩溃后，旧连接还处在TIME_WAIT状态，立即重启服务时报错。解决方法是：
int opt = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));SO_REUSEADDR允许新监听socket绑定到处于TIME_WAIT状态的地址端口组合。因为TIME_WAIT的socket四元组和新的监听socket不冲突（一个是已建立的连接，一个是监听socket），但默认情况下内核仍然禁止这种bind，开启这个选项后就可以顺利重启。
还有一个进阶选项是SO_REUSEPORT，它允许多个socket监听同一个IP:端口，内核自动做负载均衡。这在多进程/多线程模型中很好用：每个worker进程单独创建监听socket，都设置SO_REUSEPORT，内核根据连接hash决定新连接进入哪个进程。实测环境下，SO_REUSEPORT能显著减少多进程抢accept锁的竞争问题。但注意内核版本需要3.9+，而且要求所有复用端口的socket都设置该选项，否则不生效。
int reuse_port = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEPORT, &reuse_port, sizeof(reuse_port));5.3 SO_LINGER：控制close()到底等不等数据发完
默认情况下，close()返回后，内核仍然会尝试把发送缓冲区里剩余的数据发送出去，只是close()立即返回，不等待确认。如果你需要确保数据可靠送达，可以设置SO_LINGER：
struct linger lg; lg.l_onoff = 1; lg.l_linger = 0; // RST发送，丢弃未发送数据 setsockopt(sock_fd, SOL_SOCKET, SO_LINGER, &lg, sizeof(lg));l_linger=0的特殊含义是：close()时立即发送RST而不是FIN，丢弃缓冲区所有未发送数据。这在某些场景下有意为之（比如放弃一个不正常连接），但如果在业务高峰期误用，会导致对端收到RST，表现为主机崩溃一样的错误。更常用的设置是l_linger=30，close()会阻塞直到发送缓冲区数据发完或30秒超时，但这个阻塞可能让调用方线程卡住，所以用之前要评估链路可靠性。
实际项目中，除非有必须的可靠性要求，否则我不建议轻易动SO_LINGER。默认的四次挥手关闭流程在绝大多数情况下是合理的。唯一常见用例是避免大量TIME_WAIT堆积——用RST关闭连接可以不进入TIME_WAIT，但代价是抛弃了可靠关闭语义，对端可能读到不完整的数据流。
5.4 TCP_KEEPALIVE：应用层心跳之外的最后防线
网线被拔了、对端机器断电、路由器故障，TCP连接不会主动感知，可能一直保持ESTABLISHED状态。内核提供的TCP keepalive机制定时探测对端是否存活，默认配置是：
tcp_keepalive_time：7200秒（2小时）无数据传输后开始探测tcp_keepalive_intvl：75秒（每75秒探测一次）tcp_keepalive_probes：9次（连续9次无响应视为断开）
2小时对于绝大多数业务来说太长了。可以在应用层设置：
int keep_alive = 1; setsockopt(sock_fd, SOL_SOCKET, SO_KEEPALIVE, &keep_alive, sizeof(keep_alive)); int keep_idle = 60; // 60秒无数据后开始探测 int keep_intvl = 10; // 每10秒探测一次 int keep_cnt = 3; // 3次无响应视为断开 setsockopt(sock_fd, IPPROTO_TCP, TCP_KEEPIDLE, &keep_idle, sizeof(keep_idle)); setsockopt(sock_fd, IPPROTO_TCP, TCP_KEEPINTVL, &keep_intvl, sizeof(keep_intvl)); setsockopt(sock_fd, IPPROTO_TCP, TCP_KEEPCNT, &keep_cnt, sizeof(keep_cnt));但keepalive不是万能的，它只能确认对端主机网络栈还能响应，不能确认对端进程是否活着。比如java进程死锁、goroutine全部阻塞，TCP栈可能照常响应ACK。所以关键业务还是必须自己设计应用层心跳机制：定期发送心跳包，超时未收到就主动断开重连。
5.5 非阻塞IO和事件循环里write返回EAGAIN的处理
非阻塞socket在发送缓冲区满时，write()会返回-1且errno=EAGAIN。新手常常把这种情况当错误处理直接close，结果就是数据莫名丢失、连接莫名断开。正确处理是：把数据放入用户态待发送队列，注册EPOLLOUT事件，等待缓冲区有空间后再发送。
// 伪代码示例 void on_write_ready(int fd) { while (1) { ssize_t n = send(fd, send_buf + sent_len, send_len - sent_len, 0); if (n > 0) { sent_len += n; if (sent_len == send_len) { // 数据全部发完，注销EPOLLOUT事件 epoll_ctl(epfd, EPOLL_CTL_MOD, fd, &ev_without_write); break; } } else if (n < 0 && errno == EAGAIN) { // 缓冲区满，继续等待EPOLLOUT break; } else if (n < 0) { // 真实错误，关闭连接 close(fd); break; } } }一个容易忽略的问题：EPOLLOUT是水平触发时，只要发送缓冲区没满，这个事件会不断触发。所以如果没数据要发，千万不要注册EPOLLOUT，否则就是空转烧CPU。正确做法是"有数据待发送"时才注册，发完立刻注销。
这个模型就是高并发网络服务器的基础：一份数据从read到处理到write，每个阶段都在事件循环中流转，任何一步遇到缓冲区满或数据没到齐，都要靠状态机挂起，等待相应事件再继续。
6. 实战案例：手写一个支持万级并发连接的echo服务器
把前面的概念串起来，写一个完整的C语言echo服务器：epoll + ET + 非阻塞IO + 简单的协议解析框架。
#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 <arpa/inet.h> #define MAX_EVENTS 1024 #define BUFFER_SIZE 8192 static void set_nonblocking(int fd) { int flags = fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main() { int listen_fd = socket(AF_INET, SOCK_STREAM, 0); 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_port = htons(8080); addr.sin_addr.s_addr = htonl(INADDR_ANY); bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)); listen(listen_fd, 128); set_nonblocking(listen_fd); int epfd = epoll_create(1024); struct epoll_event ev, events[MAX_EVENTS]; 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, MAX_EVENTS, -1); if (n < 0) { perror("epoll_wait"); continue; } for (int i = 0; i < n; i++) { if (events[i].data.fd == listen_fd) { // accept所有连接直到EAGAIN while (1) { struct sockaddr_in cli_addr; socklen_t len = sizeof(cli_addr); int conn_fd = accept(listen_fd, (struct sockaddr *)&cli_addr, &len); if (conn_fd < 0) { if (errno != EAGAIN && errno != EWOULDBLOCK) { perror("accept"); } break; } set_nonblocking(conn_fd); ev.events = EPOLLIN | EPOLLET; ev.data.fd = conn_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev); } } else { // echo逻辑：读多少回写多少 int fd = events[i].data.fd; char buf[BUFFER_SIZE]; while (1) { ssize_t n = read(fd, buf, sizeof(buf)); if (n > 0) { ssize_t offset = 0; while (offset < n) { ssize_t w = write(fd, buf + offset, n - offset); if (w > 0) { offset += w; } else if (w < 0 && errno == EAGAIN) { // 写缓冲区满，这里需要挂起等待EPOLLOUT，简化实现直接退出 // 实际生产代码要用待发送队列 break; } else { close(fd); break; } } if (n < sizeof(buf)) { // 数据读完了 break; } } else if (n == 0) { // 对端关闭 close(fd); break; } else { if (errno == EAGAIN) { // ET模式数据读完 break; } close(fd); break; } } } } } return 0; }这个echo服务器基本结构可以直接扩展成各种业务服务器：把read到的数据丢进业务逻辑队列，处理完后通过EPOLLOUT事件把响应发回去。注意代码里write缓冲区满时的处理简化了，生产环境必须实现发送队列和EPOLLOUT注册。这里想表达的是：事件循环的心智模型就是"等事件、处理事件、注册新事件"三件事循环往复，理解了这个模型，看Redis、Nginx等源码会轻松很多。
7. 排查网络问题的工具箱：从工具输出反推内核状态
7.1 ss和netstat：先看连接状态再下手
排查线上网络问题，我第一件事就是跑ss -ant，这个命令比netstat快且信息更多。重点关注：
- LISTEN队列溢出：
ss -lnt里的Send-Q表示accept队列最大长度，Recv-Q表示当前排队的连接数量。如果Recv-Q长期接近Send-Q，说明accept处理速度跟不上。 - TIME_WAIT堆积：高并发短连接场景下，TIME_WAIT几万个很常见，但会占用fd和内存。如果严重到影响新连接，可考虑开启
tcp_tw_reuse（仅对客户端有效）或调整tcp_fin_timeout。 - CLOSE_WAIT堆积：重点是找代码里没close的路径，不是调参能解决的。
$ ss -lnt State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 128 128 0.0.0.0:8080 0.0.0.0:*Recv-Q接近128说明accept队列满了，客户端会开始connect超时。
7.2 tcpdump抓包：三次握手和四次挥手一抓见分晓
当连接建立或断开的行为不符合预期时，抓包是最直观的手段：
$ sudo tcpdump -i eth0 tcp port 8080 -nn -A观察SYN、SYN+ACK、ACK的来回顺序，就能判断握手在哪一步断了。比如只看到客户端发SYN，服务端没回SYN+ACK，可能是服务端全连接队列满，把SYN丢了；或者防火墙直接丢弃了SYN包。断开时如果看到RST而不是FIN，说明某端主动异常终止，往往是代码里设置了SO_LINGER l_linger=0或者进程崩溃时内核发了RST。
7.3 压测工具选型
- ab：简单场景够用，但单线程模型压不了高并发。
- wrk：基于epoll的高性能压测工具，适合测吞吐和延迟分布。
- locust：Python编写，脚本灵活，适合模拟业务复杂场景。
- 自定义压测客户端：如果测试的是私有二进制协议，直接用Python的socket库写并发脚本，注意用gevent或asyncio做协程并发，不要用线程，线程GIL会成为瓶颈。
压测时一定要看延迟分布，不要只看平均延迟。TCP编程里，P99和P999延迟往往能反映出缓冲区配置、Nagle算法是否关闭等问题。平均延迟100ms、P999延迟2000ms的系统，和平均延迟120ms、P999延迟180ms的系统，前者的问题明显更严重。
8. 我踩过的那些坑：几条能帮你省一周时间的经验
最后分享几个我实际经历过、并且花了不少时间才搞明白的坑，希望对你有直接帮助。
第一个教训：不要把阻塞IO和非阻塞IO混在一个线程里用。之前接手过一个老项目，accept返回的fd没有设置非阻塞，但事件循环里又用了epoll，导致某个连接的读事件触发后，阻塞read把整个线程卡死，其他所有连接全部延迟。最后排查了一整天才定位到是某个连接被对端发了个超大包，read阻塞等待完整数据。这种问题在测试环境不容易出现，因为测试数据量小，生产环境一个配置错误的客户端就能触发。
第二个教训：SO_REUSEADDR不是万能的，别指望它能解决所有bind失败问题。如果你遇到的是"Address already in use"且ss -ant里看不到TIME_WAIT，可能是另一个进程还在监听这个端口，或者有TCP连接处于LAST_ACK等非TIME_WAIT状态。这时候开启SO_REUSEADDR也救不了，需要查进程、清理连接。先把问题定位准确再动手，不要盲目叠选项。
第三个教训：TCP性能调优不是单点调一个参数就能见效的。我曾经为了优化一个文件传输服务的吞吐，单独调大了SO_SNDBUF、关了Nagle、调了内核的tcp_rmem，结果性能反而下降了。后来用iperf3测了基线，发现瓶颈在网卡队列和中断处理，调socket参数完全没用。所以调优前务必先做基线测试，确认瓶颈在TCP还是业务代码。
第四个教训：不要在代码里用sleep来等待网络事件。见过不少代码"参考"阻塞IO，在非阻塞模型里循环read + sleep(1)，这种设计从根上就是错的。事件循环的优势在于等待不消耗CPU，一旦引入sleep，要么延迟无意义地增大，要么CPU空转。如果遇到"不知道什么时候有数据"，正确方法是注册事件并用epoll_wait等待，而不是轮询。
9. 下一步往哪走：从会写到写得好，中间还差这些功课
到这里，Socket、IO多路复用和常见高级特性基本讲完了。但Linux网络编程的深度远不止如此，如果你在工作中继续深入，下面这些主题值得继续研究：
- Reactor与Proactor模式：理解Redis单线程Reactor为什么能扛高并发，Netty的EventLoop又是怎么回事。一句话版本：Reactor通过IO多路复用驱动事件循环，业务处理在回调中执行；Proactor把IO读写都交给内核完成，事件通知的是"IO已完成"，Linux的io_uring就是Proactor方向。
- io_uring：Linux 5.1+引入的异步IO接口，直接操作SQE/CQE队列，减少系统调用次数，在高IOPS场景下优势明显。很多新项目已经开始用liburing封装它了。
- 内存拷贝优化：sendfile、splice、零拷贝技术解决的是"从磁盘到网卡"的数据搬运问题，不用经过用户态缓冲区。大文件传输场景下，性能提升非常显著。
- TCP拥塞控制算法：cubic是Linux默认，但数据中心内部网络用bbr效果更好。需要改内核参数或者模块加载策略。
- 用户态协议栈：DPDK、AF_XDP这些技术把网卡数据直接到用户态处理，绕过内核协议栈，是超高性能网关的方向。但复杂度极高，一般业务用不上，了解一下原理即可。
我个人的体会是，Linux网络编程学习的核心不是记API，而是建立"数据从进程到网卡再对端进程，中间每一步有哪些机制参与"的完整图景。当你看到一个问题，能想起"这个行为可能是Nagle、延迟ACK、缓冲区满、拥塞控制中的哪一个导致的"，你就已经超过绝大多数只写业务代码的工程师了。
写到现在，这些内容基本覆盖了标题里承诺的范围。如果你在实际开发中遇到了其他奇怪的问题，欢迎按照文章里的排查思路自己推演一遍，大部分问题都能从内核状态和协议行为上找到答案。
