搞Linux系统编程，绕不开网络这块。很多人写了好几年业务代码，socket、bind、listen、accept背得滚瓜烂熟，可一旦碰到连接异常、内存暴涨、CPU飙高，就开始抓瞎。原因很简单：只记住了API，没理解API背后内核在做什么，网络协议栈在做什么。这篇文章就围绕Linux环境下的网络协议编程，把那些文档里不会明说、但实战中一定会踩的东西一次讲透。无论你是在写高并发服务的后端开发，还是刚把《UNIX环境高级编程》翻到网络章节的学生，都能从里面拿到可以直接用的东西。
1. 从API到底层：socket编程先搞清这四件事
1.1 socket到底是什么
面试的时候经常有人被问“socket是什么”，回答“是一种文件描述符”当然没错，但只说这个说明还没理解到位。我更愿意把它理解成“内核网络模块对外暴露的一个操作句柄”。
你可以把内核想象成一家快递公司，socket就是你在快递公司开的一个账户。你往里塞数据（send/write），快递公司负责打包、写面单、找路由、派送；你收数据（recv/read），快递公司帮你接收、拆包、放到你的收件箱。你不需要自己去路上跑，也不需要关心包裹经过了哪些中转站，只需要跟快递公司的柜台打交道就够了。
这个“柜台”就是socket fd。为什么它长得像文件描述符？因为Linux的设计哲学就是“一切皆文件”，统一用fd来抽象所有可读可写的对象，这样就能复用read/write这些系统调用来收发网络数据。但归根到底，网络fd和普通文件fd在内核里走的是完全不同的两条路：文件fd走的是块设备驱动、页缓存那套逻辑，网络fd走的是协议栈的接收队列和发送队列。所以如果你把 “发给一个文件fd的数据” 和 “发给一个网络fd的数据” 想成一样的，那就是在用错误的心智模型推断行为。
1.2 地址结构、端口与字节序
写socket程序，第一个绕不开的就是struct sockaddr_in。这个结构体在x86机器上内存布局是固定的：sin_family占2字节（AF_INET），sin_port占2字节（端口），sin_addr占4字节（IP）。有三个坑在这里特别容易翻车。
第一个是字节序。网络字节序统一是大端，而x86是小端。x86的intel机器上写端口8080，必须用htons(8080)转成网络序，否则端口就会变成0x901F这样奇怪的数字。很多人第一次写的时候忘记htons，结果bind成功但客户端永远连不上，排查半天发现端口对不上。
第二个是结构体清零。sockaddr_in用之前必须bzero或者memset清零。因为内核在复制这个结构体的时候会把整个结构体都往内核空间拷贝，如果里面有垃圾数据，后面的字段解析就会出问题。写代码不能偷懒，struct sockaddr_in addr = {0}是最基本的操作。
第三个是强制类型转换。bind、connect、accept这些API的参数类型都是struct sockaddr*，而不是sockaddr_in*。这其实是C语言模拟“面向对象多态”的一种方式：因为除了IPv4的sockaddr_in，还有IPv6的sockaddr_in6和域套接字的sockaddr_un，内核没法预先知道你要传哪种，只能用通用指针加family字段来区分。所以写代码时强转一下，比如(struct sockaddr*)&addr，别嫌麻烦，这是Linux API的标准姿势。
1.3 TCP、UDP和原始套接字的选型
socket(AF_INET, SOCK_STREAM, 0)创建的是TCP，SOCK_DGRAM是UDP，SOCK_RAW是原始套接字。做应用层开发基本只和前两个打交道，但这里有个经常被忽略的细节：第三个参数protocol，TCP和UDP都可以直接写0，因为SOCK_STREAM和SOCK_DGRAM已经隐含了协议类型。
原始套接字能让你自己构造IP头甚至以太网头，常用于ping、traceroute这类工具的实现、或者某些抓包工具。它需要root权限，而且一旦用不好很容易把自己系统的协议栈搞乱。我个人的建议是：如果只是想发ICMP报文，直接用socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP)，现代Linux内核会帮你处理大部分头部填充，不需要从零手搓。
初学者往往会陷入一个误区：觉得UDP比TCP简单，所以先用UDP练手。这其实是个错误策略。UDP看着代码量少，但它的边界问题、丢包重传策略、流量控制全都要你自己处理，反而更容易写出“跑起来正常，压测就崩”的程序。反而是TCP，只要按照状态机老老实实走，内核帮你处理了可靠传输的大部分脏活。
2. 手写一个TCP服务端：每个API背后的真实作用
2.1 标准调用链：socket → bind → listen → accept
很多教程喜欢把这段代码扔出来就完事，但对“为什么要按这个顺序调用、每个调用到底做了什么”讲得非常浅。我用自己的理解拆一遍。
socket()创建fd，这一步只是在内核里建立了一个“空壳”的套接字对象，它还没有地址、没有连接、没有收发缓冲区里任何有效数据。你可以把它想成新租了一个信箱，但上面还没写门牌号。
bind()负责给这个信箱贴门牌号，也就是把本地IP和端口绑定到fd上。为什么需要这一步？因为内核收到一个数据包时，必须知道要投递给哪个进程，而这个投递依据就是数据包的目标IP和端口。如果你不bind，内核会自动帮你选一个临时端口，这就导致外部无法提前知道该连哪个端口，所以服务端必须手动绑定一个固定端口。
listen()做的事情是把socket从“未监听”状态切换到“监听”状态，同时在内核里初始化两个队列：未完成连接队列（SYN队列）和已完成连接队列（accept队列）。这一步非常关键，它意味着内核开始接受来自外部的SYN包，开始参与TCP三次握手的处理。很多人忽略listen的第二个参数backlog，我后面专门讲。
accept()做的事情，很多初学者的理解是“接收连接”，但这个理解太模糊了。准确地说，accept是从已完成连接队列里取出一个已经完成三次握手的内核自动创建的新fd。注意，这里取出的是新的fd，原fd仍然保持监听状态。这解释了为什么accept返回的fd和监听fd是两回事：一个是用来继续接受新连接的，一个是用来和具体客户端通信的。如果你把两个fd搞混了，就会写出一旦accept后监听失效的诡异bug。
动手写一个最简单的TCP回射服务端，核心逻辑大概是：
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 = {0}; addr.sin_family = AF_INET; addr.sin_addr.s_addr = htonl(INADDR_ANY); addr.sin_port = htons(8899); bind(listen_fd, (struct sockaddr*)&addr, sizeof(addr)); listen(listen_fd, 128); while (1) { struct sockaddr_in client_addr = {0}; socklen_t len = sizeof(client_addr); int conn_fd = accept(listen_fd, (struct sockaddr*)&client_addr, &len); if (conn_fd < 0) { // 处理错误 continue; } // 读数据，写回去 handle_client(conn_fd); close(conn_fd); }2.2 深入listen的backlog参数
backlog这个参数，几乎所有教程都会写，但真正理解它的人不多。很多资料说它是“最大并发连接数”，这是完全错误的。看一组实际表现就明白了：你把backlog设成2，然后同时发起10个连接，你会发现前几个成功，后面的迟迟连不上，但把backlog设大后，同样的连接全部秒成功。
要理解这个现象，得回到Linux内核实现。backlog实际上限制了“已完成连接队列”的长度。当客户端发来SYN，内核自动回复SYN+ACK并把该连接放入SYN队列；当客户端回复ACK完成三次握手后，连接从SYN队列移到accept队列。accept队列的长度就是backlog。
如果accept队列满了，内核会怎么处理？不同Linux内核版本策略不同——有些干脆丢弃SYN、有些丢弃ACK。但不管哪种，表现都是客户端SYN重传、连接迟迟建立不起来。所以backlog的本质是可等待应用层accept的连接数量上限，而不是并发连接数上限。高并发服务器上，backlog设成128或256是常规操作，但更大的意义在于：你的应用层accept处理速度必须跟得上连接到达速度，否则队列再大也只是延迟爆雷的时间。
2.3 accept返回的坑：EINTR与EMFILE
实战中accept返回-1很常见，其中两个errno是最让人迷惑的：EINTR和EMFILE。
EINTR表示系统调用被信号中断。如果你在代码里用了信号处理，很可能正在阻塞的accept被信号打断，直接返回-1。处理方式很简单：判断errno == EINTR就continue继续循环，不要当做致命错误。很多线上进程莫名其妙accept失败退出的，就是这行判断没写。
EMFILE表示进程的文件描述符已经耗尽，无法再创建新的fd。这时候你的服务器通常已经有大量连接没有关闭，或者fd泄露了。更恶劣的是，如果EMFILE没处理好，accept会一直失败，但监听fd依然活着，连接在队列里堆积，最终导致整个服务假死。我见过一个服务器，fd耗尽后accept直接崩了，而且没有日志，排查了很久才找到根因。通常做法是：预留一个空fd，碰到EMFILE时先关闭它，再accept拿到新fd后立即关闭客户端连接，最后把预留fd重新打开，保证进程始终有一个fd可用于紧急情况。
2.4 分包与粘包：TCP的字节流本质
TCP是字节流协议，不是消息协议。这句话几乎人人都背过，但真正踩坑之后才理解它有多重要。客户端一次send 100字节，服务端可能一次recv收到100字节，也可能分两次收到70+30；客户端连续send两次各50字节，服务端可能一次recv就收到100字节。
原因在于TCP把数据看成无边界的一串字节，而内核会在发送缓冲区和接收缓冲区之间自动做分包和合并，应用层无法控制每次recv到底返回多少数据。
所以应用层必须自己定义消息边界。最普遍的做法是TLV（Type-Length-Value）格式：每条消息前面加4字节长度头，接收端先读长度，再读完整的数据体。举个例子，如果你原样发一段JSON数据，收端没法判断什么时候一个完整的JSON结束了，因为JSON的结尾是}，但数据里也可能有}。加上长度头之后，问题就变得清晰明确。
代码层面，粘包处理的核心是一个“读满”的思路：不要指望一次recv读到你想要的那条完整消息，而是不断recv，把数据追加到一个应用层缓冲区，然后解析出长度头，判断缓冲区里够不够一条完整消息，不够继续等，够了就取走一条。
3. UDP编程的四个细节：比想象中更需要设计
3.1 UDP的边界保留特性
和TCP相反，UDP是保留消息边界的。发端一次sendto 100字节，收端recvfrom 100字节的缓冲区，能一次收到完整100字节。但这不代表你可以随意设置缓冲区大小，如果recvfrom的缓冲区小于一条UDP报文的大小，内核会截断多余部分，并且recvfrom返回的长度会比实际报文短，那部分数据直接丢了。
所以UDP服务端收数据，缓冲区往大了开，一般给到65535就够了，这就是UDP报文的理论上限（减去IP和UDP头部）。需要强调再多也不怕：即使你recvfrom的缓冲区只有100字节，对端发来1000字节，剩余900字节不会再给你第二次机会，直接被内核丢弃。有些新手把这个和TCP搞混，以为没读完的数据下次还能继续读，在UDP里这是不可能的。
3.2 UDP的connect：一个容易忽略的优化
UDP套接字也可以调用connect。很多人第一次知道这个知识点会惊讶：UDP不是无连接的吗，为什么还能connect？connect一个UDP socket后，内核会帮你在socket内部记录对端地址。此后你可以用send代替sendto、用recv代替recvfrom，内核直接按记录好的地址发送，也不再去检查每次调用有没有传空的地址参数。
更关键的性能优化是：connect过的UDP socket，内核只需要维护一份路由表项和目的地址缓存，发送路径更短，吞吐量更高。而且只有connect过的UDP socket才能收到ICMP错误通知，比如对端端口不可达。未connect的UDP连这个都收不到——你sendto出去，对端回了端口不可达，你这边毫无感知，这是很多UDP程序“数据丢了也不知道”的隐藏原因。
3.3 UDP丢包与流量控制问题
UDP本身没有拥塞控制，不像TCP那样有滑动窗口和拥塞窗口一步步试探网络能力。如果你用UDP连续高速发数据，大量报文会在路由器队列里被丢弃，或者被接收端的接收缓冲区溢出而丢弃。实测中发现一个典型规律：局域网内UDP发送速率超过某个临界值（通常跟网卡性能、应用处理速度有关），丢包率会悬崖式上升。
所以用UDP做可靠传输，必须要自己实现确认与重传机制。规模小的场景可以简单做：每条数据带递增序号，接收端记录收到的最大连续序号并定时回ACK，发送端超过一定时间没收到ACK就重传。规模大的场景直接用现成方案，比如QUIC或者基于UDP的可靠传输库。这里提醒一句：不要迷信“UDP比TCP快”，没有流控的UDP在大流量场景下反而会把网络打爆，让所有应用一起遭殃。
3.4 UDP服务器如何做并发
传统UDP服务端最直接的写法是单进程循环：recvfrom收到请求，处理，sendto回包。这个模型简单可靠，但处理耗时较长时吞吐量上不去。如果想让UDP服务端支持并发，有两种常见做法。
第一种是“共享socket + 多线程/多进程”，所有线程共用同一个UDP fd，recvfrom收到报文后交给线程池处理。这种方式要注意recvfrom返回的源地址struct sockaddr_in必须传给处理线程，不然回包时你不知道该发给谁。第二种是用SO_REUSEPORT，多个进程分别bind同一个UDP端口，内核会自动负载均衡地把报文分发到不同进程的接收队列里。这个方案在Linux 3.9以后的内核上非常成熟，实测能有效提升UDP吞吐和CPU利用率。
4. I/O模型选择：从阻塞到epoll的路线进化
4.1 阻塞IO为什么不行
最容易写出高并发服务的错误模型是“阻塞式多线程”：每个连接来一个，accept之后开一个线程去读。问题很明显：线程数超过几百之后，上下文切换开销开始吃掉CPU，内存消耗也快速上升。一个线程默认栈8MB，开1000个线程就准备了8GB虚拟内存，实际物理页面虽然按需分配，但压力依然很大。
更麻烦的是线程在阻塞读的时候，什么都没干，但调度器还是要轮询到它，这个浪费在高并发下被放大得非常明显。所以高并发服务一个核心思路就是：把大量等待中的连接从线程里解放出来，让少量线程去管理海量连接，这就是I/O多路复用的用武之地。
4.2 select、poll和epoll的设计对比
select是最早的多路复用API，它把一批fd传进内核，内核遍历一遍，把就绪的fd标记出来。问题在于每调用一次都要把fd集合从用户态拷贝到内核态，而且内核是遍历所有fd而不是只查就绪的，所以fd数量上去了之后，O(n)的复杂度很扎眼。select还有单个fd数量上限，通常是1024。
poll解决了上限问题，但仍然每次调用要拷贝整个pollfd数组，而且同样需要遍历。这俩本质上都是“每次全量遍历+全量拷贝”。
epoll的做法完全不同。它有三个关键操作：epoll_create在内核建一个事件表；epoll_ctl让你动态往里面添加、修改、删除需要监视的fd；epoll_wait等待内核返回“哪些fd就绪了”。内核只返回就绪的fd，而不是把所有fd都返回一遍，而且内核会维护一个就绪链表，避免每次从头遍历。
直接说性能感受：管理几千个连接，poll和select都能用，但到几万甚至十几万连接，只有epoll能扛得住。你不需要每个循环都拷贝所有连接进去，而是fd增减时通过epoll_ctl增量更新，内核维护状态，等待事件时直接取出就绪结果。
4.3 epoll的两种触发模式：LT和ET
epoll事件有两种模式：水平触发（LT）和边缘触发（ET）。这是面试高频考点，也是实际项目中改bug最频繁的源头。
LT模式是默认模式：只要fd上还有未读的数据，每次epoll_wait都会返回这个fd。好处是代码好写，recv没读完也没关系，下次还能继续被唤醒。坏处是每次epoll_wait可能要重复唤醒很多次，因为不断有数据可读，导致不必要的系统调用。
ET模式只在状态变化时通知一次。比如你注册了EPOLLIN，数据来了触发一次；你这次没读完，内核不会再主动通知你，直到有新的数据到达才再次触发。ET的要求很苛刻：你必须一次循环读，直到recv返回EAGAIN为止，把缓冲区读干净。好处是唤醒次数少，吞吐量高，坏处是容易漏读。
我给一个实用的操作建议：新手从LT模式开始写，稳定了以后再挑战ET。写ET时有一个重要细节：一定要给fd设置非阻塞模式，然后在读循环里判EAGAIN。很多人在ET模式卡住，就是因为recv读到最后一次返回-1，errno是EAGAIN，他以为出错了直接把连接关了。
4.4 epoll的事件结构一次性讲清楚
epoll_wait返回的是一个struct epoll_event数组，里面有events字段和data字段。事件类型常用的是EPOLLIN（可读）、EPOLLOUT（可写）、EPOLLERR（错误）、EPOLLRDHUP（对端关闭）。data是个联合体，里面有个fd成员，你通常在epoll_ctl注册时把fd填进去，在epoll_wait返回后用event.data.fd来判断是哪个连接有事件。
这里有一个隐藏很深的坑：EPOLLIN和EPOLLRDHUP同时返回时，说明对端已经关闭了写方向，但读缓冲区可能还有残留数据。你先读走剩余数据，再关闭连接，这样才能保证不丢尾部数据。如果直接按EPOLLRDHUP关闭，最后一批数据就可能还没被读走就被放弃。
完整的epoll读事件处理逻辑大致是：
while (1) { int n = epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i = 0; i < n; i++) { int fd = events[i].data.fd; if (events[i].events & (EPOLLERR | EPOLLHUP)) { // 优先处理错误和挂断 close(fd); continue; } if (events[i].events & EPOLLIN) { // 用循环读，配合缓冲区处理半包 handle_read(fd); } if (events[i].events & EPOLLOUT) { // 有数据要发送时关注可写事件 handle_write(fd); } } }4.5 EPOLLOUT和“写不完”的问题
一提到epoll，很多人只关注EPOLLIN，对EPOLLOUT忽略得很彻底。但实际上高并发下的写事件同样关键。send缓冲区满了，send返回-1、errno是EAGAIN，组织好的数据没发出去——这时候你就需要注册EPOLLOUT，等内核发送缓冲区腾出空间后，epoll_wait会通知你继续写。
常见的错误写法是：一开始就注册EPOLLOUT，然后epoll_wait疯狂返回可写事件，因为缓冲区平时一直是空的，可写状态一直保持——这会造成忙轮询。正确思路是“按需注册”：需要发送数据时先试着直接send，如果EAGAIN再注册EPOLLOUT，等可写事件来了之后把剩下数据写完，写完立刻注销EPOLLOUT。
这个写法的好处是：避免大量无意义的可写事件，节省系统调用，让CPU用在真正有数据传输的时候。我在自己的网络库里测试过，按需注册EPOLLOUT的写路径和无脑注册相比，CPU占用能降低30%以上，在大并发下非常明显。
5. 网络编程十大常见问题排查思路与调优配置
5.1 最大连接数上不去：文件描述符和端口限制
服务器最高能承载多少并发连接，不是socket本身决定的，而是三个资源限制共同决定的：进程文件描述符数、系统文件描述符总数、可用端口数。
默认情况下，进程的文件描述符上限只有1024，这对生产服务器来说远远不够。改的方法是ulimit -n、或者直接在代码里调setrlimit。但要注意ulimit改的是会话级别，如果你用systemd托管服务，最好在service文件里配置LimitNOFILE。
端口限制方面，作为客户端主动发起百万级连接时，可能把本地端口耗尽。单IP的TCP客户端连接数理论上限是65535个端口，要突破需要多个IP或开启reuseport之类的机制。大多数情况下“连接数上不去”先查这两个限制，再查内核参数，顺序不要搞反。
5.2 TIME_WAIT太多：主动关闭方的“两分钟惩罚”
服务端主动断开连接时，连接会进入TIME_WAIT状态，默认持续60秒。大量短连接场景下，TIME_WAIT会堆积，占用fd和端口资源，导致新建连接时出现“Address already in use”错误。
业界常用两个手段：一是设置SO_REUSEADDR，允许新的监听socket复用处于TIME_WAIT的本地地址；二是调整内核参数，比如net.ipv4.tcp_tw_reuse（仅对客户端connect生效）。需要提醒：现在很多线上环境不建议改net.ipv4.tcp_tw_recycle，因为它和NAT场景的兼容性很差，容易导致随机丢连接。宁可在应用层控制“谁主动关闭连接”，也不要盲目改内核参数。
5.3 连接迟迟不释放，请求处理完也不close
fd泄露是网络服务最常见的稳定增长型故障。排查方法很朴素：监控进程fd数，如果连接数没涨但fd数一直涨，基本可以断定有fd没关。
具体到代码里，比较隐蔽的场景包括：客户端走到异常分支没有close；fork子进程后子进程继承了父进程的fd没有关闭；错误处理里continue前忘记close。处理方式建议统一封装RAII或者defer式的关闭逻辑，保证所有return路径都释放fd。再用lsof或者/proc/PID/fd定期采样，观察哪些fd持续增长，很容易定位到具体代码段。
5.4 接收缓冲区太小导致性能暴跌
TCP的收发缓冲区大小直接影响吞吐。默认缓冲区在某些场景太小了——尤其在高带宽、高延迟的链路上（比如跨地域专线），小缓冲区会严重限制单连接吞吐量。
Linux下可以调整socket缓冲区大小，但更重要的是要理解window scale机制：TCP窗口大小是16位表示的，如果不开启窗口缩放，单连接最大吞吐会被限制在64KB/RTT。跨地域时RTT可能20ms以上，64KB/0.02s=3.2MB/s，怎么看都很难看。Linux默认开启tcp_window_scaling，但应用层的SO_RCVBUF如果显式设置过小，会覆盖内核的自动调优。所以建议：除非明确知道自己在做什么，否则不要往小里改SO_RCVBUF，让内核自动调优。
5.5 connect超时与重传参数调优
客户端connect一个不可达的地址，会等待很长一段时间才返回超时，这由内核的TCP SYN重传策略决定。比如Linux默认tcp_syn_retries是6，每两次SYN之间的间隔指数退避（1秒、2秒、4秒……），最长可能要等一两分钟才返回失败。
如果业务上希望快速失败，可以在应用层自己给connect设置非阻塞模式加超时控制：用O_NONBLOCK的socket发起connect，丢进epoll里等可写事件，用epoll_wait设置超时，超时就主动判断为失败。这个技巧在需要大量并发尝试连接不同节点、且希望快速排除不可达主机的场景里非常实用。
5.6 惊群效应与reuseport
多个线程/进程同时阻塞在同一个socket的accept上，一个连接到来时所有线程都被唤醒，但只有一个能抢到连接。这就是惊群效应。早期解决方式是用全局锁或者互斥量，后来有了SO_REUSEPORT，可以让多个进程各自bind同一个端口，内核直接把连接分发到不同的socket队列，从源头避免了惊群。
使用SO_REUSEPORT需要内核3.9以上，且每个进程都要在listen前设置SO_REUSEPORT再bind同样端口。实测下来，多进程模式下的吞吐提升很可观，特别是CPU核数多而单进程无法吃满的情况下。但要注意，SO_REUSEPORT的分发算法不一定均匀，某些版本的内核在短连接场景下会出现一定倾斜，所以上线之前务必压测验证一下。
5.7 SIGPIPE带来的进程崩溃
向一个对端已经关闭的socket写数据，内核会给进程发送SIGPIPE信号，默认动作是终止进程。这个坑太经典了。处理方式有两个：在代码全局忽略这个信号，signal(SIGPIPE, SIG_IGN)；或者用send时加上MSG_NOSIGNAL标志，让send返回错误而不是触发信号。
我在生产环境就见过一个服务因为客户端异常断开后，服务端继续写数据，直接被SIGPIPE打崩，进程挂掉后整个服务不可用。这个问题的隐蔽性在于它只在特定时序下出现，本地联调很难复现，压测时才会爆发。
5.8 半关闭状态：只关写不关读
TCP支持半关闭，即调用shutdown(fd, SHUT_WR)关闭发送方向，但保留接收方向。这在很多协议里是必须的：比如客户端发送完请求后关闭写方向，告诉服务端“我没有更多数据了”，然后继续等读取服务端的响应。
如果只有close，不分读写方向，两者表现不同：close会马上释放fd并发送FIN，同时丢弃接收缓冲区中未读数据。shutdown则更精细。在HTTP/1.0时代的框架里“发送完请求关闭写端再读响应”是很常见的设计。不要看到shutdown就觉得一定需要，但要明白它和close的差别，否则排查“为什么我的响应数据读不到了”时会走很多弯路。
5.9 非阻塞connect的实现细节
刚才提到的非阻塞connect，动手实现时有一个容易踩的坑：connect返回-1并不代表失败，errno是EINPROGRESS才是正常现象，表示内核正在异步建立连接。此时你应该把这个fd注册到epoll里等待EPOLLOUT事件。EPOLLOUT到来后，还需要调用getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &len)确认连接是否真的建立成功。因为EPOLLOUT也可能因为连接失败而触发，SO_ERROR为0才是成功，非0值是具体的错误码。
5.10 内核参数快查：三个最值得动的配置
很多人喜欢四处抄内核参数，这里我建议只关注三个影响最明显、也最安全的：
- net.core.somaxconn：listen backlog的全局上限，默认128。高并发连接场景下如果accept队列经常被打满，调大这个值配合应用层listen的backlog是有必要的。
- net.ipv4.tcp_fin_timeout：FIN_WAIT_2状态的超时时间。主动关闭方用了shutdown或read到EOF后进入这个状态，调小一点能加快连接回收。
- net.ipv4.tcp_keepalive_time：TCP保活探测的间隔。对长时间不通信的连接，设置一个合适的保活间隔，可以让内核自动发现并清理“僵死连接”。
这几项都建议在压测中观察系统表现后结合业务特点调整，不要照抄别人的“最佳实践”。不同硬件、不同带宽时延、不同协议行为，对参数的需求完全不一样。
6. 一套可落地的epoll + 线程池服务端骨架
6.1 整体架构思路
把前面的知识点串起来，我给出一个我个人实战中反复使用的epoll服务端骨架设计。它很适合作为后续业务的起点，不管你是要做网关、推送服务还是API服务，都能在这基础上改。
架构分三层：
- 主线程：创建监听fd，注册到epoll，循环epoll_wait处理连接事件和IO事件。
- 线程池：处理业务逻辑，从epoll返回的fd中读取完整数据包，执行业务，写回响应。
- 数据队列：主线程与线程池之间通过无锁或加锁队列交互，传递就绪连接的fd和读到的数据。
主线程只做两类事情：accept新连接并注册到epoll；从线程池的响应队列取下待发送数据，执行send。绝不阻塞在网络IO的read/write上。业务逻辑全部丢给线程池，保持epoll主循环的响应速度。
6.2 主线程的事件循环要点
主循环的核心逻辑，写成伪代码看会更清晰：
for (;;) { int n = epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i = 0; i < n; i++) { if (events[i].data.fd == listen_fd) { handle_accept(); // accept新连接并注册 } else if (events[i].events & EPOLLIN) { handle_read(events[i].data.fd); } else if (events[i].events & EPOLLOUT) { handle_write(events[i].data.fd); } } // 处理线程池返回的待发送数据 flush_pending_responses(); }关于read的细节：每个连接在业务处理时，你需要维护一个应用层的输入缓冲区。recv到的数据追加到缓冲区末尾，然后尝试解析协议，能解析出完整消息就交给线程池处理。无法解析完则继续保持等待EPOLLIN。
线程池处理完消息，把响应数据放进一个发送队列，主线程定时检查发送队列并发送。为什么不让线程池直接send？因为send可能阻塞，比如发送缓冲区满，线程池线程如果阻塞在send上，是很浪费的。把发送职责统一到主线程，通过EPOLLOUT管理写事件，就避免了多个线程同时操作一个socket发送缓冲区可能导致的加锁和顺序混乱问题。
6.3 单线程epoll模型其实也够用
在很多场景下，单线程epoll加非阻塞IO已经能支撑很可观的并发量。这里说一个我实测过的数据：在普通云服务器上，单线程epoll处理简单的回射协议，可以支撑几千到上万并发连接。CPU密集型的业务另说，IO密集且每个请求计算量很小的情况下，单线程模型完全够用，而且省掉了跨线程同步的大量麻烦。
所以不要一上来就搞复杂多线程模型。先写单线程epoll，压测看瓶颈。如果CPU跑不满但吞吐上不去，观察是不是读缓冲区太小、是不是accept队列打满、是不是协议解析太慢。多线程解决的是“CPU用不满、线程不够用”的问题，而不是“连接数太多”的问题。
6.4 一次压测学会看这三个指标
写完服务端骨架之后，压测是必须的。我的建议是重点看三个指标：最大并发连接数、QPS、以及长尾延迟。
并发连接数直接看服务端fd数就行，确认它能稳定撑住预设值。QPS用压测工具看每秒成功请求数，注意区分成功和失败。长尾延迟更关键：统计P99延迟，也就是最慢的1%请求耗时。很多服务平均延迟很好看，但P99高得吓人，说明系统在某个局部环节有严重的抖动——可能是线程池满了、发送队列积压、或者GC停顿。
压测时逐步增加并发，找到QPS拐点的位置。拐点之前是正常线性增长区域，拐点之后吞吐不涨甚至下降，说明系统已经过载。把负载控制在拐点之前的80%左右，是最稳妥的生产配置策略之一。
7. 网络编程中那些常识之外的“偏见”与“真相”
7.1 “TCP是可靠的”不等于“你写的代码可靠的”
学习阶段总强调TCP可靠性，但生产环境里，TCP保证的是“数据按序到达对端内核”，不保证“对端应用进程一定处理了数据”。内核收到数据放进接收队列，如果应用进程一直没调用recv，数据会一直滞留，甚至被内核丢弃。更重要的是，对端进程崩溃、对端机器断电，TCP的确认包是无法通知到你的——你只会在一段时间后因为保活机制或超时才发现连接异常。
所以“TCP可靠”只限于传输层内核之间，应用层的可靠交付必须靠自己的心跳、请求超时、重试、幂等设计来实现。这是我带过的每一届新人最容易误解的一层。
7.2 “长连接一定比短连接好”要看场景
短连接的问题是每次都要走一遍三次握手，还有可能的四次挥手，TIME_WAIT堆积，握手期间的延迟也会拖慢请求。长连接免掉握手延迟，适合高频率交互。但长连接也有代价：需要处理心跳保活、需要管理连接状态、如果服务端长时间无消息可发，中间网络设备可能回收空闲连接，导致你发数据时才发现连接已经断了。
折中的做法是“连接池 + 健康检查”：维护一组长连接，定期发送ping验证可用性，发现失效的连接立即剔除并重建。大多数框架已经帮你内置了这套逻辑，但理解它有助于排查“为什么我的连接池里的连接总是失效”之类的问题。
7.3 局域网和广域网的网络编程差异
同一套代码在局域网里跑得飞起，放到公网上就各种超时重传，这种经历几乎人人都有。原因很直接：局域网的丢包率极低、延迟极低、带宽充足，TCP几乎不需要重传；公网丢包率高，还有带宽争抢、路径拥塞，TCP会频繁进入重传和拥塞避免状态。
测网络程序，一定要在“高丢包、高延迟”环境里跑一遍。可以用tc命令在本地模拟，比如延迟加100ms、丢包加5%，你会发现很多在局域网里隐藏的问题全部暴露出来：应用层超时设置太短、重试机制根本没写、读缓冲区太小导致吞吐暴跌。
7.4 协议设计与业务场景的匹配
最后一个特别想强调的点：网络编程的核心其实不是写socket代码，而是协议设计。同样的业务，你用文本协议（如HTTP）可能又慢又占带宽，用二进制协议配合 varint 压缩，可能体积小十倍不止；你用同步请求写客户端简单但延迟高，改成异步消息模式吞吐立刻上了一个量级。
协议设计要跟着数据量、实时性要求、客户端环境、网络质量走。没有银弹。多花时间在设计数据的语义与边界上，比日后在代码里填坑划算得多。
我自己的经验是：网络编程不卡在语法，卡在“心智模型”。当你脑子里对三次握手、四次挥手、缓冲区、拥塞控制、IO多路复用这些概念有了清晰的图景，写代码和排查问题都会自然顺畅起来。这篇文章里记录的很多坑，是我反复踩过之后才明白的。希望你拿着这些思路再去读内核源码或者翻相关书籍时，能少走一些弯路。
