我给自己这套Linux学习笔记起了个代号叫“木下”没啥特别含义就是当时电脑桌面上放着个木雕摆件。从进程、信号一路看到网络通信突然发现很多之前学得模模糊糊的概念到了TCP这里全串起来了。这篇内容是整个“木下系列”里我整理得最久的部分因为网络通信不像写个printf那么直观数据包发出去之后内核帮你干了什么、你自己该干什么界限非常清楚也很容易踩坑。这篇内容想解决的问题很具体理解TCP协议状态写出一版能跑的TCP服务端和客户端搞懂多客户端并发该怎么选模型以及遇到报错时怎么定位。适合刚学完C语言基础、想往Linux后端方向走的开发者也适合那些用各种框架封装惯了、想回头看看socket底层逻辑的人。看完之后至少你手里会有一套可以直接编译跑的代码以及一份排查问题的速查清单。1. 为什么我把TCP当作Linux系统编程的必修课1.1 从单个程序的思维走到“多个程序协作”前面学文件IO、进程、线程时你面对的都是单台机器上的资源。进程间通信用管道、共享内存绕来绕去终究是一台机器内部的事。但真实的后端服务几乎没有单机封闭的。哪怕你写一个最简单的管理后台浏览器连过来走的也是HTTPHTTP下面就是TCP。所以TCP不是一个“可选进阶项”而是程序从单机走向网络的第一步台阶。很多教材喜欢把socket单独拎出来讲好像它是一个神秘对象。实际上Linux里一切皆文件socket照样是一个文件描述符只不过它是一个“可以跨机器读写”的文件描述符。读它就是从远端收数据写它就是向远端发数据。你用read、write去操作它和操作普通文件在接口层面没有本质区别。这个视角一旦建立起来理解accept、close这些调用就顺畅得多。不过我当年写第一版回显服务时还是被它狠狠教育了一顿。问题不在于socket函数不会用而在于我完全没意识到“网络是不可靠的”对方可能断网、进程可能崩溃、数据可能迟到。本地文件读写错了你给我报个错就行网络通信错了你得自己设计机制去发现和处理。这也是我认为TCP值得花整块时间学习的原因它逼着你从“写功能”过渡到“写防御性代码”。1.2 TCP解决的核心问题TCP全称Transmission Control Protocol传输控制协议。它在IP协议只负责“尽力送达”的基础上补上了三件事可靠性丢包重传、顺序性按序交付、流量控制接收方跟不上时发送方得降速。这三件事听起来平平无奇但底层工程实现极其复杂。序列号怎么设计、确认应答怎么处理、重传超时怎么计算、窗口怎么滑动随便展开都是一本书。系统编程层面你倒不需要把拥塞控制算法背得滚瓜烂熟但必须理解“TCP是一个有状态的协议”双方连接不是一条固定管道而是一系列状态机的迁移。你会发现Linux里很多socket选项本质都是在调整这个状态机的行为比如等多久、重传几次、断开时是否立刻丢弃缓冲数据。不理解状态机遇到TIME_WAIT、CLOSE_WAIT、Address already in use这类报错就只能搜一个答案抄一个答案换个环境又抓瞎。下面这一节我先把协议的状态机讲清楚后面所有代码和调优都建立在它之上。2. 先把手握热TCP协议本身的核心状态2.1 三次握手连接从来不是“直接建立”的很多资料让你背诵客户端发SYN服务端回SYNACK客户端再发ACK连接建立。这个顺序本身没错但容易让人产生一个错觉好像三次握手是某个设计者拍脑袋定出来的流程。其实它要解决的问题非常实际网络上有延迟和重放怎么确认双方都做好了收发准备我第一次理解三次握手是在想“为什么不是两次”的时候。假设只有两次客户端发SYN服务端回SYNACK就算建立。那如果客户端第一个SYN因为网络拥堵被延迟了客户端等不及重发了一个SYN服务端收到第二个SYN并响应了连接建立后双方愉快通信。结果延迟的那个旧SYN又漂到服务端服务端无法区分这是旧请求又回了个SYNACK于是凭空多出一条空连接浪费资源。三次握手的作用就是让双方各自确认“自己发的包对方能收到对方发的包自己也能收到”。用生活里的话说两个人互相喊话A喊“能听到吗”B回“能听到你能听到我吗”A再回“我也能听到”这才算建立起了双向通话。序列号也在握手过程中同步完成后续数据传输才能按序组装。这个机制从1981年定下来到现在一直没变过够说明它的成熟度。2.2 四次挥手和TIME_WAIT关闭比建立更麻烦关闭连接为什么需要四次因为建立时双方可以直接同步进入就绪状态但关闭时每一方都要独立表达“我这边数据发完了准备收摊”。主动关闭方发FIN对方回ACK这算确认了第一方的关闭请求。但另一方可能还有数据没发完所以它不能立刻跟着发FIN得等到自己的数据发完再发FIN然后主动方回ACK。这套流程本身不难真正坑人的是TIME_WAIT状态。主动关闭方在发出最后一个ACK后并不会立刻释放连接而是进入TIME_WAIT默认等2MSL报文最大生存时间的两倍通常60秒左右才消失。为什么非要等两个原因一是担心最后一个ACK丢了对方收不到会重发FIN你得保留状态以便重发ACK二是防止旧连接里的延迟数据包漂到新连接里搞乱新连接的数据。我实际写服务器时最常遇到的一个问题就是服务端主动关闭连接后端口被TIME_WAIT占着立刻重启监听同端口会报Address already in use。解决办法后面会专门写这里你先记住TIME_WAIT不是bug是TCP的自我保护任何绕过它的操作都要想清楚代价。比如把TIME_WAIT调成0或直接设置SO_LINGER关闭连接虽然端口释放快了但可能会吞掉未发送完的数据属于用正确性换便利。2.3 窗口、流量控制与拥塞控制简谈TCP的可靠传输不是“发一个等一个”这么笨那样效率太低。它用滑动窗口机制接收方在ACK里带上自己还能收多少字节发送方在这个窗口内可以连续发多个包不用等单个确认。窗口大小和接收缓冲区剩余空间直接相关这就是为什么Linux的socket缓冲区大小设置会直接影响吞吐量。拥塞控制则是另一套独立机制它管的是“网络本身能不能承受这么多数据”。最直观的算法就是慢启动刚开始拥塞窗口很小每收到一轮确认就翻倍快速增长。等到了阈值附近转为线性增长避免把网络堵死。如果出现丢包重传拥塞窗口会大幅缩小。你在应用层看到的现象就是网速忽快忽慢其实底层一直在做这种动态调整。系统编程的同学不必实现这些算法内核都做好了。但你要理解一点TCP的性能不是你写了个write就完事的它受对端处理速度、网络延迟、缓冲区、拥塞状态多方面影响。所以当你发现发送很慢别急着怀疑代码并发有问题先用工具看看是不是被流控卡住了。3. 动手跑代码之前的环境准备3.1 开发环境与基础工具这篇内容里的代码全部是C语言在Linux环境下编译运行。不需要装什么重型IDE一个编辑器加gcc就够。我建议你在虚拟机或者云主机上装一个纯净的Linux发行版不要带图形界面的那种这样更贴近生产环境。编译器版本不用讲究gcc 4.8以上就能编译这些代码。调试工具我会用到几个gcc、gdb可能用不上、strace、ss和tcpdump。tcpdump需要root权限如果没装就用包管理器装一下。我个人习惯是先用ss看端口状态再用strace看系统调用最后才上tcpdump抓包。三个工具层层递进基本能解决所有socket层面的疑难杂症。编译时有个参数值得一提编译时建议加上-Wall -Wextra把警告全部暴露出来。网络编程的bug往往不是语法错误而是逻辑边界问题比如没有判断accept返回-1、没有处理read返回0。开了警告能帮你提前发现很多低级问题。3.2 先理清文件描述符和socket的关系socket函数返回一个int这个int就是文件描述符fd。普通文件和socket在文件描述符表里地位一样所以能用read和write操作它们。但socket有自己的特殊性它有缓冲区读操作不一定等到缓冲区填满才返回写操作也不一定把数据立刻发出去。进程每次调用socket、open、accept内核都会返回一个当前进程中最小的可用fd。这个特性看起来不起眼但解释了一个经典bug如果你忘了close某些fdfd号会不停增长直到耗尽新socket创建失败。我排查过一个连接数上不去的问题最后发现就是fd泄漏进程可以打开的fd数量是有限的默认1024调大只是延缓问题根本解法是确保每个连接关闭。另一个必须建立的概念是阻塞和非阻塞。默认创建的socket是阻塞的accept在等新连接时进程会挂起read在等数据时进程也会挂起。这种模式写起来简单但没法同时服务多个连接后面要讲的select和epoll本质就是把“等”这件事交给内核统一管理。4. 手写第一个TCP服务器从socket到accept4.1 完整代码一个回显服务器我先贴出完整代码然后逐段解释。这个服务器的功能很简单接受到客户端的连接后把客户端发来的数据原样返回直到对方关闭连接。#include stdio.h #include stdlib.h #include string.h #include unistd.h #include errno.h #include arpa/inet.h #include sys/socket.h #define SERVER_PORT 9000 #define BACKLOG 128 int main() { int lfd socket(AF_INET, SOCK_STREAM, 0); if (lfd 0) { perror(socket); exit(EXIT_FAILURE); } int reuse 1; if (setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, reuse, sizeof(reuse)) 0) { perror(setsockopt); close(lfd); exit(EXIT_FAILURE); } 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(SERVER_PORT); if (bind(lfd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); close(lfd); exit(EXIT_FAILURE); } if (listen(lfd, BACKLOG) 0) { perror(listen); close(lfd); exit(EXIT_FAILURE); } printf(echo server listening on port %d\n, SERVER_PORT); while (1) { struct sockaddr_in cliaddr; socklen_t clilen sizeof(cliaddr); int cfd accept(lfd, (struct sockaddr *)cliaddr, clilen); if (cfd 0) { if (errno EINTR) { continue; } perror(accept); continue; } char ipbuf[INET_ADDRSTRLEN]; inet_ntop(AF_INET, cliaddr.sin_addr, ipbuf, sizeof(ipbuf)); printf(client connected: %s:%d\n, ipbuf, ntohs(cliaddr.sin_port)); char buf[1024]; while (1) { int n read(cfd, buf, sizeof(buf)); if (n 0) { printf(client closed\n); break; } if (n 0) { if (errno EINTR) { continue; } perror(read); break; } if (write(cfd, buf, n) 0) { perror(write); break; } } close(cfd); } close(lfd); return 0; }这段代码可以直接编译运行gcc -Wall -Wextra -o echo_server echo_server.c。启动后用nc 127.0.0.1 9000随便发几行字测试会看到内容被原样返回。4.2 每一步为什么必须这么写先说socket(AF_INET, SOCK_STREAM, 0)。AF_INET表示IPv4地址族SOCK_STREAM表示字节流套接字0是协议号通常指TCP由内核根据“流套接字”自动选定。如果这里不小心写成SOCK_DGRAM那就变成UDP了后续调用connect、listen都会表现出完全不同的语义。bind的作用是给监听fd绑定IP和端口。我用INADDR_ANY表示监听本机所有网卡地址端口是9000。这里有个新手常犯的错端口和IP在网络传输时用网络字节序大端本机计算时用主机字节序所以需要htons、htonl做转换。你如果忘了htons经常出现监听了一个完全不对的端口排查半天才发现。listen里第二个参数BACKLOG表示已完成握手但还没被accept取走的连接队列长度。这个值不是无脑开大就行它受内核参数somaxconn限制超出部分会被内核截断。Linux默认是4096左右你填128算是合理的保守值。有些框架喜欢填1024甚至更大但如果并发真的到了那种程度你的业务逻辑一定得是异步的不然accept不过来队列再长也会满。accept返回一个新的fd叫cfd监听fd lfd继续负责接收新连接。这是TCP和UDP一个巨大差异UDP只有一个socket谁发数据都能收TCP必须先握手每个客户端连接独占一个通信fd。accept返回值必须判错因为高并发下系统资源不足时accept可能返回-1且errno是ENFILE或EMFILE这时你如果直接continue可能陷入空转正确做法是短暂sleep一下再继续给内核释放资源的时间。4.3 这个服务器最大的问题一次只能服务一个客户端上面代码能跑但它天生有缺陷while循环里嵌套了read死循环必须等当前客户端的连接关闭才会回到accept。也就是说如果第一个客户端连上后一直不发数据第二个客户端就永远无法被接受即使微服务框架里这叫“串行阻塞”生产环境根本不能这么玩。另外注意read和write的返回处理。read返回0表示对端正常关闭返回-1表示出错其中EINTR表示被信号打断需要重试。这两种情况都必须在代码里显式处理否则要么死循环空转要么误判连接状态。很多C语言教程为了演示方便把这些细节全部省略但作为学习者必须补上网络编程的稳定性就是靠这些边界判断堆出来的。5. 写一个能用的TCP客户端连接、收发与协议设计5.1 最简单的客户端代码服务端有了自然得有个客户端。下面这个客户端从标准输入读数据发到服务端然后打印回显内容。#include stdio.h #include stdlib.h #include string.h #include unistd.h #include arpa/inet.h #include sys/socket.h int main(int argc, char *argv[]) { if (argc ! 3) { fprintf(stderr, usage: %s server_ip server_port\n, argv[0]); exit(EXIT_FAILURE); } int fd socket(AF_INET, SOCK_STREAM, 0); if (fd 0) { perror(socket); exit(EXIT_FAILURE); } struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_port htons(atoi(argv[2])); if (inet_pton(AF_INET, argv[1], addr.sin_addr) 0) { perror(inet_pton); close(fd); exit(EXIT_FAILURE); } if (connect(fd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(connect); close(fd); exit(EXIT_FAILURE); } char buf[1024]; while (fgets(buf, sizeof(buf), stdin) ! NULL) { size_t len strlen(buf); if (write(fd, buf, len) 0) { perror(write); break; } int n read(fd, buf, sizeof(buf)); if (n 0) { printf(server closed\n); break; } write(STDOUT_FILENO, buf, n); } close(fd); return 0; }connect是这里的关键调用。它一旦返回0三次握手就完成了。connect不仅是一个系统调用它会让当前进程阻塞直到连接建立或超时。默认超时时间受内核参数影响大概在75秒到两分钟这个范围对某些交互场景来说太长了后面会讲怎么用非阻塞connect加select来做超时控制。5.2 read/write两兄弟的隐藏差异客户端和服务端代码里都用read和write很多学过Linux文件IO的人会习以为常。但在socket场景下它们的行为和普通文件IO有明显差异。普通文件read往往能一次性读到你要求的长度socket则不一定它只返回当前缓冲区里已经有的数据可能比你要求的小也可能一次返回多条拼接的数据。write也是同一个道理它只保证“把参数指定的字节放入发送缓冲区”不保证这些字节真正到达对端更不保证一个write对应一次网络包发送。Nagle算法可能把多个小write合并成一个包发送接收方也可能一次read读到多个write拼起来的数据。这就是传说中的粘包问题。在Linux下你还可以用recv和send替代read和write优势在于第四个参数可以传标志比如MSG_NOSIGNAL可以避免写已关闭连接时触发SIGPIPE信号MSG_WAITALL能在阻塞模式下尽量等满字节数再返回。不过MSG_WAITALL本质还是“尽量”遇到EOF或错误照样提前返回别依赖它解决业务问题。5.3 粘包和半包应用层协议怎么设计这里讲一个我实际踩过的坑。写一个简单的二进制协议时我每帧数据用“4字节长度若干字节内容”的格式。对方发消息时我图省事用send把整个帧发出去了结果对方一次recv并没有把完整帧收完我只处理了半包后续数据全错位了。正确做法是应用层自己维护消息边界接收方必须循环读取直到凑齐一个完整帧。设计协议有三种主流思路定长消息、分隔符、长度前缀。定长最简单但浪费空间分隔符适合文本协议比如HTTP的换行头长度前缀最常用可表达任意长度二进制数据。处理流程是先读固定长度的头解析出正文长度再继续读直到收到那么多字节。操作中必须用循环累加直到收满需要的大小。这里再补充一个经验千万不要假设一次read能拿到所有数据在测试环境小数据量时可能没问题生产环境一旦数据变长问题立刻爆发。5.4 给connect加上可控超时默认connect可能卡很久但如果服务端没监听或IP不通内核其实很快会返回ECONNREFUSED或EHOSTUNREACH真正卡住的是网络黑洞SYN包发出去没人理这时就得等内核超时。生产环境里客户端卡死是灾难级的所以建议给connect加超时。常用做法是先设置非阻塞调用connect再用select或poll等待可写事件同时设置时间上限。看起来多几行代码但能避免线程池里几十个连接一起挂起。类似地read也可能长时间无数据可以通过setsockopt设置SO_RCVTIMEO来控制这个选项设置后阻塞read在超时后会返回-1并设置errno为EAGAIN或EWOULDBLOCK。我测试过这个方案比非阻塞加轮询简单能覆盖大多数场景。6. 处理多客户端从阻塞IO到多路复用6.1 通用方案一连接一线程前面那个回显服务器显然不合格因为它只能同时服务一个连接。最直观的改进是accept到一个连接后创建一个线程去处理这个连接主线程继续accept。Linux下可以用pthread库来写。这个方案在小规模并发下完全可行逻辑简单清晰每个连接读写互不干扰。但问题也明显线程不是免费的。每来一个连接就创建一个线程多线程调度开销和内存占用会迅速膨胀。虽然可以用线程池复用但每个连接在等待数据时都占着一个线程线程只能阻塞在read上白白占用栈内存默认线程栈通常8MB几千个连接内存就吃紧了。所以对高并发网络服务主流的套路是固定几个线程配合IO多路复用一个线程能同时监控几百上千个fd。下面几节介绍的select、poll、epoll就是“一个线程管大量fd”的三种实现方式。6.2 select和poll为什么慢慢不够用select的思路简单粗暴每次调用它之前把你关心的fd集合复制给内核内核阻塞扫描一旦有事件就返回用户程序再遍历所有fd检查哪个就绪了。它的缺点刚好是致命的三点fd数量上限通常被限制为1024每次调用都要重新构造并复制fd集合效率低返回后你必须全部轮询一遍才能找到就绪fd复杂度O(n)。poll解决了fd上限问题改成链表组织但仍没解决“每次都要全量扫描”和“返回后要轮询”这两大痛点。当连接数到几千后你会发现CPU都在做无意义的遍历真正的业务计算反而没分到多少资源。这也是为什么现代Linux服务器几乎不用select/poll做高并发除非连接数量极小。6.3 epoll登场事件驱动而不是轮询epoll是Linux特有的IO多路复用机制它的核心设计是三件事epoll_create创建实例epoll_ctl注册你关心的fd和事件epoll_wait阻塞等待事件发生。内核只会返回真正就绪的fd不需要你全量扫描。注册的fd在内核里有事件表维护也不用每次复制集合。下面这段代码演示epoll版回显服务器重点看主循环的写法#include sys/epoll.h #include stdio.h #include stdlib.h #include string.h #include unistd.h #include errno.h #include arpa/inet.h #include sys/socket.h #define MAX_EVENTS 64 #define SERVER_PORT 9000 int main() { int lfd socket(AF_INET, SOCK_STREAM, 0); if (lfd 0) { perror(socket); exit(EXIT_FAILURE); } int reuse 1; setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, reuse, sizeof(reuse)); 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(SERVER_PORT); if (bind(lfd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); exit(EXIT_FAILURE); } if (listen(lfd, 128) 0) { perror(listen); exit(EXIT_FAILURE); } int epfd epoll_create1(0); if (epfd 0) { perror(epoll_create1); exit(EXIT_FAILURE); } struct epoll_event ev; ev.events EPOLLIN; ev.data.fd lfd; if (epoll_ctl(epfd, EPOLL_CTL_ADD, lfd, ev) 0) { perror(epoll_ctl); exit(EXIT_FAILURE); } struct epoll_event events[MAX_EVENTS]; while (1) { int nready epoll_wait(epfd, events, MAX_EVENTS, -1); if (nready 0) { if (errno EINTR) continue; perror(epoll_wait); break; } for (int i 0; i nready; i) { int fd events[i].data.fd; if (fd lfd) { int cfd accept(lfd, NULL, NULL); if (cfd 0) { perror(accept); continue; } ev.events EPOLLIN; ev.data.fd cfd; epoll_ctl(epfd, EPOLL_CTL_ADD, cfd, ev); printf(accept new client, fd%d\n, cfd); } else { char buf[1024]; int n read(fd, buf, sizeof(buf)); if (n 0) { // 读到0或出错移除并关闭 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); close(fd); printf(close fd%d\n, fd); } else { // 回显。这里注意简单演示直接写生产环境要防半包 write(fd, buf, n); } } } } close(lfd); close(epfd); return 0; }这段代码逻辑很简单监听fd一旦可读说明有新连接到来马上accept并把这个新cfd注册进epoll普通fd可读说明有数据read并回显。相比select的做法这个模型能轻松支撑上万连接因为内核只回传就绪事件。6.4 边沿触发和水平触发怎么选epoll里有两种事件通知模式。水平触发LT是默认的fd只要还有数据可读每次epoll_wait都会返回它。边沿触发ET只在状态变化从无数据变为有数据时通知一次之后即便还有数据没读完也不会再次通知。换句话说LT模式下你不用担心漏读因为内核会反复提醒ET模式则逼你每次read必须循环读直到返回EAGAIN否则会丢数据。那为什么还有人用ET因为在高并发下LT模式下如果一个fd一直可读它每次唤醒都会返回导致其他fd饥饿。ET配合非阻塞socket和while read能把唤醒次数压到最低CPU占用更少。我的建议是新手先用LT它容错率高逻辑简单。等你把epoll_wait、EPOLLIN的细节都吃透了再研究ET不要一开始就追求“高级模式”那只会让你的问题排查难度翻倍。7. 服务器上线前必须检查的socket选项7.1 SO_REUSEADDR重启时才知道它有多重要代码里特意加了SO_REUSEADDR这里把原因讲透。服务端主动关闭连接后连接会进入TIME_WAIT默认持续约60秒。如果此时你重启服务listen的端口和TIME_WAIT里的本地端口冲突bind就会失败报Address already in use。SO_REUSEADDR这个选项允许你bind一个处于TIME_WAIT状态的地址从而让服务能在崩溃或重启后立刻恢复。几乎所有正经服务器都会设置它。但注意这不等同于随意复用端口它只解决TIME_WAIT场景。如果某个端口被一个还在正常运行的进程占用你设置了这个选项照样bind失败。7.2 TCP_NODELAY、Nagle算法与延迟确认TCP默认开启Nagle算法发送方把多个小数据包合并成大包再发减少小包数量提升网络利用率。这个算法对交互式应用很不友好比如实时游戏、远程输入一帧小数据可能被延迟几十毫秒才发出去。TCP_NODELAY选项可以关闭Nagle算法让每个write立即打包发送。听起来很简单但实际场景是Nagle和延迟ACK互相配合时会产生一个典型问题发送方等凑包接收方等合并确认双方互相等待延迟可能叠加到200毫秒以上。调试时如果发现请求响应忽快忽慢可以先打开TCP_NODELAY试试很多问题立刻消失。该选项在客户端和服务端都要设置因为它影响的是每条连接本身的发送行为。7.3 keepalive定时探活程序挂了连接还挂着TCP是全双工通道但操作系统层面没有“对方进程是否还活着”的主动通知。假设客户端进程崩溃没有发FIN服务端的连接会一直半开着read会永远阻塞。默认情况下TCP有一个keepalive探活机制但Linux默认要7200秒没数据才启动探测基本等于没用。业务上更常见的做法是自己实现心跳包应用层每隔几十秒发送一个心跳消息超过时长没收到对端消息就认为连接失效并主动关闭。这个逻辑一定要写不然服务端会积累大量半开连接fd和线程资源被白白占着。我接手过一个老系统几千个连接里一大半都是死连接加了心跳后连接清理得干干净净。7.4 常用Socket选项速查表选项名作用使用建议SO_REUSEADDR允许复用TIME_WAIT状态的地址服务器端基本必开TCP_NODELAY关闭Nagle算法小包立即发送低延迟交互场景开启SO_KEEPALIVE开启TCP层定期探活参数偏保守应用层心跳更实用SO_RCVBUF / SO_SNDBUF调整内核收发缓冲区大小大流量传输可以调大但要同时考虑内存SO_LINGER控制close时的行为默认即可不要随意改容易丢失数据SO_RCVTIMEO / SO_SNDTIMEO给阻塞收发设置超时推荐开启防止连接永久卡死以上每个选项改之前都要想清楚它影响的是正确性还是性能比如SO_LINGER设置成超时后立刻发RST虽然端口释放极快但未发送的数据会被丢弃对可靠性要求高的系统这就是事故。所以我的原则是非必要不碰它。8. 常见故障和调试技巧8.1 Address already in use除了等还能怎么办这个报错最常见原因上面说过了端口还在TIME_WAIT里。如果你没加SO_REUSEADDR重启就会撞上。加了之后基本解决。还有个相关场景是服务退出时没有close进程虽然没了但内核维护的连接还在同样会遇到这个报错。如果是一些极端情况比如压测时TIME_WAIT连接数巨大你可以查看/proc/sys/net/ipv4/ip_local_port_range确认可用端口范围或者调整net.ipv4.tcp_tw_reuse听名字和SO_REUSEADDR类似但它只在客户端主动连接时生效。我一般不推荐为了压测去改这些系统参数压测环境和生产环境的行为差异会误导你的判断。8.2 Broken pipe 和 SIGPIPE程序突然退出服务端收到数据后用write回写如果客户端已经关闭write会触发SIGPIPE信号而SIGPIPE的默认动作是终止进程。这是很多服务器“神秘崩溃”的元凶明明是一段普通的write代码却让整个进程退出。解决方案有几种一是设置信号处理忽略SIGPIPE二是在send调用时加MSG_NOSIGNAL标志。两种都有效我建议服务器代码里两个都做尤其是多线程程序忽略SIGPIPE能避免一个连接的错误带走全部线程。这属于“不知道的时候觉得没事知道后才发现自己一直坐在火药桶上”的典型例子。8.3 数据总是发不出去先看缓冲区有一种现象客户端发送了很多数据服务端只读了一部分或者服务端一段时间不读客户端write依然返回成功。这是因为数据暂时存到了内核发送缓冲区。缓冲区大小有限如果持续写入且对端不读取最终write会阻塞或返回EAGAIN。遇到这个现象别急着怀疑代码先看几个数ss -tan能显示send-q和recv-q队列长度分别表示发送队列和接收队列积压了多少字节。如果recv-q一直很大说明应用程序读得太慢如果send-q一直很大说明对端应用没在读。这两个数值能帮你把问题快速定位到具体设备侧。8.4 调试工具strace、ss、tcpdump的实战用法我的排查套路先看ss再看strace最后看tcpdump。ss看连接状态最直观ss -tan会列出所有TCP连接的本地地址、远端地址和状态ss -tanp还能看到对应进程PID方便你确认是不是自己的程序占着端口。strace用来跟踪系统调用strace -p pid -e tracenetwork能实时看到该进程的connect、accept、read、write调用。如果程序卡住了strace能告诉你是卡在哪个调用上比如一直在accept、一直read这比靠猜高效得多。不过生产环境别随便strace它显著拖慢性能我只在问题复现时短时间抓取。tcpdump抓包是最终手段sudo tcpdump -i any tcp port 9000 -nn可以看到SYN、ACK、FIN、RST的交互过程。比如连不上的情况抓包能看出是SYN发出后没响应还是对端回了RST。这个工具能一口气验证三次握手是不是正常应用层的字节流是不是符合预期。8.5 故障排查速查表现象可能原因排查路径bind报Address already in useTIME_WAIT或端口被占用ss -tan看状态加SO_REUSEADDR进程启动后立刻退出SIGPIPE查看日志忽略信号或用MSG_NOSIGNAL客户端连不上但服务端在运行防火墙、backlog满、监听地址不对ss -tanl确认监听tcpdump看SYNread永远阻塞对端发完数据后没关闭连接设置SO_RCVTIMEO应用层心跳发送慢偶尔卡一下Nagle 延迟ACK开启TCP_NODELAY数据错乱、丢帧应用层没有处理粘包/半包设计长度前缀协议循环读取fd耗尽socket返回EMFILE文件描述符泄漏检查所有分支是否close9. 我写这套笔记时的一些体会回头看这套“木下”TCP笔记最大的收获倒不是背下了socket函数和选项列表而是建立了“协议状态机”和“内核资源”这两条主线。每次遇到网络bug我会先问自己这条连接现在处于哪个状态我写的这个调用会改变内核的什么资源状态很多人学网络编程时喜欢直接套框架比如用Python写个socket两三行就把服务跑起来反而忽略了底层机制。框架把connect、bind、accept全封装了报错也变成了抽象的异常。等你遇到一个需要自己调参数、查内核日志的问题时就会发现自己对底层一无所知。所以尽管现在新语言的新框架层出不穷我依然建议每个后端开发者至少用C语言完整写一遍TCP服务端和客户端亲手处理EINTR、半包、TIME_WAIT这些问题写完之后再看任何高并发框架理解都会快很多。另一个体会是调试工具的重要性。代码写完能跑只是开始真正考验人的是“跑不出预期结果时你用什么方法定位问题”。先判断是哪一侧的问题用ss看连接状态用strace看系统调用用tcpdump看报文交互一套流程下来大多数网络问题都在半小时内有结论而不是靠猜和瞎改。这些工具我平时基本都开着方便随时排查你也可以先把这套流程跑熟后面做性能优化时还能靠它们验证你的优化是不是真的生效。