Socket 这个词刚接触网络编程的人多半被它坑过。我第一次写 TCP 服务端的时候把listen的 backlog 参数随手填了个 1本地测试一切正常上线之后并发一上来连接就开始莫名其妙地超时。排查了大半天才反应过来是连接队列被打满了。类似这种“文档里一句话带过、实际用起来处处是坑”的细节在 socket 编程里比比皆是。这篇东西就是想把 Linux 下 socket 这套东西从头捋一遍把 TCP 和 UDP 两条线各自的脾气、系统调用的真实行为、以及那些只有踩过才知道的坑尽量讲透。不管你是刚学网络编程、对着man手册发懵的新手还是写过一些服务端代码但总觉得理解不够扎实的老手应该都能从里面捞到点有用的东西。核心关键词就三个socket、TCP、UDP全文围绕它们在 Linux 上的实际表现展开。1. 先把 socket 这个东西的本质说清楚很多人学 socket 是从“它像一个文件”这句话开始的但这句话到底意味着什么往往没人往深了讲。理解这一点是后面所有内容的地基所以放在最前面。1.1 socket 为什么被设计成文件描述符在 Linux 的哲学里“一切皆文件”不是一句口号而是实实在在的抽象。socket 在创建之后返回的是一个整数这个整数就是一个文件描述符file descriptorfd和open()打开一个普通文件拿到的东西是同一类东西。这意味着你可以对 socket 用read()、write()、close()也可以把它塞进select/poll/epoll里做多路复用。这个设计的好处非常实际内核不需要为网络通信单独发明一套 IO 模型用户态程序也不需要学两套 API。你操作文件和操作网络连接在系统调用层面是统一的。但这里有个容易被忽略的点——socket fd 虽然长得像文件 fd但它背后挂的是一套完全不同的内核对象。普通文件背后是 inode 和页缓存socket 背后是struct socket和struct sock再往下才是 TCP/UDP 协议栈。所以有些行为看起来“像文件”但又不完全像比如 socket 上的lseek()是无效的因为它没有“文件偏移量”这个概念。我见过有同学试图对 socket 做mmap想零拷贝读数据结果当然是失败的。这不是 bug是设计上就没打算让你这么用。理解 fd 只是“句柄”而不是“文件实体”能帮你避开一大类想当然的错误。1.2 socket 描述符三元组与连接的唯一标识一个 TCP 连接在系统里是怎么被唯一确定的答案是四元组源 IP、源端口、目的 IP、目的端口。而一个 socket 在绑定之后本地这一端由二元组本地 IP、本地端口标识。这两个概念经常被混着说但区分清楚很重要。举个具体的例子。你的服务器监听在0.0.0.0:8080这是一个监听 socket它本身不参与数据传输只负责接受连接。当三个客户端分别从不同端口连上来内核会为每个连接创建一个新的 socket每个新 socket 的本地端是服务器IP:8080对端是各自的客户端IP:客户端端口。所以同一时刻服务器上会有 1 个监听 socket 加 3 个已连接 socket它们的 fd 各不相同。这里有个实操中很关键的细节监听 socket 和连接 socket 是两个不同的 fd。accept()返回的是新连接的 fd原来那个监听 fd 继续留着接受后续连接。新手常犯的错是把accept的返回值覆盖到监听 fd 上导致监听能力丢失。这个坑我在早期代码里踩过症状是“只能接受一个连接之后再也不响应”排查时盯着accept的返回值看半天才恍然大悟。1.3 阻塞与非阻塞socket 的两种性格socket 默认是阻塞的。什么意思你调accept()如果没有新连接线程就卡在那儿不动你调recv()如果没有数据到达线程同样挂起。这对简单的单连接程序很友好但一旦要处理多个连接阻塞模型就撑不住了——一个连接卡住整个线程都动不了。把 socket 设成非阻塞需要fcntl(fd, F_SETFL, O_NONBLOCK)之后所有操作立即返回没数据就返回-1并置errno为EAGAIN或EWOULDBLOCK在 Linux 上这俩值相等。非阻塞配合epoll就是现代高性能服务端的标准姿势。但这里有个非常隐蔽的坑accept()在非阻塞监听 socket 上如果没有新连接会返回EAGAIN这不是错误是正常状态。很多代码把accept返回-1一律当错误处理结果日志里刷满了“accept failed”其实啥事没有。正确的做法是判断errno只有EAGAIN/EWOULDBLOCK之外的值才是真错误。这个细节man手册里有写但很容易被跳过。2. TCP 服务端从 socket 到 accept 的完整链路光知道 API 名字没用得知道每一步内核到底干了什么、失败了意味着什么。这一节按调用顺序把 TCP 服务端的建立过程拆开讲。2.1 socket() 与 bind()端口占用问题的根因socket(AF_INET, SOCK_STREAM, 0)创建一个 TCP socket此时它还没有和任何地址关联。bind()才是把本地地址和端口绑上去的动作。绑定失败最常见的原因是EADDRINUSE——端口被占用。但“被占用”分两种情况很多人分不清。第一种是确实有另一个进程在监听这个端口netstat或ss一查就能看到。第二种是端口处于 TIME_WAIT 状态上一个连接刚关闭内核还保留着这个端口一段时间通常是 2 倍 MSLLinux 上约 60 秒防止旧连接的延迟报文干扰新连接。这时候你重启服务bind就会失败。解决办法是设置SO_REUSEADDRint opt 1; setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt));这个选项允许绑定处于 TIME_WAIT 的端口。注意它和SO_REUSEPORT不是一回事后者允许多个 socket 绑同一个端口做负载均衡用途完全不同别搞混。我在实际项目里基本是无脑加SO_REUSEADDR因为服务重启是家常便饭不加就是给自己找麻烦。2.2 listen() 的 backlog那个被误解最深的参数listen(fd, backlog)这个调用backlog 到底指什么很多人以为是“最大连接数”这是错的。backlog 影响的是未完成连接队列SYN queue和已完成连接队列accept queue的长度上限。内核收到 SYN 后连接进入 SYN queue完成三次握手后移到 accept queue等着应用层accept()取走。backlog 大致约束的是 accept queue 的容量实际值还受somaxconn限制Linux 默认 4096。如果 accept queue 满了新完成握手的连接会被丢弃或拒绝客户端表现为连接超时或重置。这就解释了我开头说的那个坑backlog 填 1意味着 accept queue 极小稍微有点并发队列就满新连接进不来。实际经验是把 backlog 设成一个合理值比如 128 到 1024 之间同时确认somaxconn够大。查somaxconn用cat /proc/sys/net/core/somaxconn需要调的话改/etc/sysctl.conf里的net.core.somaxconn。还有一个细节listen之后 socket 才真正进入监听状态之前bind完只是占了个坑。顺序不能乱socket → bind → listen是固定套路。2.3 accept() 背后新 fd 从哪来accept()从 accept queue 里取出一个已完成握手的连接内核为它创建一个全新的 socket返回新 fd。这个新 fd 继承了监听 socket 的部分属性比如非阻塞标志在 Linux 上不会自动继承需要手动设但它是独立的连接。这里有个性能相关的点值得说高并发场景下accept可能一次只能取一个连接如果连接来得猛应用层处理速度跟不上accept queue 就会堆积。有些实现会用多线程或多个进程同时accept同一个监听 fd配合SO_REUSEPORT或共享 fd把接受连接的压力分散开。这是“惊群”问题的现代解法之一不过那是另一个话题了这里先记住 accept 是串行取队列的就行。另外accept的第二个参数能拿到对端地址第三个参数是地址长度是个值-结果参数传进去时告诉内核缓冲区多大返回时告诉实际用了多少。忘了初始化长度会导致accept失败这个错误很傻但确实常见。3. TCP 的数据收发read/write 与 send/recv 的真实差异连接建好之后就是传数据。这一块看似简单实则暗坑无数尤其是“一次 send 不等于一次收完”这件事坑了无数人。3.1 短连接与长连接下的读写语义TCP 是字节流协议没有消息边界。你send了 100 字节对端recv可能一次收到 100 字节也可能分两次收到 60 和 40甚至可能先收到 1 字节。这不是 bug是字节流的本质。所以应用层必须自己定义消息边界——要么定长要么带长度前缀要么用分隔符。我见过太多新手代码写成这样char buf[1024]; int n recv(fd, buf, sizeof(buf), 0); // 假设 n 就是一条完整消息这种写法在本地测试、小数据量时往往“看起来正常”一旦网络有波动或者数据变大立刻出问题。正确的做法是循环读直到凑够一条完整消息。带长度前缀的协议最省心先读固定长度的头部拿到 body 长度再循环读够 body。read/write和send/recv在 TCP socket 上行为基本一致区别在于send/recv多了个flags参数能控制MSG_NOSIGNAL防止对端关闭时触发 SIGPIPE 信号把进程干掉这类行为。服务端代码强烈建议用send并带上MSG_NOSIGNAL或者全局忽略 SIGPIPE否则对端异常断开时你的进程可能直接崩掉这个坑非常致命。3.2 返回值处理那些必须区分的错误码recv返回 0 表示对端有序关闭了连接发了 FIN这是正常的关闭流程不是错误。返回-1才是出错但错误也分种类返回值/errno含义处理方式 0读到 n 字节正常处理继续读0对端关闭关闭本地 fd清理连接-1EAGAIN非阻塞下暂无数据等下次可读事件-1EINTR被信号中断重试-1ECONNRESET对端重置连接关闭 fd记录日志EINTR这个错误特别容易被忽略。当进程收到信号比如定时器信号阻塞中的recv会被打断返回-1errno是EINTR。这时候应该重试而不是当错误处理。很多代码没处理这个导致偶发的“读失败”排查起来极其痛苦因为它是概率性的。3.3 发送缓冲与部分写send 返回小于请求长度怎么办send返回的字节数可能小于你请求发送的长度这叫部分写。原因是内核发送缓冲区满了只塞进去一部分。阻塞 socket 上send通常会等到全部数据进缓冲区才返回但不保证对端收到非阻塞 socket 上则可能只写一部分就返回。处理部分写的标准姿势是循环size_t sent 0; while (sent len) { ssize_t n send(fd, buf sent, len - sent, MSG_NOSIGNAL); if (n 0) { if (errno EINTR) continue; if (errno EAGAIN) { /* 等可写事件再继续 */ break; } /* 真错误关闭连接 */ break; } sent n; }非阻塞场景下EAGAIN意味着发送缓冲区满了得等epoll报告可写再继续。这就要求应用层维护一个“待发送缓冲区”把没发完的数据存起来。这是所有高性能网络库都要处理的核心问题之一自己手写的时候千万别偷懒跳过。4. UDP 的脾气无连接不等于简单很多人觉得 UDP 比 TCP 简单因为不用建连接、不用管顺序。但“简单”只是表面UDP 把复杂度从协议层推给了应用层该操心的一个都少不了。4.1 数据报边界UDP 帮你保住了什么UDP 是数据报协议它保留了消息边界。你sendto发一个 100 字节的包对端recvfrom要么收到完整的 100 字节要么收不到不会出现“收到 60 字节”这种情况。这是 UDP 相对 TCP 最大的便利——不用自己划边界。但代价是UDP 不保证送达、不保证顺序、不保证不重复。丢包、乱序、重复应用层都得自己扛。所以 UDP 适合那些“丢了也无所谓或者自己能处理”的场景比如实时音视频、游戏状态同步、DNS 查询。你要是拿 UDP 传文件还指望它可靠那就是给自己挖坑。还有一个硬限制UDP 单个数据报有大小上限。理论上限是 65507 字节65535 减去 IP 头 20 和 UDP 头 8但实际中超过 MTU通常 1500就会在 IP 层分片分片一多丢一个分片整个包就废了重传代价极高。实战建议把 UDP 包控制在 MTU 以内也就是 1400 字节左右避免 IP 分片。这个数字不是拍脑袋的是 1500 减去 IP 头 20、UDP 头 8再留点余量。4.2 connect 在 UDP 上的妙用UDP 是无连接的但你可以对 UDP socket 调connect()。这不是建立连接而是在内核里记下对端地址之后就能用send/recv而不用每次sendto/recvfrom带地址。好处有两个一是省去每次传地址的开销二是内核会过滤掉其他来源的包只收 connect 指定的对端发来的数据安全性更好。这个技巧在实际项目里很好用。比如做客户端和固定服务器通信connect一下代码立刻清爽还能避免收到乱七八糟的伪造包。不过要注意connect过的 UDP socket 收到 ICMP 不可达时下一次send会返回ECONNREFUSED这个行为和未 connect 时不同得留意。4.3 UDP 的接收缓冲与丢包UDP 的接收缓冲区是有限的如果应用层recvfrom的速度跟不上包到达的速度缓冲区满了新到的包会被内核直接丢弃而且不通知你。这是 UDP 丢包的一个常见来源很多人以为是网络问题其实是自己处理太慢。调大接收缓冲区能缓解int rcvbuf 4 * 1024 * 1024; setsockopt(fd, SOL_SOCKET, SO_RCVBUF, rcvbuf, sizeof(rcvbuf));但要注意Linux 会对这个值做加倍处理而且受net.core.rmem_max限制。查一下cat /proc/sys/net/core/rmem_max如果设的值超过它实际生效的是 max 值。这个细节文档里写得含糊实测才知道。5. 端口复用、地址转换与那些绕不开的配置socket 编程绕不开地址和端口的处理这一块配置项多、行为微妙单独拎出来讲。5.1 字节序htonl/ntohl 到底在转什么网络字节序是大端主机字节序看 CPUx86 是小端。所以往 socket 地址结构里填端口和 IP 时必须转换。端口用htons/ntohs16 位IP 用htonl/ntohl32 位。名字里的 h 是 hostn 是 networks 是 shortl 是 long。新手最容易犯的错是忘了转端口导致绑到一个奇怪的端口上。比如想绑 8080htons(8080)得到的是0x901F不转的话直接填 8080 在小端机器上会被解释成0x1F90也就是 8080 的高低位颠倒。这种错误编译不报错运行时端口不对排查时容易懵。IP 地址的转换现在更推荐用inet_pton/inet_ntop比老的inet_addr/inet_ntoa更安全后者不可重入多线程下会出问题。inet_pton把点分十进制字符串转成二进制inet_ntop反过来。5.2 INADDR_ANY 与绑定具体地址的区别bind时地址填INADDR_ANY也就是0.0.0.0表示监听本机所有网卡的所有 IP。填具体 IP则只监听那个 IP 上的连接。多网卡机器上这个区别很实际如果你只想让内网访问就绑内网 IP想全部开放用INADDR_ANY。有个坑绑了INADDR_ANY之后再用具体 IP 绑同一端口会失败除非用SO_REUSEPORT因为INADDR_ANY已经覆盖了所有地址。反过来先绑具体 IP 再绑INADDR_ANY也可能冲突。这个行为在不同内核版本上略有差异稳妥做法是统一用INADDR_ANY或者统一用具体 IP别混着来。5.3 SO_LINGER关闭时的行为控制close()一个 TCP socket默认行为是内核尝试把发送缓冲区里的数据发完然后走正常的四次挥手。但有时候你希望立即关闭比如检测到异常不想等这时候可以设SO_LINGERstruct linger lg; lg.l_onoff 1; lg.l_linger 0; // 立即关闭发 RST setsockopt(fd, SOL_SOCKET, SO_LINGER, lg, sizeof(lg));l_linger 0会让close立即发 RST 而不是 FIN丢弃未发送的数据。这个操作要慎用因为它可能导致对端收到 RST 而不是正常关闭数据也可能丢。一般只在明确要“粗暴断开”的场景用比如防止大量 TIME_WAIT 堆积但这是治标不治本的做法更好的方案是让服务端主动关闭连接。6. 排查 socket 问题的实战思路理论讲完最后落到排查。socket 问题往往表现为“连接不上”“数据不对”“偶发失败”下面这套排查链路是我这些年攒下来的按顺序走基本能定位大部分问题。6.1 从 ss 命令看连接状态ss是排查 socket 问题的第一把工具比netstat快且信息全。常用姿势ss -tlnp # 看 TCP 监听端口和对应进程 ss -tnp # 看所有 TCP 连接及进程 ss -s # 看连接状态统计 ss -tn state time-wait # 专门看 TIME_WAIT如果ss -tlnp看不到你的监听端口说明bind/listen没成功或者进程根本没起来。如果能看到监听但客户端连不上看ss -tn里有没有对应的 SYN_RECV 状态——有的话说明握手没完成可能是防火墙或 backlog 问题。6.2 用 strace 跟踪系统调用当行为不符合预期strace能直接告诉你系统调用返回了什么。比如怀疑accept失败就strace -f -e tracenetwork -p pid-e tracenetwork只跟网络相关调用输出干净。看accept的返回值和errno一眼就能判断是EAGAIN正常还是真错误。这个手段在排查“偶发失败”时特别有效因为你能看到每次调用的真实结果而不是靠猜。6.3 常见问题速查表把高频问题整理成表遇到时对照着看能省不少时间现象可能原因排查手段bind 失败 EADDRINUSE端口被占或 TIME_WAITss -tlnp查占用加 SO_REUSEADDR连接超时backlog 满或防火墙查 somaxconn查 iptables只能接一个连接accept 返回值覆盖监听 fd检查代码 fd 管理偶发 recv 失败EINTR 未处理检查错误码分支对端断开进程崩溃SIGPIPE用 MSG_NOSIGNAL 或忽略信号UDP 丢包接收缓冲满调大 SO_RCVBUF加快处理这套表不是万能的但覆盖了八成常见情况。真正棘手的问题还是得靠strace加日志一点点抠。6.4 一个真实的排查案例说个我印象深的。有次一个服务客户端反馈“偶尔连不上”但服务端日志一切正常ss看监听也在。后来用strace跟了一段时间发现accept偶尔返回EMFILE——文件描述符耗尽。原因是代码里有个分支忘了close连接泄漏跑久了 fd 用完新连接自然接不了。这个问题的教训是每个 accept 出来的 fd 都必须有明确的关闭路径包括异常分支。后来我养成了习惯accept 之后立刻在脑子里过一遍“这个 fd 在哪些情况下会被关”代码里也用 RAII 或者 goto cleanup 的方式保证不泄漏。fd 泄漏这种问题症状隐蔽、爆发突然早防早省心。7. 写在最后的一点个人体会socket 这套 API 几十年没大变说明它的抽象是成功的但也意味着很多“历史包袱”和“反直觉行为”会一直存在。我自己的经验是别指望靠读文档就完全掌握它一定要动手写、动手调。写一个最简单的 echo 服务端然后用ss、strace去观察它的每一个状态变化比看十篇文章都管用。另外TCP 和 UDP 的选择从来不是“哪个高级用哪个”而是看场景。要可靠、要顺序选 TCP接受它的连接管理和字节流处理成本要低延迟、能容忍丢包选 UDP自己把可靠性该补的补上。真正难的不是调 API而是想清楚你的业务到底需要协议提供什么保证然后据此设计应用层的逻辑。这一点想明白了socket 编程的大部分困惑也就迎刃而解了。 
长河君 · 2026/10/26 13:59:15 · 阅读 1.2k Linux Socket编程深度解析：TCP/UDP核心机制与实战避坑指南
Socket 这个词刚接触网络编程的人多半被它坑过。我第一次写 TCP 服务端的时候把listen的 backlog 参数随手填了个 1本地测试一切正常上线之后并发一上来连接就开始莫名其妙地超时。排查了大半天才反应过来是连接队列被打满了。类似这种“文档里一句话带过、实际用起来处处是坑”的细节在 socket 编程里比比皆是。这篇东西就是想把 Linux 下 socket 这套东西从头捋一遍把 TCP 和 UDP 两条线各自的脾气、系统调用的真实行为、以及那些只有踩过才知道的坑尽量讲透。不管你是刚学网络编程、对着man手册发懵的新手还是写过一些服务端代码但总觉得理解不够扎实的老手应该都能从里面捞到点有用的东西。核心关键词就三个socket、TCP、UDP全文围绕它们在 Linux 上的实际表现展开。1. 先把 socket 这个东西的本质说清楚很多人学 socket 是从“它像一个文件”这句话开始的但这句话到底意味着什么往往没人往深了讲。理解这一点是后面所有内容的地基所以放在最前面。1.1 socket 为什么被设计成文件描述符在 Linux 的哲学里“一切皆文件”不是一句口号而是实实在在的抽象。socket 在创建之后返回的是一个整数这个整数就是一个文件描述符file descriptorfd和open()打开一个普通文件拿到的东西是同一类东西。这意味着你可以对 socket 用read()、write()、close()也可以把它塞进select/poll/epoll里做多路复用。这个设计的好处非常实际内核不需要为网络通信单独发明一套 IO 模型用户态程序也不需要学两套 API。你操作文件和操作网络连接在系统调用层面是统一的。但这里有个容易被忽略的点——socket fd 虽然长得像文件 fd但它背后挂的是一套完全不同的内核对象。普通文件背后是 inode 和页缓存socket 背后是struct socket和struct sock再往下才是 TCP/UDP 协议栈。所以有些行为看起来“像文件”但又不完全像比如 socket 上的lseek()是无效的因为它没有“文件偏移量”这个概念。我见过有同学试图对 socket 做mmap想零拷贝读数据结果当然是失败的。这不是 bug是设计上就没打算让你这么用。理解 fd 只是“句柄”而不是“文件实体”能帮你避开一大类想当然的错误。1.2 socket 描述符三元组与连接的唯一标识一个 TCP 连接在系统里是怎么被唯一确定的答案是四元组源 IP、源端口、目的 IP、目的端口。而一个 socket 在绑定之后本地这一端由二元组本地 IP、本地端口标识。这两个概念经常被混着说但区分清楚很重要。举个具体的例子。你的服务器监听在0.0.0.0:8080这是一个监听 socket它本身不参与数据传输只负责接受连接。当三个客户端分别从不同端口连上来内核会为每个连接创建一个新的 socket每个新 socket 的本地端是服务器IP:8080对端是各自的客户端IP:客户端端口。所以同一时刻服务器上会有 1 个监听 socket 加 3 个已连接 socket它们的 fd 各不相同。这里有个实操中很关键的细节监听 socket 和连接 socket 是两个不同的 fd。accept()返回的是新连接的 fd原来那个监听 fd 继续留着接受后续连接。新手常犯的错是把accept的返回值覆盖到监听 fd 上导致监听能力丢失。这个坑我在早期代码里踩过症状是“只能接受一个连接之后再也不响应”排查时盯着accept的返回值看半天才恍然大悟。1.3 阻塞与非阻塞socket 的两种性格socket 默认是阻塞的。什么意思你调accept()如果没有新连接线程就卡在那儿不动你调recv()如果没有数据到达线程同样挂起。这对简单的单连接程序很友好但一旦要处理多个连接阻塞模型就撑不住了——一个连接卡住整个线程都动不了。把 socket 设成非阻塞需要fcntl(fd, F_SETFL, O_NONBLOCK)之后所有操作立即返回没数据就返回-1并置errno为EAGAIN或EWOULDBLOCK在 Linux 上这俩值相等。非阻塞配合epoll就是现代高性能服务端的标准姿势。但这里有个非常隐蔽的坑accept()在非阻塞监听 socket 上如果没有新连接会返回EAGAIN这不是错误是正常状态。很多代码把accept返回-1一律当错误处理结果日志里刷满了“accept failed”其实啥事没有。正确的做法是判断errno只有EAGAIN/EWOULDBLOCK之外的值才是真错误。这个细节man手册里有写但很容易被跳过。2. TCP 服务端从 socket 到 accept 的完整链路光知道 API 名字没用得知道每一步内核到底干了什么、失败了意味着什么。这一节按调用顺序把 TCP 服务端的建立过程拆开讲。2.1 socket() 与 bind()端口占用问题的根因socket(AF_INET, SOCK_STREAM, 0)创建一个 TCP socket此时它还没有和任何地址关联。bind()才是把本地地址和端口绑上去的动作。绑定失败最常见的原因是EADDRINUSE——端口被占用。但“被占用”分两种情况很多人分不清。第一种是确实有另一个进程在监听这个端口netstat或ss一查就能看到。第二种是端口处于 TIME_WAIT 状态上一个连接刚关闭内核还保留着这个端口一段时间通常是 2 倍 MSLLinux 上约 60 秒防止旧连接的延迟报文干扰新连接。这时候你重启服务bind就会失败。解决办法是设置SO_REUSEADDRint opt 1; setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt));这个选项允许绑定处于 TIME_WAIT 的端口。注意它和SO_REUSEPORT不是一回事后者允许多个 socket 绑同一个端口做负载均衡用途完全不同别搞混。我在实际项目里基本是无脑加SO_REUSEADDR因为服务重启是家常便饭不加就是给自己找麻烦。2.2 listen() 的 backlog那个被误解最深的参数listen(fd, backlog)这个调用backlog 到底指什么很多人以为是“最大连接数”这是错的。backlog 影响的是未完成连接队列SYN queue和已完成连接队列accept queue的长度上限。内核收到 SYN 后连接进入 SYN queue完成三次握手后移到 accept queue等着应用层accept()取走。backlog 大致约束的是 accept queue 的容量实际值还受somaxconn限制Linux 默认 4096。如果 accept queue 满了新完成握手的连接会被丢弃或拒绝客户端表现为连接超时或重置。这就解释了我开头说的那个坑backlog 填 1意味着 accept queue 极小稍微有点并发队列就满新连接进不来。实际经验是把 backlog 设成一个合理值比如 128 到 1024 之间同时确认somaxconn够大。查somaxconn用cat /proc/sys/net/core/somaxconn需要调的话改/etc/sysctl.conf里的net.core.somaxconn。还有一个细节listen之后 socket 才真正进入监听状态之前bind完只是占了个坑。顺序不能乱socket → bind → listen是固定套路。2.3 accept() 背后新 fd 从哪来accept()从 accept queue 里取出一个已完成握手的连接内核为它创建一个全新的 socket返回新 fd。这个新 fd 继承了监听 socket 的部分属性比如非阻塞标志在 Linux 上不会自动继承需要手动设但它是独立的连接。这里有个性能相关的点值得说高并发场景下accept可能一次只能取一个连接如果连接来得猛应用层处理速度跟不上accept queue 就会堆积。有些实现会用多线程或多个进程同时accept同一个监听 fd配合SO_REUSEPORT或共享 fd把接受连接的压力分散开。这是“惊群”问题的现代解法之一不过那是另一个话题了这里先记住 accept 是串行取队列的就行。另外accept的第二个参数能拿到对端地址第三个参数是地址长度是个值-结果参数传进去时告诉内核缓冲区多大返回时告诉实际用了多少。忘了初始化长度会导致accept失败这个错误很傻但确实常见。3. TCP 的数据收发read/write 与 send/recv 的真实差异连接建好之后就是传数据。这一块看似简单实则暗坑无数尤其是“一次 send 不等于一次收完”这件事坑了无数人。3.1 短连接与长连接下的读写语义TCP 是字节流协议没有消息边界。你send了 100 字节对端recv可能一次收到 100 字节也可能分两次收到 60 和 40甚至可能先收到 1 字节。这不是 bug是字节流的本质。所以应用层必须自己定义消息边界——要么定长要么带长度前缀要么用分隔符。我见过太多新手代码写成这样char buf[1024]; int n recv(fd, buf, sizeof(buf), 0); // 假设 n 就是一条完整消息这种写法在本地测试、小数据量时往往“看起来正常”一旦网络有波动或者数据变大立刻出问题。正确的做法是循环读直到凑够一条完整消息。带长度前缀的协议最省心先读固定长度的头部拿到 body 长度再循环读够 body。read/write和send/recv在 TCP socket 上行为基本一致区别在于send/recv多了个flags参数能控制MSG_NOSIGNAL防止对端关闭时触发 SIGPIPE 信号把进程干掉这类行为。服务端代码强烈建议用send并带上MSG_NOSIGNAL或者全局忽略 SIGPIPE否则对端异常断开时你的进程可能直接崩掉这个坑非常致命。3.2 返回值处理那些必须区分的错误码recv返回 0 表示对端有序关闭了连接发了 FIN这是正常的关闭流程不是错误。返回-1才是出错但错误也分种类返回值/errno含义处理方式 0读到 n 字节正常处理继续读0对端关闭关闭本地 fd清理连接-1EAGAIN非阻塞下暂无数据等下次可读事件-1EINTR被信号中断重试-1ECONNRESET对端重置连接关闭 fd记录日志EINTR这个错误特别容易被忽略。当进程收到信号比如定时器信号阻塞中的recv会被打断返回-1errno是EINTR。这时候应该重试而不是当错误处理。很多代码没处理这个导致偶发的“读失败”排查起来极其痛苦因为它是概率性的。3.3 发送缓冲与部分写send 返回小于请求长度怎么办send返回的字节数可能小于你请求发送的长度这叫部分写。原因是内核发送缓冲区满了只塞进去一部分。阻塞 socket 上send通常会等到全部数据进缓冲区才返回但不保证对端收到非阻塞 socket 上则可能只写一部分就返回。处理部分写的标准姿势是循环size_t sent 0; while (sent len) { ssize_t n send(fd, buf sent, len - sent, MSG_NOSIGNAL); if (n 0) { if (errno EINTR) continue; if (errno EAGAIN) { /* 等可写事件再继续 */ break; } /* 真错误关闭连接 */ break; } sent n; }非阻塞场景下EAGAIN意味着发送缓冲区满了得等epoll报告可写再继续。这就要求应用层维护一个“待发送缓冲区”把没发完的数据存起来。这是所有高性能网络库都要处理的核心问题之一自己手写的时候千万别偷懒跳过。4. UDP 的脾气无连接不等于简单很多人觉得 UDP 比 TCP 简单因为不用建连接、不用管顺序。但“简单”只是表面UDP 把复杂度从协议层推给了应用层该操心的一个都少不了。4.1 数据报边界UDP 帮你保住了什么UDP 是数据报协议它保留了消息边界。你sendto发一个 100 字节的包对端recvfrom要么收到完整的 100 字节要么收不到不会出现“收到 60 字节”这种情况。这是 UDP 相对 TCP 最大的便利——不用自己划边界。但代价是UDP 不保证送达、不保证顺序、不保证不重复。丢包、乱序、重复应用层都得自己扛。所以 UDP 适合那些“丢了也无所谓或者自己能处理”的场景比如实时音视频、游戏状态同步、DNS 查询。你要是拿 UDP 传文件还指望它可靠那就是给自己挖坑。还有一个硬限制UDP 单个数据报有大小上限。理论上限是 65507 字节65535 减去 IP 头 20 和 UDP 头 8但实际中超过 MTU通常 1500就会在 IP 层分片分片一多丢一个分片整个包就废了重传代价极高。实战建议把 UDP 包控制在 MTU 以内也就是 1400 字节左右避免 IP 分片。这个数字不是拍脑袋的是 1500 减去 IP 头 20、UDP 头 8再留点余量。4.2 connect 在 UDP 上的妙用UDP 是无连接的但你可以对 UDP socket 调connect()。这不是建立连接而是在内核里记下对端地址之后就能用send/recv而不用每次sendto/recvfrom带地址。好处有两个一是省去每次传地址的开销二是内核会过滤掉其他来源的包只收 connect 指定的对端发来的数据安全性更好。这个技巧在实际项目里很好用。比如做客户端和固定服务器通信connect一下代码立刻清爽还能避免收到乱七八糟的伪造包。不过要注意connect过的 UDP socket 收到 ICMP 不可达时下一次send会返回ECONNREFUSED这个行为和未 connect 时不同得留意。4.3 UDP 的接收缓冲与丢包UDP 的接收缓冲区是有限的如果应用层recvfrom的速度跟不上包到达的速度缓冲区满了新到的包会被内核直接丢弃而且不通知你。这是 UDP 丢包的一个常见来源很多人以为是网络问题其实是自己处理太慢。调大接收缓冲区能缓解int rcvbuf 4 * 1024 * 1024; setsockopt(fd, SOL_SOCKET, SO_RCVBUF, rcvbuf, sizeof(rcvbuf));但要注意Linux 会对这个值做加倍处理而且受net.core.rmem_max限制。查一下cat /proc/sys/net/core/rmem_max如果设的值超过它实际生效的是 max 值。这个细节文档里写得含糊实测才知道。5. 端口复用、地址转换与那些绕不开的配置socket 编程绕不开地址和端口的处理这一块配置项多、行为微妙单独拎出来讲。5.1 字节序htonl/ntohl 到底在转什么网络字节序是大端主机字节序看 CPUx86 是小端。所以往 socket 地址结构里填端口和 IP 时必须转换。端口用htons/ntohs16 位IP 用htonl/ntohl32 位。名字里的 h 是 hostn 是 networks 是 shortl 是 long。新手最容易犯的错是忘了转端口导致绑到一个奇怪的端口上。比如想绑 8080htons(8080)得到的是0x901F不转的话直接填 8080 在小端机器上会被解释成0x1F90也就是 8080 的高低位颠倒。这种错误编译不报错运行时端口不对排查时容易懵。IP 地址的转换现在更推荐用inet_pton/inet_ntop比老的inet_addr/inet_ntoa更安全后者不可重入多线程下会出问题。inet_pton把点分十进制字符串转成二进制inet_ntop反过来。5.2 INADDR_ANY 与绑定具体地址的区别bind时地址填INADDR_ANY也就是0.0.0.0表示监听本机所有网卡的所有 IP。填具体 IP则只监听那个 IP 上的连接。多网卡机器上这个区别很实际如果你只想让内网访问就绑内网 IP想全部开放用INADDR_ANY。有个坑绑了INADDR_ANY之后再用具体 IP 绑同一端口会失败除非用SO_REUSEPORT因为INADDR_ANY已经覆盖了所有地址。反过来先绑具体 IP 再绑INADDR_ANY也可能冲突。这个行为在不同内核版本上略有差异稳妥做法是统一用INADDR_ANY或者统一用具体 IP别混着来。5.3 SO_LINGER关闭时的行为控制close()一个 TCP socket默认行为是内核尝试把发送缓冲区里的数据发完然后走正常的四次挥手。但有时候你希望立即关闭比如检测到异常不想等这时候可以设SO_LINGERstruct linger lg; lg.l_onoff 1; lg.l_linger 0; // 立即关闭发 RST setsockopt(fd, SOL_SOCKET, SO_LINGER, lg, sizeof(lg));l_linger 0会让close立即发 RST 而不是 FIN丢弃未发送的数据。这个操作要慎用因为它可能导致对端收到 RST 而不是正常关闭数据也可能丢。一般只在明确要“粗暴断开”的场景用比如防止大量 TIME_WAIT 堆积但这是治标不治本的做法更好的方案是让服务端主动关闭连接。6. 排查 socket 问题的实战思路理论讲完最后落到排查。socket 问题往往表现为“连接不上”“数据不对”“偶发失败”下面这套排查链路是我这些年攒下来的按顺序走基本能定位大部分问题。6.1 从 ss 命令看连接状态ss是排查 socket 问题的第一把工具比netstat快且信息全。常用姿势ss -tlnp # 看 TCP 监听端口和对应进程 ss -tnp # 看所有 TCP 连接及进程 ss -s # 看连接状态统计 ss -tn state time-wait # 专门看 TIME_WAIT如果ss -tlnp看不到你的监听端口说明bind/listen没成功或者进程根本没起来。如果能看到监听但客户端连不上看ss -tn里有没有对应的 SYN_RECV 状态——有的话说明握手没完成可能是防火墙或 backlog 问题。6.2 用 strace 跟踪系统调用当行为不符合预期strace能直接告诉你系统调用返回了什么。比如怀疑accept失败就strace -f -e tracenetwork -p pid-e tracenetwork只跟网络相关调用输出干净。看accept的返回值和errno一眼就能判断是EAGAIN正常还是真错误。这个手段在排查“偶发失败”时特别有效因为你能看到每次调用的真实结果而不是靠猜。6.3 常见问题速查表把高频问题整理成表遇到时对照着看能省不少时间现象可能原因排查手段bind 失败 EADDRINUSE端口被占或 TIME_WAITss -tlnp查占用加 SO_REUSEADDR连接超时backlog 满或防火墙查 somaxconn查 iptables只能接一个连接accept 返回值覆盖监听 fd检查代码 fd 管理偶发 recv 失败EINTR 未处理检查错误码分支对端断开进程崩溃SIGPIPE用 MSG_NOSIGNAL 或忽略信号UDP 丢包接收缓冲满调大 SO_RCVBUF加快处理这套表不是万能的但覆盖了八成常见情况。真正棘手的问题还是得靠strace加日志一点点抠。6.4 一个真实的排查案例说个我印象深的。有次一个服务客户端反馈“偶尔连不上”但服务端日志一切正常ss看监听也在。后来用strace跟了一段时间发现accept偶尔返回EMFILE——文件描述符耗尽。原因是代码里有个分支忘了close连接泄漏跑久了 fd 用完新连接自然接不了。这个问题的教训是每个 accept 出来的 fd 都必须有明确的关闭路径包括异常分支。后来我养成了习惯accept 之后立刻在脑子里过一遍“这个 fd 在哪些情况下会被关”代码里也用 RAII 或者 goto cleanup 的方式保证不泄漏。fd 泄漏这种问题症状隐蔽、爆发突然早防早省心。7. 写在最后的一点个人体会socket 这套 API 几十年没大变说明它的抽象是成功的但也意味着很多“历史包袱”和“反直觉行为”会一直存在。我自己的经验是别指望靠读文档就完全掌握它一定要动手写、动手调。写一个最简单的 echo 服务端然后用ss、strace去观察它的每一个状态变化比看十篇文章都管用。另外TCP 和 UDP 的选择从来不是“哪个高级用哪个”而是看场景。要可靠、要顺序选 TCP接受它的连接管理和字节流处理成本要低延迟、能容忍丢包选 UDP自己把可靠性该补的补上。真正难的不是调 API而是想清楚你的业务到底需要协议提供什么保证然后据此设计应用层的逻辑。这一点想明白了socket 编程的大部分困惑也就迎刃而解了。