1. 从一次线上故障说起为什么我要把socket翻出来重讲一遍前阵子帮一个朋友排查他那个小服务的问题现象很怪客户端明明显示连接已经建立但发出去的数据就像石沉大海服务端日志里连个影子都没有。他一口咬定是业务逻辑写错了我让他把抓包结果发过来一看三次握手压根没走完卡在第二次。问题最后定位到他监听队列的 backlog 设得太小加上服务端处理 accept 的节奏太慢新连接全堵在半路上。这事儿让我意识到很多人写网络程序是“照着模板抄”socket 那几行代码背得滚瓜烂熟可一旦出问题脑子里没有一张从内核到应用的完整地图排查起来就是瞎猜。所以这篇东西我想把 Linux 下的 socket 编程从头到尾捋一遍重点落在 TCP 和 UDP 这两条主线上。它不是什么高深的东西就是操作系统给进程开的一扇“网络门”你往里写数据内核帮你打包发出去外面有数据进来内核帮你拆包放到缓冲区等你读。但恰恰是这扇门背后的机制——缓冲区、连接状态、阻塞与非阻塞、粘包与丢包——决定了你的程序是稳如老狗还是三天两头抽风。这篇文章适合谁看刚接触网络编程、能写个 echo server 但说不清背后原理的同学也适合工作几年、天天调 API 但对内核行为一知半解的开发者。我会把每个关键选择背后的“为什么”讲透配上能直接抄的代码和踩过的坑读完你至少能做到看到连接异常知道往哪个方向查写服务端知道 backlog、缓冲区、超时这些参数该怎么定。2. 先把 socket 这层窗户纸捅破它到底是什么2.1 socket 不是协议是内核给你的一张“收据”很多人初学时会混淆 socket 和 TCP/UDP 的关系。打个比方TCP 和 UDP 是两家不同的快递公司一个承诺必达、按顺序送一个只管扔出去、快但可能丢件而 socket 是你去寄件时拿到的那张单子上面写着收件地址、联系方式你凭这张单子跟快递公司打交道。也就是说socket 是应用层和传输层之间的编程接口是一个抽象出来的文件描述符。在 Linux 里“一切皆文件”socket 也不例外你拿到的是一个 int 型的 fd可以用 read/write 去操作它也可以用 close 关掉它。这个“文件”的特别之处在于它背后挂着一整套内核网络栈。你调用socket()的时候内核给你分配了一个 socket 结构体里面记录了协议族IPv4 还是 IPv6、套接字类型流式还是数据报、当前状态、发送和接收缓冲区等信息。真正干活的是内核你的进程只是通过系统调用给它下指令。理解这一点很关键因为后面所有的“坑”——缓冲区满、连接排队、数据粘包——本质上都是你在跟内核的这套机制博弈。2.2 流式与数据报TCP 和 UDP 在 socket 层面的根本分野创建 socket 时那个type参数决定了你走哪条路。SOCK_STREAM对应 TCPSOCK_DGRAM对应 UDP。这个选择不是随便挑的它直接决定了你后面代码的写法。TCP 是面向连接的字节流。什么叫字节流就是它不保留你发送时的“消息边界”。你分三次 write 了 “hello”、“world”、“!”对面 read 的时候可能一次读到 “helloworld!”也可能分五次读到碎片。它只保证字节顺序不乱、不丢、不重。这就要求应用层自己设计“怎么知道一条消息结束了”——这就是后面要讲的粘包问题的根源。UDP 是面向报文的。你 sendto 一个 100 字节的包对面 recvfrom 要么收到完整的 100 字节要么啥也收不到绝不会收到 50 字节。它保留了消息边界但代价是不保证送达、不保证顺序、不保证不重复。所以 UDP 适合那种“丢一两个包无所谓、但延迟要低”的场景比如实时音视频、游戏状态同步、DNS 查询。我见过不少新手拿 UDP 去传文件然后自己在上层实现重传和排序最后写出来的东西比 TCP 还慢还容易出错。这就是没搞清楚两者定位。选型的时候先问自己三个问题数据能不能丢对延迟敏不敏感需不需要按顺序到达答案清楚了选哪个自然就定了。2.3 一个 socket 的完整生命周期长什么样TCP 的 socket 生命周期是一条清晰的链socket()创建 →bind()绑定地址端口 →listen()进入监听 →accept()取出已完成连接的套接字 →read/write收发 →close()关闭。客户端则是socket()→connect()→ 收发 →close()。UDP 简单些服务端socket()→bind()→recvfrom/sendto客户端socket()→sendto/recvfrom没有 listen 和 accept 这一套。这里有个容易被忽略的点accept()返回的是一个全新的 fd和监听 fd 不是同一个。监听 fd 只负责“接客”新 fd 才是真正跟这个客户端通信的通道。所以一个服务端要同时处理多个客户端就得把每个 accept 出来的 fd 管好这就引出了后面 select/poll/epoll 的话题。很多模板代码里 accept 完不关新 fd或者把监听 fd 关了都是低级但要命的错误。3. TCP 服务端实操从 bind 到 accept 的每一步都有讲究3.1 地址复用与 bind那个让人抓狂的“Address already in use”写服务端第一个坑往往出现在重启的时候程序刚被杀掉马上再启动报Address already in use。这不是你的代码有 bug是 TCP 的连接状态机在作祟。主动关闭连接的一方会进入TIME_WAIT状态停留 2MSL一般是 60 秒左右这段时间里端口还被占着。解决办法是在bind()之前设置SO_REUSEADDRint opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt));这个选项的作用是允许绑定处于TIME_WAIT状态的地址。生产环境里几乎必开否则每次发布重启都可能起不来。还有个SO_REUSEPORT允许多个进程绑定同一个端口做负载均衡那是更进阶的用法普通场景用SO_REUSEADDR就够了。bind()的地址填法也有讲究。服务端一般填INADDR_ANY即 0.0.0.0表示监听本机所有网卡。如果你只想监听某个特定网卡就填那个网卡的 IP。端口填 0 的话内核会随机分配一个可用端口这在写测试客户端时有用但服务端肯定要指定固定端口。绑定失败除了端口占用还可能是权限问题——1024 以下的端口需要 root 权限普通用户绑不上。3.2 listen 的 backlog不是越大越好也不是随便填listen(fd, backlog)这个 backlog 到底指什么网上说法五花八门。准确地说它影响的是已完成连接队列accept queue的长度上限也就是三次握手已经完成、等着你 accept 的那些连接能排多长。注意不同内核版本对它的解释略有差异早期版本还会参考半连接队列SYN queue但现代内核里 backlog 主要管的是 accept 队列。那 backlog 设多少合适设太小高并发时新连接会被拒绝或者丢弃表现为客户端 connect 超时或收到 RST设太大占内存不说还可能掩盖你 accept 处理太慢的问题。我的经验是先估算你的 QPS 和单次 accept 处理耗时backlog 至少要能扛住“处理一个连接期间新进来的连接数”。比如你每秒处理 1000 个连接accept 一次耗时 1ms那理论上队列里最多积压 1 个但考虑到突发流量设个 128 到 1024 比较稳妥。内核还有个somaxconn参数/proc/sys/net/core/somaxconn会封顶你 listen 传的值超过它也没用实际生效的是两者取小。提示排查连接建立慢的问题时可以看netstat -s | grep -i listen里的 overflow 计数如果 listen queue overflow 在涨说明 backlog 不够或者 accept 太慢。3.3 accept 的阻塞行为与并发模型的选择默认情况下accept()是阻塞的没有新连接来它就卡在那儿不动。单线程单连接的 demo 这么写没问题但真实服务端不可能这样。于是就有了几种经典模型第一种是每连接一线程accept 完就pthread_create开个线程去处理。写起来简单但连接数一多线程切换开销和内存占用就顶不住了几千个连接还行上万个就悬。第二种是IO 多路复用用一个线程管一堆 fd靠select/poll/epoll告诉你哪些 fd 可读可写。这是 Linux 下高并发服务端的主流做法epoll尤其适合连接数多但活跃连接少的场景。第三种是多进程主进程 accept 后 fork 子进程处理或者多个子进程各自 accept配合SO_REUSEPORT。这种模型隔离性好一个连接崩了不影响别的但进程间共享状态麻烦。选哪种取决于你的业务。连接数不大、逻辑复杂每连接一线程最省心追求高并发、IO 密集epoll 是标配。我个人的习惯是先用最简单的模型把功能跑通压测发现瓶颈了再换别一上来就上 epoll把代码搞得自己都看不懂。3.4 收发数据read/write 的返回值你必须逐个判断read()和write()的返回值是新手最容易忽略的地方。read()返回 0 表示对端关闭了连接收到 FIN返回 -1 表示出错要看 errno返回正数才是实际读到的字节数。而且这个字节数可能小于你请求的长度因为 TCP 是字节流内核缓冲区里有多少就给你多少不保证一次读满。所以正确的读法是循环读直到读够你要的长度或者遇到 0/-1。write()也一样返回值可能小于请求写入的长度尤其是在发送缓冲区快满的时候。如果你写的是大块数据必须循环写直到全部写完。我见过有人write(fd, buf, 1024)之后就不管了结果对端只收到 800 字节剩下 224 字节丢了排查半天以为是网络问题其实是自己没处理短写。还有个细节write()返回成功只代表数据进了内核发送缓冲区不代表对端收到了。真要确认对方收到得靠应用层的 ACK 机制。这也是为什么很多协议要设计“请求-响应”模式发完等回复而不是发完就当成功了。4. UDP 的脾气简单背后藏着丢包和乱序4.1 sendto 与 recvfrom没有连接每次都要带地址UDP 的收发接口是sendto()和recvfrom()比 TCP 多了个地址参数。服务端recvfrom()的时候除了拿到数据还能拿到发送方的地址这样才知道回给谁。客户端sendto()的时候要指定目标地址。整个过程中没有 connect、没有握手、没有状态维护发出去就不管了。这种“无连接”带来的好处是轻量不用维护连接状态一个 socket 可以同时跟无数个对端通信服务端不用为每个客户端开新 fd。DNS 服务器就是典型例子一个 UDP socket 处理所有查询收到请求查完就回简单高效。但代价也很明显。UDP 不保证送达网络拥塞时路由器可以直接丢包不保证顺序后发的包可能先到不保证不重复重传机制如果上层有可能产生重复包。所以用 UDP 的应用必须自己处理这些问题或者干脆接受这些缺陷——实时语音丢一帧无所谓但文件传输丢一个字节就废了。4.2 UDP 的缓冲区与最大报文别指望发多大数据UDP 有个硬限制单个数据报最大 65507 字节65535 减去 IP 头 20 字节和 UDP 头 8 字节。但实际网络中超过 MTU通常 1500 字节的包会被分片分片越多丢一个分片整个包就废了重传代价极高。所以实践里 UDP 单包一般控制在 1400 字节以内避免 IP 分片。接收端也有坑。UDP 的接收缓冲区如果满了新来的包会被直接丢弃而且不通知发送方。你recvfrom()读得慢缓冲区一满就开始丢包现象就是“偶尔丢几个包”。排查这种问题可以看netstat -su里的 receive buffer errors 计数。调大接收缓冲区用setsockopt的SO_RCVBUF但注意内核会把它翻倍并且有上限/proc/sys/net/core/rmem_max设太大也没用。4.3 什么时候该用 UDP三个真实场景的判断第一个场景是实时性优先于可靠性。视频会议、在线游戏的位置同步丢一两帧用户感知不到但如果为了重传卡住 200ms体验就崩了。这类场景 UDP 是正解。第二个场景是请求-响应且数据量小。DNS 查询一个域名发一个几十字节的包等一个几十字节的回复用 TCP 光握手就三次往返太重了。UDP 一问一答快得多。类似的还有 NTP 时间同步、DHCP 分配地址。第三个场景是广播和组播。TCP 是一对一的UDP 支持一对多。局域网里发现设备、服务注册广播都得靠 UDP。这也是为什么很多设备的发现协议用 UDP 实现。反过来说凡是“数据不能丢、不能乱、量大”的场景老老实实用 TCP别自己造轮子。我见过用 UDP 传配置文件的结果配置文件偶尔缺几行服务起不来查了一整天才发现是丢包。这种教训一次就够了。5. 粘包、半包与拆包TCP 字节流的必修课5.1 粘包不是 bug是你没定义边界“粘包”这个词吓退过不少人其实它根本不是 TCP 的缺陷而是字节流的天然属性。TCP 只负责把字节按顺序送到不负责帮你划分消息。你发了两条消息内核可能合并成一个包发出去Nagle 算法也可能拆成好几个包对端 read 的时候完全看运气。所以问题不在 TCP在于你的应用层协议没有定义“一条消息到哪儿结束”。解决办法有三种常见套路。第一种是固定长度每条消息定长读满 N 字节就是一条。简单但浪费空间适合消息长度固定的场景。第二种是分隔符比如用\n或特殊字符结尾读到分隔符就算一条。HTTP 的头部、Redis 的协议都这么干。第三种是长度前缀消息头里放一个字段标明正文长度先读头再读正文。这是最通用、最高效的做法二进制协议基本都用它。5.2 长度前缀协议的完整实现思路假设我们用 4 字节大端整数表示正文长度那收发的逻辑是这样的发送方先算出正文长度把 4 字节长度和正文拼在一起发出去接收方先读 4 字节解析出长度 N再循环读 N 字节正文。听起来简单但实际写的时候有两个坑。第一个坑是读长度头也可能读不全。TCP 不保证一次 read 给你 4 字节可能只给 2 字节。所以读头部也得循环直到凑够 4 字节。第二个坑是长度字段的字节序。网络传输统一用大端网络字节序你本机可能是小端收发时要用htonl/ntohl转换否则解析出来的长度是个天文数字程序直接崩。我一般会封装一个read_n(fd, buf, n)函数循环读直到读满 n 字节或出错所有读操作都走它。这样上层逻辑就干净了先read_n4 字节拿长度再read_n那个长度拿正文。写的时候同理封装write_n处理短写。这套封装看着朴素但能挡掉 80% 的收发 bug。5.3 缓冲区设计为什么不能一次 read 就当一条消息有些同学图省事read一次拿到多少就当成一条完整消息去解析结果偶尔解析失败偶尔丢数据。原因就是前面说的一次 read 的边界和消息边界没有任何关系。正确的做法是维护一个应用层接收缓冲区每次 read 到的数据追加到缓冲区末尾然后循环检查缓冲区里有没有完整消息按你的协议规则判断有就取出来处理剩下的留着等下次数据。这个模式叫“缓冲区 状态机”是所有健壮网络程序的基础。缓冲区的大小也要考虑。太小频繁拼接效率低太大内存浪费。一般设成单条最大消息长度的几倍或者干脆用动态扩容的缓冲区类似 Java 的 ByteBuffer 或 C 的 std::vector。关键是处理“半包”的情况数据不够一条消息时不能丢要留着等后续数据补齐。6. 阻塞、非阻塞与 IO 多路复用把并发这件事说透6.1 阻塞模式下一个线程只能伺候一个连接默认的 socket 是阻塞的。accept阻塞等新连接read阻塞等数据write在缓冲区满时也会阻塞。单线程程序里这意味着你 read 一个连接的时候别的连接来了也没人管。要同时处理多个连接最直接的办法就是开多线程每个线程管一个连接各自阻塞各自的。这就是“每连接一线程”模型。这个模型的问题在于扩展性。每个线程有独立的栈默认 8MB几千个连接就是几十 GB 虚拟内存线程切换有开销连接数一多CPU 大量时间花在上下文切换上。所以它适合连接数几百以内、逻辑较重的场景比如内部管理后台。上到万级连接就得换思路。6.2 非阻塞 epoll高并发服务端的标准答案把 fd 设成非阻塞O_NONBLOCK后read没数据会立刻返回 -1 并置errno为EAGAINaccept没新连接也立刻返回。这样单线程就不会卡住但你需要知道“什么时候该去读哪个 fd”总不能死循环挨个试那叫忙等待CPU 直接跑满。epoll就是解决这个问题的。你把关心的 fd 注册进去告诉它你关心“可读”还是“可写”然后调epoll_wait阻塞等待有事件发生时它返回一批就绪的 fd你挨个处理。它的高效之处在于内核用红黑树管理 fd、用就绪链表返回事件不用像select那样每次把整个 fd 集合从用户态拷到内核态也不用遍历所有 fd 找就绪的。连接数越多epoll的优势越明显。用epoll的典型流程是创建epoll实例 → 把监听 fd 加进去关心可读 → 循环epoll_wait→ 如果是监听 fd 就绪就accept新连接并把新 fd 加进去 → 如果是普通 fd 就绪就读数据、处理、写回复。这里有个细节epoll有水平触发LT和边缘触发ET两种模式。LT 是只要缓冲区还有数据就一直通知你写起来简单不容易漏ET 是只在状态变化时通知一次必须一次把数据读干净循环读到EAGAIN否则剩下的数据可能再也等不到通知。新手建议先用 LT稳。6.3 三种模型的取舍别为了高并发而高并发说了这么多到底该选哪个我的判断标准是看连接数和活跃比例。连接数少几百以内、每个连接都很活跃多线程阻塞模型最直观调试也方便。连接数多上万、但大部分连接不活跃比如长连接推送epoll是唯一选择。介于两者之间可以先用多线程跑着压测扛不住了再重构。还有个常被忽略的点epoll不是银弹。如果你的业务逻辑里有阻塞操作比如查数据库、读文件放在epoll的单线程里照样会卡住整个事件循环。这种时候要么用线程池把阻塞操作甩出去要么就老老实实多线程。架构选型永远是为业务服务的别被“高并发”三个字带偏。7. 排查实录那些年我们踩过的 socket 坑7.1 连接建立失败从三次握手找线索客户端connect失败报Connection refused通常是目标端口没在监听或者被防火墙挡了。先netstat -tlnp看服务端有没有在 listen再看iptables规则。如果是Connection timed out多半是网络不通或者 SYN 包被丢用tcpdump抓包看 SYN 有没有发出去、有没有收到 SYN-ACK。还有一种诡异情况connect一直阻塞不返回。这通常是 SYN 发出去了但没回应内核在重试默认重试 6 次耗时约 127 秒。可以调/proc/sys/net/ipv4/tcp_syn_retries缩短重试次数让失败来得快一点。排查时抓包最直接看 SYN 发了几次、对方有没有回。7.2 数据发出去收不到缓冲区、Nagle 与延迟确认有时候数据 write 成功了但对端迟迟收不到。原因可能有三。一是发送缓冲区满write阻塞或者返回短写数据还在本地排队。二是Nagle 算法在作怪它会把小包攒起来一起发导致延迟。对延迟敏感的场景可以设TCP_NODELAY关掉它。三是延迟确认接收方收到数据后不立刻回 ACK等一会儿看有没有数据要捎带回去这也会增加延迟。Nagle 和延迟确认凑一起可能产生几十到几百毫秒的额外延迟这就是著名的“Nagle延迟 ACK 互锁”问题。排查这类问题tcpdump抓包看时间戳最有效。看数据是什么时候发的、ACK 是什么时候回的中间隔了多久一目了然。如果发现是攒包导致的关 Nagle如果是 ACK 延迟考虑调整TCP_QUICKACK不过这个选项行为不太稳定慎用。7.3 常见问题速查表现象可能原因排查手段解决方向bind 报 Address already in use端口处于 TIME_WAITnetstat 看端口状态设 SO_REUSEADDRconnect 超时网络不通或 SYN 被丢tcpdump 抓 SYN查路由、防火墙连接建立慢accept 队列满netstat -s 看 overflow调大 backlog、加快 accept数据收不全没处理短读/短写打印 read/write 返回值循环读写直到完成消息错乱没定义消息边界检查协议设计加长度前缀或分隔符UDP 偶尔丢包接收缓冲区满netstat -su 看错误计数调大 SO_RCVBUF、加快读取高并发下卡顿阻塞操作拖累事件循环看 CPU 和线程状态阻塞操作甩到线程池7.4 几个我压箱底的小技巧第一个调试网络程序时把SO_RCVTIMEO和SO_SNDTIMEO设上别让 read/write 无限阻塞出问题时至少能超时返回方便定位。第二个服务端 accept 出来的 fd 记得设TCP_NODELAY除非你明确需要攒包。第三个写日志时把 fd、对端地址、读写字节数都打上出问题时日志就是最好的证据。第四个压测别只测正常流程故意制造慢客户端读得慢、发得慢很多缓冲区相关的 bug 只有在这种场景下才暴露。8. 写在最后socket 这门手艺靠的是对内核行为的敬畏我个人的体会是socket 编程的难点从来不在 API 本身那十几个函数一下午就能背完。难的是理解每个调用背后内核做了什么、没做什么以及当事情不按预期发展时知道去哪儿找答案。缓冲区、队列、状态机、字节序这些概念单拎出来都不复杂但组合在一起就成了一个需要反复调试、反复验证的系统。我见过太多人代码能跑就以为懂了直到线上出了个偶发的丢包或者连接泄漏才发现自己对底层一无所知。所以我的建议是别满足于“能跑”。每写一个网络程序都问自己几个问题这个参数为什么这么设数据从我的缓冲区到对方缓冲区中间经过了哪些环节如果对端突然消失我的程序会怎样把这些想清楚了你写的代码才经得起考验。后面如果还想深入可以去看tcpdump抓包分析、研究epoll的内核实现、或者读一读那本讲 TCP/IP 的经典书路还长着呢。
1. 从一次线上故障说起为什么我要把socket翻出来重讲一遍前阵子帮一个朋友排查他那个小服务的问题现象很怪客户端明明显示连接已经建立但发出去的数据就像石沉大海服务端日志里连个影子都没有。他一口咬定是业务逻辑写错了我让他把抓包结果发过来一看三次握手压根没走完卡在第二次。问题最后定位到他监听队列的 backlog 设得太小加上服务端处理 accept 的节奏太慢新连接全堵在半路上。这事儿让我意识到很多人写网络程序是“照着模板抄”socket 那几行代码背得滚瓜烂熟可一旦出问题脑子里没有一张从内核到应用的完整地图排查起来就是瞎猜。所以这篇东西我想把 Linux 下的 socket 编程从头到尾捋一遍重点落在 TCP 和 UDP 这两条主线上。它不是什么高深的东西就是操作系统给进程开的一扇“网络门”你往里写数据内核帮你打包发出去外面有数据进来内核帮你拆包放到缓冲区等你读。但恰恰是这扇门背后的机制——缓冲区、连接状态、阻塞与非阻塞、粘包与丢包——决定了你的程序是稳如老狗还是三天两头抽风。这篇文章适合谁看刚接触网络编程、能写个 echo server 但说不清背后原理的同学也适合工作几年、天天调 API 但对内核行为一知半解的开发者。我会把每个关键选择背后的“为什么”讲透配上能直接抄的代码和踩过的坑读完你至少能做到看到连接异常知道往哪个方向查写服务端知道 backlog、缓冲区、超时这些参数该怎么定。2. 先把 socket 这层窗户纸捅破它到底是什么2.1 socket 不是协议是内核给你的一张“收据”很多人初学时会混淆 socket 和 TCP/UDP 的关系。打个比方TCP 和 UDP 是两家不同的快递公司一个承诺必达、按顺序送一个只管扔出去、快但可能丢件而 socket 是你去寄件时拿到的那张单子上面写着收件地址、联系方式你凭这张单子跟快递公司打交道。也就是说socket 是应用层和传输层之间的编程接口是一个抽象出来的文件描述符。在 Linux 里“一切皆文件”socket 也不例外你拿到的是一个 int 型的 fd可以用 read/write 去操作它也可以用 close 关掉它。这个“文件”的特别之处在于它背后挂着一整套内核网络栈。你调用socket()的时候内核给你分配了一个 socket 结构体里面记录了协议族IPv4 还是 IPv6、套接字类型流式还是数据报、当前状态、发送和接收缓冲区等信息。真正干活的是内核你的进程只是通过系统调用给它下指令。理解这一点很关键因为后面所有的“坑”——缓冲区满、连接排队、数据粘包——本质上都是你在跟内核的这套机制博弈。2.2 流式与数据报TCP 和 UDP 在 socket 层面的根本分野创建 socket 时那个type参数决定了你走哪条路。SOCK_STREAM对应 TCPSOCK_DGRAM对应 UDP。这个选择不是随便挑的它直接决定了你后面代码的写法。TCP 是面向连接的字节流。什么叫字节流就是它不保留你发送时的“消息边界”。你分三次 write 了 “hello”、“world”、“!”对面 read 的时候可能一次读到 “helloworld!”也可能分五次读到碎片。它只保证字节顺序不乱、不丢、不重。这就要求应用层自己设计“怎么知道一条消息结束了”——这就是后面要讲的粘包问题的根源。UDP 是面向报文的。你 sendto 一个 100 字节的包对面 recvfrom 要么收到完整的 100 字节要么啥也收不到绝不会收到 50 字节。它保留了消息边界但代价是不保证送达、不保证顺序、不保证不重复。所以 UDP 适合那种“丢一两个包无所谓、但延迟要低”的场景比如实时音视频、游戏状态同步、DNS 查询。我见过不少新手拿 UDP 去传文件然后自己在上层实现重传和排序最后写出来的东西比 TCP 还慢还容易出错。这就是没搞清楚两者定位。选型的时候先问自己三个问题数据能不能丢对延迟敏不敏感需不需要按顺序到达答案清楚了选哪个自然就定了。2.3 一个 socket 的完整生命周期长什么样TCP 的 socket 生命周期是一条清晰的链socket()创建 →bind()绑定地址端口 →listen()进入监听 →accept()取出已完成连接的套接字 →read/write收发 →close()关闭。客户端则是socket()→connect()→ 收发 →close()。UDP 简单些服务端socket()→bind()→recvfrom/sendto客户端socket()→sendto/recvfrom没有 listen 和 accept 这一套。这里有个容易被忽略的点accept()返回的是一个全新的 fd和监听 fd 不是同一个。监听 fd 只负责“接客”新 fd 才是真正跟这个客户端通信的通道。所以一个服务端要同时处理多个客户端就得把每个 accept 出来的 fd 管好这就引出了后面 select/poll/epoll 的话题。很多模板代码里 accept 完不关新 fd或者把监听 fd 关了都是低级但要命的错误。3. TCP 服务端实操从 bind 到 accept 的每一步都有讲究3.1 地址复用与 bind那个让人抓狂的“Address already in use”写服务端第一个坑往往出现在重启的时候程序刚被杀掉马上再启动报Address already in use。这不是你的代码有 bug是 TCP 的连接状态机在作祟。主动关闭连接的一方会进入TIME_WAIT状态停留 2MSL一般是 60 秒左右这段时间里端口还被占着。解决办法是在bind()之前设置SO_REUSEADDRint opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt));这个选项的作用是允许绑定处于TIME_WAIT状态的地址。生产环境里几乎必开否则每次发布重启都可能起不来。还有个SO_REUSEPORT允许多个进程绑定同一个端口做负载均衡那是更进阶的用法普通场景用SO_REUSEADDR就够了。bind()的地址填法也有讲究。服务端一般填INADDR_ANY即 0.0.0.0表示监听本机所有网卡。如果你只想监听某个特定网卡就填那个网卡的 IP。端口填 0 的话内核会随机分配一个可用端口这在写测试客户端时有用但服务端肯定要指定固定端口。绑定失败除了端口占用还可能是权限问题——1024 以下的端口需要 root 权限普通用户绑不上。3.2 listen 的 backlog不是越大越好也不是随便填listen(fd, backlog)这个 backlog 到底指什么网上说法五花八门。准确地说它影响的是已完成连接队列accept queue的长度上限也就是三次握手已经完成、等着你 accept 的那些连接能排多长。注意不同内核版本对它的解释略有差异早期版本还会参考半连接队列SYN queue但现代内核里 backlog 主要管的是 accept 队列。那 backlog 设多少合适设太小高并发时新连接会被拒绝或者丢弃表现为客户端 connect 超时或收到 RST设太大占内存不说还可能掩盖你 accept 处理太慢的问题。我的经验是先估算你的 QPS 和单次 accept 处理耗时backlog 至少要能扛住“处理一个连接期间新进来的连接数”。比如你每秒处理 1000 个连接accept 一次耗时 1ms那理论上队列里最多积压 1 个但考虑到突发流量设个 128 到 1024 比较稳妥。内核还有个somaxconn参数/proc/sys/net/core/somaxconn会封顶你 listen 传的值超过它也没用实际生效的是两者取小。提示排查连接建立慢的问题时可以看netstat -s | grep -i listen里的 overflow 计数如果 listen queue overflow 在涨说明 backlog 不够或者 accept 太慢。3.3 accept 的阻塞行为与并发模型的选择默认情况下accept()是阻塞的没有新连接来它就卡在那儿不动。单线程单连接的 demo 这么写没问题但真实服务端不可能这样。于是就有了几种经典模型第一种是每连接一线程accept 完就pthread_create开个线程去处理。写起来简单但连接数一多线程切换开销和内存占用就顶不住了几千个连接还行上万个就悬。第二种是IO 多路复用用一个线程管一堆 fd靠select/poll/epoll告诉你哪些 fd 可读可写。这是 Linux 下高并发服务端的主流做法epoll尤其适合连接数多但活跃连接少的场景。第三种是多进程主进程 accept 后 fork 子进程处理或者多个子进程各自 accept配合SO_REUSEPORT。这种模型隔离性好一个连接崩了不影响别的但进程间共享状态麻烦。选哪种取决于你的业务。连接数不大、逻辑复杂每连接一线程最省心追求高并发、IO 密集epoll 是标配。我个人的习惯是先用最简单的模型把功能跑通压测发现瓶颈了再换别一上来就上 epoll把代码搞得自己都看不懂。3.4 收发数据read/write 的返回值你必须逐个判断read()和write()的返回值是新手最容易忽略的地方。read()返回 0 表示对端关闭了连接收到 FIN返回 -1 表示出错要看 errno返回正数才是实际读到的字节数。而且这个字节数可能小于你请求的长度因为 TCP 是字节流内核缓冲区里有多少就给你多少不保证一次读满。所以正确的读法是循环读直到读够你要的长度或者遇到 0/-1。write()也一样返回值可能小于请求写入的长度尤其是在发送缓冲区快满的时候。如果你写的是大块数据必须循环写直到全部写完。我见过有人write(fd, buf, 1024)之后就不管了结果对端只收到 800 字节剩下 224 字节丢了排查半天以为是网络问题其实是自己没处理短写。还有个细节write()返回成功只代表数据进了内核发送缓冲区不代表对端收到了。真要确认对方收到得靠应用层的 ACK 机制。这也是为什么很多协议要设计“请求-响应”模式发完等回复而不是发完就当成功了。4. UDP 的脾气简单背后藏着丢包和乱序4.1 sendto 与 recvfrom没有连接每次都要带地址UDP 的收发接口是sendto()和recvfrom()比 TCP 多了个地址参数。服务端recvfrom()的时候除了拿到数据还能拿到发送方的地址这样才知道回给谁。客户端sendto()的时候要指定目标地址。整个过程中没有 connect、没有握手、没有状态维护发出去就不管了。这种“无连接”带来的好处是轻量不用维护连接状态一个 socket 可以同时跟无数个对端通信服务端不用为每个客户端开新 fd。DNS 服务器就是典型例子一个 UDP socket 处理所有查询收到请求查完就回简单高效。但代价也很明显。UDP 不保证送达网络拥塞时路由器可以直接丢包不保证顺序后发的包可能先到不保证不重复重传机制如果上层有可能产生重复包。所以用 UDP 的应用必须自己处理这些问题或者干脆接受这些缺陷——实时语音丢一帧无所谓但文件传输丢一个字节就废了。4.2 UDP 的缓冲区与最大报文别指望发多大数据UDP 有个硬限制单个数据报最大 65507 字节65535 减去 IP 头 20 字节和 UDP 头 8 字节。但实际网络中超过 MTU通常 1500 字节的包会被分片分片越多丢一个分片整个包就废了重传代价极高。所以实践里 UDP 单包一般控制在 1400 字节以内避免 IP 分片。接收端也有坑。UDP 的接收缓冲区如果满了新来的包会被直接丢弃而且不通知发送方。你recvfrom()读得慢缓冲区一满就开始丢包现象就是“偶尔丢几个包”。排查这种问题可以看netstat -su里的 receive buffer errors 计数。调大接收缓冲区用setsockopt的SO_RCVBUF但注意内核会把它翻倍并且有上限/proc/sys/net/core/rmem_max设太大也没用。4.3 什么时候该用 UDP三个真实场景的判断第一个场景是实时性优先于可靠性。视频会议、在线游戏的位置同步丢一两帧用户感知不到但如果为了重传卡住 200ms体验就崩了。这类场景 UDP 是正解。第二个场景是请求-响应且数据量小。DNS 查询一个域名发一个几十字节的包等一个几十字节的回复用 TCP 光握手就三次往返太重了。UDP 一问一答快得多。类似的还有 NTP 时间同步、DHCP 分配地址。第三个场景是广播和组播。TCP 是一对一的UDP 支持一对多。局域网里发现设备、服务注册广播都得靠 UDP。这也是为什么很多设备的发现协议用 UDP 实现。反过来说凡是“数据不能丢、不能乱、量大”的场景老老实实用 TCP别自己造轮子。我见过用 UDP 传配置文件的结果配置文件偶尔缺几行服务起不来查了一整天才发现是丢包。这种教训一次就够了。5. 粘包、半包与拆包TCP 字节流的必修课5.1 粘包不是 bug是你没定义边界“粘包”这个词吓退过不少人其实它根本不是 TCP 的缺陷而是字节流的天然属性。TCP 只负责把字节按顺序送到不负责帮你划分消息。你发了两条消息内核可能合并成一个包发出去Nagle 算法也可能拆成好几个包对端 read 的时候完全看运气。所以问题不在 TCP在于你的应用层协议没有定义“一条消息到哪儿结束”。解决办法有三种常见套路。第一种是固定长度每条消息定长读满 N 字节就是一条。简单但浪费空间适合消息长度固定的场景。第二种是分隔符比如用\n或特殊字符结尾读到分隔符就算一条。HTTP 的头部、Redis 的协议都这么干。第三种是长度前缀消息头里放一个字段标明正文长度先读头再读正文。这是最通用、最高效的做法二进制协议基本都用它。5.2 长度前缀协议的完整实现思路假设我们用 4 字节大端整数表示正文长度那收发的逻辑是这样的发送方先算出正文长度把 4 字节长度和正文拼在一起发出去接收方先读 4 字节解析出长度 N再循环读 N 字节正文。听起来简单但实际写的时候有两个坑。第一个坑是读长度头也可能读不全。TCP 不保证一次 read 给你 4 字节可能只给 2 字节。所以读头部也得循环直到凑够 4 字节。第二个坑是长度字段的字节序。网络传输统一用大端网络字节序你本机可能是小端收发时要用htonl/ntohl转换否则解析出来的长度是个天文数字程序直接崩。我一般会封装一个read_n(fd, buf, n)函数循环读直到读满 n 字节或出错所有读操作都走它。这样上层逻辑就干净了先read_n4 字节拿长度再read_n那个长度拿正文。写的时候同理封装write_n处理短写。这套封装看着朴素但能挡掉 80% 的收发 bug。5.3 缓冲区设计为什么不能一次 read 就当一条消息有些同学图省事read一次拿到多少就当成一条完整消息去解析结果偶尔解析失败偶尔丢数据。原因就是前面说的一次 read 的边界和消息边界没有任何关系。正确的做法是维护一个应用层接收缓冲区每次 read 到的数据追加到缓冲区末尾然后循环检查缓冲区里有没有完整消息按你的协议规则判断有就取出来处理剩下的留着等下次数据。这个模式叫“缓冲区 状态机”是所有健壮网络程序的基础。缓冲区的大小也要考虑。太小频繁拼接效率低太大内存浪费。一般设成单条最大消息长度的几倍或者干脆用动态扩容的缓冲区类似 Java 的 ByteBuffer 或 C 的 std::vector。关键是处理“半包”的情况数据不够一条消息时不能丢要留着等后续数据补齐。6. 阻塞、非阻塞与 IO 多路复用把并发这件事说透6.1 阻塞模式下一个线程只能伺候一个连接默认的 socket 是阻塞的。accept阻塞等新连接read阻塞等数据write在缓冲区满时也会阻塞。单线程程序里这意味着你 read 一个连接的时候别的连接来了也没人管。要同时处理多个连接最直接的办法就是开多线程每个线程管一个连接各自阻塞各自的。这就是“每连接一线程”模型。这个模型的问题在于扩展性。每个线程有独立的栈默认 8MB几千个连接就是几十 GB 虚拟内存线程切换有开销连接数一多CPU 大量时间花在上下文切换上。所以它适合连接数几百以内、逻辑较重的场景比如内部管理后台。上到万级连接就得换思路。6.2 非阻塞 epoll高并发服务端的标准答案把 fd 设成非阻塞O_NONBLOCK后read没数据会立刻返回 -1 并置errno为EAGAINaccept没新连接也立刻返回。这样单线程就不会卡住但你需要知道“什么时候该去读哪个 fd”总不能死循环挨个试那叫忙等待CPU 直接跑满。epoll就是解决这个问题的。你把关心的 fd 注册进去告诉它你关心“可读”还是“可写”然后调epoll_wait阻塞等待有事件发生时它返回一批就绪的 fd你挨个处理。它的高效之处在于内核用红黑树管理 fd、用就绪链表返回事件不用像select那样每次把整个 fd 集合从用户态拷到内核态也不用遍历所有 fd 找就绪的。连接数越多epoll的优势越明显。用epoll的典型流程是创建epoll实例 → 把监听 fd 加进去关心可读 → 循环epoll_wait→ 如果是监听 fd 就绪就accept新连接并把新 fd 加进去 → 如果是普通 fd 就绪就读数据、处理、写回复。这里有个细节epoll有水平触发LT和边缘触发ET两种模式。LT 是只要缓冲区还有数据就一直通知你写起来简单不容易漏ET 是只在状态变化时通知一次必须一次把数据读干净循环读到EAGAIN否则剩下的数据可能再也等不到通知。新手建议先用 LT稳。6.3 三种模型的取舍别为了高并发而高并发说了这么多到底该选哪个我的判断标准是看连接数和活跃比例。连接数少几百以内、每个连接都很活跃多线程阻塞模型最直观调试也方便。连接数多上万、但大部分连接不活跃比如长连接推送epoll是唯一选择。介于两者之间可以先用多线程跑着压测扛不住了再重构。还有个常被忽略的点epoll不是银弹。如果你的业务逻辑里有阻塞操作比如查数据库、读文件放在epoll的单线程里照样会卡住整个事件循环。这种时候要么用线程池把阻塞操作甩出去要么就老老实实多线程。架构选型永远是为业务服务的别被“高并发”三个字带偏。7. 排查实录那些年我们踩过的 socket 坑7.1 连接建立失败从三次握手找线索客户端connect失败报Connection refused通常是目标端口没在监听或者被防火墙挡了。先netstat -tlnp看服务端有没有在 listen再看iptables规则。如果是Connection timed out多半是网络不通或者 SYN 包被丢用tcpdump抓包看 SYN 有没有发出去、有没有收到 SYN-ACK。还有一种诡异情况connect一直阻塞不返回。这通常是 SYN 发出去了但没回应内核在重试默认重试 6 次耗时约 127 秒。可以调/proc/sys/net/ipv4/tcp_syn_retries缩短重试次数让失败来得快一点。排查时抓包最直接看 SYN 发了几次、对方有没有回。7.2 数据发出去收不到缓冲区、Nagle 与延迟确认有时候数据 write 成功了但对端迟迟收不到。原因可能有三。一是发送缓冲区满write阻塞或者返回短写数据还在本地排队。二是Nagle 算法在作怪它会把小包攒起来一起发导致延迟。对延迟敏感的场景可以设TCP_NODELAY关掉它。三是延迟确认接收方收到数据后不立刻回 ACK等一会儿看有没有数据要捎带回去这也会增加延迟。Nagle 和延迟确认凑一起可能产生几十到几百毫秒的额外延迟这就是著名的“Nagle延迟 ACK 互锁”问题。排查这类问题tcpdump抓包看时间戳最有效。看数据是什么时候发的、ACK 是什么时候回的中间隔了多久一目了然。如果发现是攒包导致的关 Nagle如果是 ACK 延迟考虑调整TCP_QUICKACK不过这个选项行为不太稳定慎用。7.3 常见问题速查表现象可能原因排查手段解决方向bind 报 Address already in use端口处于 TIME_WAITnetstat 看端口状态设 SO_REUSEADDRconnect 超时网络不通或 SYN 被丢tcpdump 抓 SYN查路由、防火墙连接建立慢accept 队列满netstat -s 看 overflow调大 backlog、加快 accept数据收不全没处理短读/短写打印 read/write 返回值循环读写直到完成消息错乱没定义消息边界检查协议设计加长度前缀或分隔符UDP 偶尔丢包接收缓冲区满netstat -su 看错误计数调大 SO_RCVBUF、加快读取高并发下卡顿阻塞操作拖累事件循环看 CPU 和线程状态阻塞操作甩到线程池7.4 几个我压箱底的小技巧第一个调试网络程序时把SO_RCVTIMEO和SO_SNDTIMEO设上别让 read/write 无限阻塞出问题时至少能超时返回方便定位。第二个服务端 accept 出来的 fd 记得设TCP_NODELAY除非你明确需要攒包。第三个写日志时把 fd、对端地址、读写字节数都打上出问题时日志就是最好的证据。第四个压测别只测正常流程故意制造慢客户端读得慢、发得慢很多缓冲区相关的 bug 只有在这种场景下才暴露。8. 写在最后socket 这门手艺靠的是对内核行为的敬畏我个人的体会是socket 编程的难点从来不在 API 本身那十几个函数一下午就能背完。难的是理解每个调用背后内核做了什么、没做什么以及当事情不按预期发展时知道去哪儿找答案。缓冲区、队列、状态机、字节序这些概念单拎出来都不复杂但组合在一起就成了一个需要反复调试、反复验证的系统。我见过太多人代码能跑就以为懂了直到线上出了个偶发的丢包或者连接泄漏才发现自己对底层一无所知。所以我的建议是别满足于“能跑”。每写一个网络程序都问自己几个问题这个参数为什么这么设数据从我的缓冲区到对方缓冲区中间经过了哪些环节如果对端突然消失我的程序会怎样把这些想清楚了你写的代码才经得起考验。后面如果还想深入可以去看tcpdump抓包分析、研究epoll的内核实现、或者读一读那本讲 TCP/IP 的经典书路还长着呢。
