故小里写后台服务这些年，我有一半的线上事故都和Socket有关。从最开始的Connection refused，到高并发下的“no more data to read from socket”，再到莫名其妙的Address already in use，每个坑背后都是一条Linux网络编程的硬知识。这篇指南把Linux网络编程里的Socket、IO多路复用和几个高级特性串起来讲，结合真实场景，顺便把经常被问到的排查方法也放进来。不管你是刚学完C语言想做网络服务，还是已经在用select/poll/epoll但没吃透细节，这篇内容应该都能帮到你。
1. Socket基础：先把文件描述符这件事想明白
1.1 Socket到底是什么
很多教程一上来就贴三次握手图，反而让人记不住。我更喜欢用“电话机”来类比：你要打电话，必须有一根线路（fd），拨号（connect），对方接听（accept），然后两人说话（send/recv），挂断（close）。Socket就是操作系统给你的一根抽象线路，屏蔽了网卡、协议栈、路由这些底层细节。Linux里一切皆是文件，socket创建后会返回一个文件描述符（int fd），后续的收发操作全部围绕这个fd展开。
Linux支持三种常见Socket：AF_INET（IPv4网络Socket）、AF_INET6（IPv6）和AF_UNIX（本机进程间通信，也就是MySQL的Unix Socket）。网络编程里最常用的是AF_INET + SOCK_STREAM（TCP），它提供的是可靠的、双向的字节流；SOCK_DGRAM是UDP，不可靠但有消息边界。很多人以为Socket是“连接”，其实更准确地说，它只是通信端点，TCP连接是靠客户端connect三次握手后在两端形成的一条“虚拟链路”。理解这一点，后面看accept、listen、close的行为就不会乱。
1.2 核心API调用顺序
服务端和客户端的调用顺序几乎是固定的，建议先背下来：
- 服务端：socket() → bind() → listen() → accept() → recv()/send() → close()
- 客户端：socket() → connect() → send()/recv() → close()
每个API都有几个容易踩坑的参数。bind之前要填充struct sockaddr_in，注意sin_port必须用htons()转成网络字节序，sin_addr用inet_pton()把字符串IP转成二进制。比如绑定127.0.0.1:8080时，很多人忘了htons，导致端口变成65535倒过来。listen()的backlog参数表示已完成连接但还没accept的队列长度，这个值受内核参数net.core.somaxconn限制，不是想设多大就多大。
accept()返回的是新连接fd，而不是监听fd。监听fd只负责“接电话”，具体“通话”在返回的connfd上。服务端一定不要用listenfd去收数据，这是新手最常见的错误之一。还有一点，close()之前要确保数据发送完成，否则可能丢数据，可以配合shutdown()实现优雅关闭，但shutdown和close的行为差异很大，后面高级特性部分展开。
1.3 阻塞模式和非阻塞模式的抉择
默认创建的socket是阻塞的。以recv为例，如果没有数据可读，线程会一直挂在recv调用上，直到有数据或对端关闭。看起来无所谓，但高并发场景下，如果每个客户端分配一个线程，慢客户端就会让线程池被占满。我试过一个项目里用每连接一线程，单机也就几百个连接就开始报“unable to create new native thread”。后来切到非阻塞+IO多路复用，才把并发数拉起来。
设置非阻塞最直接的方式是fcntl(fd, F_SETFL, O_NONBLOCK)，也可以在accept后立刻设置。非阻塞模式下， recv/send在没有数据时会立即返回-1，错误码是EAGAIN或EWOULDBLOCK，这表示事件未准备好，不算失败。除此之外还要注意EINTR，即系统调用被信号中断，这种情况建议重试一次，而不是直接报错。很多线上bug都出在把EAGAIN当异常处理，导致正常压力下的服务被误杀。
1.4 连接建立的隐藏细节：三次握手不只是在connect里完成
TCP是面向连接的，很多人以为connect成功就等于三次握手完成，其实不完全对。connect()返回时，握手可能还在半路，尤其是遇到网络延迟或SYN重传时。服务端listen()只是打开等待队列，accept()把已完成握手的连接从队列里取出来。如果服务端不调用accept，连接依然会完成三次握手，只是没人“接通”。因此，连接队列满的时候，客户端表现为非常慢甚至超时，服务端这边可能看起来CPU占用不高，但Netstat会显示大量SYN_RECV。
这些隐藏行为只有在压测时才会暴露。我建议学习Socket时，配合抓包工具tcpdump看三次握手报文，绝对比死磕书上的状态图直观得多。后面第5章会专门讲排查手法。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. IO多路复用：select、poll、epoll到底怎么选
2.1 为什么必须有IO多路复用
刚才提到阻塞socket下，一个线程只能处理一个连接。非阻塞socket虽然能防止“卡死”，但如果一个线程不停轮询所有连接，CPU空转也很浪费。IO多路复用的核心思路是：把这些fd统一托管给内核，由内核通知哪些fd可读/可写，用户线程只处理就绪的fd。这样单线程就能管理成千上万个连接，避免了频繁创建线程，也减少了线程上下文切换。
理解IO多路复用之前，先分清阻塞/非阻塞描述的是“你如何等待fd”，而select/poll/epoll是“你一次等多少个fd”。它们不是替代关系，epoll模式下最好配合非阻塞socket使用，特别是边缘触发模式，否则很容易出问题。初学的时候把这两层概念理清，后面看代码会顺畅很多。
2.2 select：老功臣，但上限和效率都捉急
select最早的接口，原型大概是int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout)。用起来就是每次调用前把要监视的fd塞进fd_set，调用后一个fd一个fd地检查谁还在集合里。我最早写聊天室服务器就是用select，连接数一超过两百，循环扫描就开始肉眼可见地变慢。
select的痛点主要有三个：
- fd数量受限：默认FD_SETSIZE是1024，不修改内核基本跑不上高并发。
- 每次调用都需要把fd集合从用户态拷贝到内核态，频繁调用成本高。
- 内核不知道哪个fd就绪，需要线性扫描全部fd，连接越多越慢。
所以现在我一般不建议新项目再写select，除非你只是复习原理或维护老代码。
2.3 poll：突破了上限，但链表扫描没变
poll本质上就是把select的fd_set换成了pollfd数组，数量上限放宽了，但内部依然是线性扫描所有pollfd。它的事件字段用短整型events和revents标记，使用起来比fd_set直观，但性能和select差不多，连接数上来以后依然是O(n)的复杂度。如果你在写一个连接数不会超过几千、性能要求不高的工具型服务，poll比select更好用，代码也更简单。但如果目标是万级并发，建议直接上epoll。
2.4 epoll：Linux下的高性能方案
epoll是Linux特有的接口，不是POSIX标准。它由三个系统调用组成：epoll_create、epoll_ctl、epoll_wait。内核会为每个epoll实例维护一棵红黑树和一个就绪链表，你通过epoll_ctl把fd注册进去，哪个fd有事件了，内核会把它放到就绪链表，epoll_wait直接返回就绪fd的数组，不需要扫描全部fd。复杂度从O(n)降到O(就绪数)，这才是高并发的底气。
先看一个最基础的epoll服务端框架，监听socket加入event loop：
c复制#include <sys/epoll.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#define MAX_EVENTS 1024
static void set_nonblock(int fd) {
int flags = fcntl(fd, F_GETFL, 0);
fcntl(fd, F_SETFL, flags | O_NONBLOCK);
}
int main() {
int listenfd = socket(AF_INET, SOCK_STREAM, 0);
int opt = 1;
setsockopt(listenfd, 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(8080);
bind(listenfd, (struct sockaddr *)&addr, sizeof(addr));
listen(listenfd, 1024);
set_nonblock(listenfd);
int epfd = epoll_create(1);
struct epoll_event ev;
ev.events = EPOLLIN;
ev.data.fd = listenfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, &ev);
struct epoll_event events[MAX_EVENTS];
while (1) {
int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
for (int i = 0; i < n; i++) {
if (events[i].data.fd == listenfd) {
struct sockaddr_in client_addr;
socklen_t len = sizeof(client_addr);
int connfd = accept(listenfd, (struct sockaddr *)&client_addr, &len);
if (connfd < 0) {
if (errno == EAGAIN || errno == EINTR) continue;
perror("accept");
continue;
}
set_nonblock(connfd);
ev.events = EPOLLIN | EPOLLET; // 边缘触发，配合非阻塞
ev.data.fd = connfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, connfd, &ev);
} else {
int fd = events[i].data.fd;
char buf[4096];
ssize_t nread;
while ((nread = read(fd, buf, sizeof(buf))) > 0) {
// 回显，真实场景一般做业务解析
write(fd, buf, nread);
}
if (nread == 0) {
close(fd);
} else if (nread < 0 && errno != EAGAIN && errno != EINTR) {
close(fd);
}
}
}
}
}
这段代码虽然短，但已经把epoll的三种事件模型都展示出来了。事件类型上，EPOLLIN表示数据可读，EPOLLOUT表示可写，EPOLLERR表示发生错误，还有EPOLLRDHUP用于对端半关闭。注意分支里用循环读直到EAGAIN，这是边缘触发模式的核心要求，后面细说。
2.5 LT和ET：水平触发与边缘触发的实战选择
epoll的两种触发模式让很多人懵。简单说，LT（水平触发）是“只要缓冲区里还有数据，就会一直通知你”，ET（边缘触发）是“缓冲区状态从无变有，或者又到了新数据时，才通知一次”。
LT模式下，你读到部分数据没关系，下次epoll_wait还会继续通知你。ET模式则不同，一次通知后你得一口气把数据读完，否则剩余数据要等下一次新数据到达才可能再被通知，这就是为什么ET必须配非阻塞socket，并且要循环read直到EAGAIN。
从使用体验看，LT代码更稳，适合大多数业务；ET理论上更高效，因为少了很多重复通知和系统调用。我自己的建议是：新手先用LT跑通整体链路，再改成ET做优化；成熟服务如果追求极致吞吐，可以用ET，但千万记得把fd设置成非阻塞，不然read一个不完整包就卡死整个线程。还有一个坑是ET模式下的accept也要循环，只要accept一次没有返回EAGAIN，就一直accept，直到队列清空，否则监听fd只通知一次，剩下的连接会排长队。
3. 高级特性与参数调优：让每个连接都健壮起来
3.1 SO_REUSEADDR：解决“Address already in use”的第一步
TCP四次挥手后，主动关闭方会进入TIME_WAIT状态，默认持续2MSL（Linux上大约60秒）。这段时间内，如果服务器立刻重启，旧连接的本地端口还没释放，bind会直接报Address already in use。解决办法是在bind之前设置SO_REUSEADDR：
c复制int opt = 1;
setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
这个参数的意思不是“随意占用别人的地址”，而是允许内核在TIME_WAIT状态下重用本地地址。它是网络服务开发里必须加的参数，尤其是测试环境下频繁重启server，不加它体验非常糟糕。稍微提一句SO_REUSEPORT，它允许不同进程分别监听同一个端口，内核做负载均衡，多进程模型下很有用，但要注意使用场景和内核版本支持。
3.2 TCP_NODELAY：关掉Nagle算法，换回低延迟
Nagle算法是为了把小包攒成大数据块再发送，减少小包数量。但它的副作用是：如果发送方一次写一个字节，对端常常要等20-40毫秒才能收到更新，因为Nagle会延迟发送等待ACK（延迟ACK）。这在实时性要求高的场景（如即时消息、远程鼠标控制、交互式协议）里非常致命。
线上服务如果发现小包延迟明显，可以给连接fd加上TCP_NODELAY：
c复制int flag = 1;
setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));
关闭Nagle后，应用层每次send都会立刻封装成报文发出，心跳就能及时到达。反面代价是可能产生更多小包，增加带宽消耗。所以使用时机是：通常是低延迟要求的交互型流量，而大文件下载或批量上报则不需要，反而可以不动它，让内核自动优化。
3.3 SO_KEEPALIVE与业务心跳：哪套方案更可靠
TCP自带SO_KEEPALIVE，但默认参数几乎不适用：Linux默认空闲2小时才探测一次，连续9次失败才断开，等于一个死连接要挂好几个小时才能被发现。可以用setsockopt调整内核参数，或者直接不做依赖。真正的线上长连接服务，我更推荐自己做应用层心跳：比如客户端每30秒发一个PING，服务端超过90秒没收到就判定为死连接然后关闭。
为什么业务心跳更可靠？因为它基于业务语义，你不仅知道网络通不通，还能判断服务是否正常处理请求。TCP keepalive只能证明对端主机还活着，如果对端进程假死或卡死，TCP层面依然活着。所以我的习惯是两层一起用：TCP keepalive兜底，应用层心跳决定业务清理，不至于让无效连接一直占着fd。
3.4 收发超时：避免一个连接拖垮整个线程
在阻塞socket下，如果对端一直不回复，recv会永久阻塞。虽然你可以在线程层做超时，但更直接的办法是用SO_RCVTIMEO / SO_SNDTIMEO给系统调用设置超时：
c复制struct timeval tv;
tv.tv_sec = 5;
tv.tv_usec = 0;
setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));
setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, &tv, sizeof(tv));
超时后recv返回-1，errno通常是EAGAIN/EWOULDBLOCK。这样即使业务忘记处理，底层也不会无限卡下去。需要澄清的是，在多路复用模式下，epoll_wait本身有timeout参数，就绪事件才是最常被使用的超时机制，SO_RCVTIMEO通常用来保护那些没有接入epoll管理、独立阻塞读的socket，比如某些同步实现的客户端库。
3.5 其他值得了解的setsockopt：SO_LINGER、TCP_CORK、SO_SNDBUF
SO_LINGER控制close时的行为，默认close会立即返回，后台把缓冲区的数据尽量发送，如果设置l_onoff=1, l_linger=0，close会发送RST而不是正常四次挥手，主动丢弃未确认数据，这适合一些需要强制快速释放连接的场景。TCP_CORK与TCP_NODELAY相反，它会强制延迟发送，直到缓冲区积累到一定量或显式取消CORK，适合批量数据传输。SO_SNDBUF和SO_RCVBUF调整内核socket缓冲区大小，太大的值会浪费内存，太小的值会降低吞吐。一般情况下默认值已经够用，除非你打包大数据或延迟敏感业务，再去内核参数里调。
4. 常见问题与排查实录
4.1 Connection refused：端口到底有没有人监听
客户端connect报Connection refused，大概率是服务端进程没在该端口监听，或者防火墙把包丢了。排查顺序很固定：
- 服务端用ss -tlnp检查端口是否在LISTEN状态。
- 客户端用telnet ip port试一下，如果连拒绝都没有，看防火墙。
- 用tcpdump抓包，看SYN是否有回包。
有一次线上问题就是这个：服务进程起来了，但绑定的IP写成了127.0.0.1，外部机器当然连不上，只有本机能连。所以绑定的时候要明确INADDR_ANY还是指定内网IP，不能想当然。Connection refused通常是好事，说明对端及时告诉你“没人”，比黑洞式的超时好排查多了。
4.2 “no more data to read from socket”：EOF不是错误
很多语言库会把这个情况包装成异常，其实底层就是read()返回0，表示对端正常关闭。客户端如果设置了循环读取，对端断开后read返回0，应用层应该结束循环并close，而不是继续等数据。Java JDBC报“no more data to read from socket”常见于MySQL连接被服务端关闭、或查询期间网络断开，本质都是对端关闭连接。
项目里出现过一次：线程池里的线程拿到一个已经关闭的socket fd，重复调用read，返回0后库直接抛异常。定位后才知道是连接池没有及时清理死连接，导致旧连接被复用。日常开发要记住：“EOF不是网络错误”，而是协议的一部分，发送完数据一定要显式告诉对方“我说完了”，比如用shutdown写半关闭，或自定义消息结束标记。
4.3 Connection reset by peer：不能忽视的RST
如果对端进程崩溃，或者一端close时缓冲区里还有未读数据，内核会直接发RST而不是FIN，这时对端再read/write就可能报Connection reset by peer。常见错误有：客户端发了数据后立即close，服务端还没处理完，内核觉得是异常关闭；又或者是服务端写了一个已经不存在的连接，收到RST后继续写，就会reset。
排查建议是多看业务日志中close的顺序。如果服务端要主动断开，先调用shutdown(fd, SHUT_WR)发送FIN，再等待对端FIN，最后close，这样可以大幅减少RST。另外，对已经收到RST的socket，别再调用close以外的操作，因为后续读写都是浪费。
4.4 Can't connect to local MySQL server through socket '/tmp/mysql.sock'
这不是TCP Socket问题，而是Unix域套接字问题。MySQL启动后会在某个路径生成.sock文件用于本机连接。报错原因一般有：MySQL没启动、Socket文件被删除、路径配置不一致、权限不对。解决步骤：
systemctl status mysql或service mysql status确认进程在跑。ls -l /tmp/mysql.sock看文件是否存在，如果目录是tmpfs，重启后可能被清，需要配置MySQL重新生成。- 用
mysql -uroot -h127.0.0.1 -P3306强制走TCP连接测试一下，如果TCP能通但socket不行，重点检查权限和路径配置。
别把它和网络socket混淆。Unix域Socket传输不走网卡，性能更好，可用于本机进程间通信，但文件路径很容易被清理或权限限制。我曾经在容器里遇到/tmp/mysql.sock消失，是因为容器重启把临时目录清掉，重启MySQL服务就好了。
4.5 TCP粘包和分包：为什么“奇数字节后多了随机数”
很多初学Socket的人写协议：第一次read收到的数据长度不确定，然后莫名其妙多出来几个“随机字符”。这其实是把TCP当UDP用了。TCP是字节流，recv一次返回多少字节完全不确定，可能少读，也可能把两包并一包。客户端每次send一包数据，服务端可能一次read读到半包，也可能一次读到多包。至于“多出来的随机数”，往往不是网络补的，而是你解析时用了strlen去取缓冲区的长度，但缓冲区里残留了上一次的数据，或者结构体里存在padding，未初始化的内存被当成了消息内容。
解决办法是设计成有边界的协议：
- 固定长度报文：每包固定大小，读够长度再处理。
- 长度字段：头部4字节表示后续数据长度，先读头部再读body。
- 分隔符协议：如HTTP的\r\n，但二进制数据不适合。
我的习惯是用“消息头（magic字节 + 长度） + 消息体”，客户端封包服务端拆包，这样既不会有粘包问题，也能正确判断一个完整消息何时到达。
4.6 Address already in use与端口占用
bind报Address already in use，很大概率是之前的进程没退净，或者TIME_WAIT状态仍在。用lsof -i:8080或ss -tlnp查看占用情况，先确认是不是自己上一次的旧进程。如果是TIME_WAIT，设置SO_REUSEADDR解决；如果是别的进程占用，别硬抢，应该换端口或协调进程。顺便提醒，修改内核参数net.ipv4.tcp_tw_reuse可以加快TIME_WAIT重用，但要谨慎，它只适用于客户端连接，不能完全替代SO_REUSEADDR。
5. 性能优化与实测经验
5.1 文件描述符限制：先冲破1024的墙
高并发服务首先要处理fd上限。默认进程打开文件数通常是1024，一个连接至少占一个fd，所以单进程最多1000来个并发就顶天了。调整方法：
bash复制ulimit -n 65535
这只是当前shell临时生效，需要永久修改可以去/etc/security/limits.conf里配置。此外，内核级还有fs.file-max系统总限制。很多压测死得莫名其妙，一查就是fd耗尽，报错“Too many open files”。所以写服务的第一步，先把fd上限调大。
5.2 高并发线程模型：Reactor比每连接一线程靠谱
处理高并发的常见套路是Reactor模型：一个线程跑epoll_wait做事件监听，业务处理丢给线程池。事件线程只做IO读写和解包，避免阻塞；耗时任务如数据库查询放到工作线程，不要让IO线程卡住。这样IO线程才能快速处理新连接和新请求。
如果继续用每连接一线程，不仅线程数暴增，上下文切换成本也不可忽视。我用Rust和C写过几个对比压测，差别最大的就是内存和线程切换，同样4核8G的云主机，每连接一线程压到3000并发时CPU就飙到90%，Reactor模型顶到3万连接还行。核心原因是线程切换成本远高于epoll事件通知。
5.3 内核参数调整：让TCP栈更配合你的业务
网络服务的性能瓶颈有时不在应用层，而在内核TCP栈。常见调整项有：
- net.core.somaxconn：影响listen的backlog上限，建议调大，否则即使listen(1024)，内核也截断到默认128。
- net.ipv4.tcp_max_syn_backlog：SYN队列长度，在半连接攻击或网络慢时有用。
- net.ipv4.ip_local_port_range：客户端主动连接时自动分配的本地端口范围，范围太窄会限制发起连接数。
- net.core.rmem_max / net.core.wmem_max：增大socket缓冲区上限。
调这些参数前先压测看监控，不要无脑调大，有些参数改动会占用更多内存。实测经验是somaxconn从128调到4096后，突发连接瞬间的ConnectFailed明显减少。
5.4 零拷贝：sendfile、splice能省掉一次内存拷贝
做文件传输类服务时，传统流程是read到用户态再write，内核与用户态之间拷贝两次，CPU占用高。可以用sendfile直接把文件fd的内容发送到socket fd，让内核完成传输，Java NIO的transferTo就是这个原理。Linux下还有splice可以把管道和socket之间直接搬数据。零拷贝不是万能的，它适合大文件或流量极高的转发场景，对复杂业务报文没有太大帮助，但值得在系统设计里留一个备选项。
5.5 工具与心法：strace和tcpdump怎么配合
遇到网络问题，我最常用的组合是strace和tcpdump。strace可以跟踪进程的system call，看它到底在哪个阶段卡住，比如卡在read还是accept；tcpdump抓包可以让你看到报文走没走、SYN有没有回复、数据在哪一层丢的。跑一次：
bash复制strace -f -e trace=network -p 进程ID
tcpdump -i eth0 -s0 -w /tmp/out.pcap tcp port 8080
这两个命令能解决90%以上的网络服务问题。我遇过最诡异的case是：客户端卡在connect超时，但服务端明明在LISTEN。tcpdump看SYN有进去，但服务端没回SYN-ACK，最后发现是iptables规则针对某个源IP丢了包。如果只看应用层日志，这个case能查好几个晚上。
还有一个小技巧：所有socket fd要记得加FD_CLOEXEC，防止fork()之后子进程继承fd导致连接一直被占着。可以借助fcntl设置，也可以用epoll_create1函数带EPOLL_CLOEXEC标志。这些细节平时不显眼，等你的进程需要自动重启或拉起子进程时，会救命。
最后再分享一个经验：写网络服务不要上来就追求“高级”，先把阻塞/非阻塞、多路复用、参数调优这些基本功吃透，再谈高并发。调试时，strace看系统调用，tcpdump看报文，两把尺子一起用，几乎不会有定位不了的问题。如果让我只留一条建议，那就是：任何时候不要忽略错误码和关闭语义，TCP连接不是资源，而是一场双方协作的过程，谁先close、谁发RST、谁还读EOF，搞清楚这些，你才算真正理解了Linux网络编程。