做网络编程练手项目大部分人第一站是 TCP 回显服务第二站是聊天室。但我越来越觉得想真正理解网络协议的本质是权衡这件事光写 TCP 是不够的UDP 才是那个逼你思考的题目。所以我用纯 C 在 Linux 上写了一个 UDP 版的 DictServer客户端把一个单词通过 UDP 报文发给服务器服务器在本地词库里查到释义再用一个报文把结果扔回来不建连接、不记状态、不保证送达。项目不大但把 UDP 无连接、有边界、不可靠这三个特性全部暴露在应用层面前。这个练手项目最适合两类人刚学完 socket 基础想找一个完整 UDP 项目的初学者以及在 TCP 里待太久想切换思维看无连接协议怎么设计的开发者。本文从协议设计、服务器实现、客户端重传、实测踩坑四个方向展开代码全部在 Linux x86_64 gcc 下跑过没有第三方依赖。你可以照着抄也可以只当避坑手册看。1. 协议先行DictServer 的请求/响应结构怎么定1.1 为什么字典服务是比回显服务更好的 UDP 练手项目回显服务确实简单但它把 UDP 最值得学的部分绕过去了。回显不涉及查表、不涉及多客户端区分、不涉及业务状态的构造做完只是把 recvfrom 的参数原样塞回 sendto。字典服务不一样它的业务模型是请求-响应查询这恰恰是 UDP 在真实世界中最常见的使用模式。你看 DNS域名到 IP 的映射查询本质上就是一个巨型字典服务NTP 的时间戳查询、DHCP 的配置获取也都是请求-响应。把 DictServer 理解透了再看这些协议会非常亲切。UDP 做请求-响应有两层天然优势。第一无连接意味着服务器不需要维护客户端状态客户端来了一个包处理完回一个包这个事务的生命周期就结束了不用像 TCP 那样维护连接表、处理半关闭、管理保活定时器。第二UDP 报文自带边界一次 recvfrom 必然拿回恰好一个报文不像 TCP 那样要处理粘包、半包、字节流切割。对字典查询这种一问一答的业务报文边界就是天然的协议边界省去大量代码。代价同样是这两点造成的既然没有连接那丢包、乱序、重复这些在 TCP 里被协议栈藏起来的问题全部要由应用层自己兜着。这就是为什么我说 UDP 的难度不在 API而在应用层设计。1.2 一个 5 字节头部加两个长度上限动手写代码前要先把字节布局定死。UDP 没有内核帮你做协议解析收进来的就是裸字节收发双方必须对第几个字节是什么有完全一致的约定。我的协议定义如下方向字段长度说明请求seq4 字节客户端自增序号网络字节序请求word0~63 字节单词原始字节不包含结尾符响应seq4 字节回显请求的 seq响应status1 字节0 命中1 未找到2 格式错误响应definition0~511 字节命中时的释义文本seq 字段是必须的。TCP 有连接内核帮你区分这个响应属于哪次请求UDP 没有这个机制客户端如果先后发出两个请求回来的响应各属于谁只能靠包里的序号分辨。后面讲客户端重传时你会看到seq 不仅是匹配响应的依据还是丢弃迟到包的关键。定义 word 上限 63、definition 上限 511不是随便拍的普通网卡 MTU 是 1500去掉 IP 头 20 字节和 UDP 头 8 字节单个 UDP 报文能携带的净荷是 1472 字节加上 5 字节头部再把 word 限在 63、释义限在 511怎么超都撞不上分片线。为了保证协议简单请求和响应都按定长上限处理超长的部分直接截断而不是做应用层分片——分片又是一套复杂度这个小项目用不上。另外一个约定服务器端对单词做规范化处理去掉首尾空白、统一转小写。这样客户端发 Hello、hello、 hello 查到的都是同一个词条。注意这个逻辑放在服务器而不是客户端客户端哪怕做得再糙服务器也能兜住。2. 服务器实现哈希词库加 recvfrom/sendto 主循环2.1 词库加载一次读取全部灌进哈希表词库文件格式我先定成一行一个词条单词和释义用 Tab 分隔。这样文件可以用任何编辑器维护脚本生成词库也方便。这里有个小细节用 fgets 读行时行尾的回车换行会带进缓冲区解析前必须剥掉行尾的\r和\n否则查词时永远匹配不上。加载词库的代码大致是这样static int load_dict(const char *path) { FILE *fp fopen(path, r); if (!fp) return -1; char line[1024]; while (fgets(line, sizeof(line), fp)) { char *tab strchr(line, \t); if (!tab) continue; *tab \0; size_t len strlen(line); while (len 0 (line[len-1] \r || line[len-1] \n)) line[--len] \0; WordEntry *e calloc(1, sizeof(WordEntry)); snprintf(e-word, sizeof(e-word), %s, line); snprintf(e-def, sizeof(e-def), %s, tab 1); unsigned int idx hash_str(e-word); e-next hash_table[idx]; hash_table[idx] e; } fclose(fp); return 0; }哈希表用的是链地址法每个桶是一个单向链表新词条头插。为什么用链地址而不是开放寻址因为词库只有构建期写入、运行期只读头插法实现最直白删除操作完全不需要链地址法是最省心的选择。哈希函数用的 djb2配合 8192 个桶几万词条规模下每个桶平均三四个元素查询冲突基本可以忽略。2.2 socket 初始化的三个关键决定服务器要做的 socket 初始化只有三步创建、设置选项、绑定。每一步都有值得说明的决定。第一用socket(AF_INET, SOCK_DGRAM, 0)创建套接字。SOCK_DGRAM 是 UDP 的套接字类型第三个参数固定传 0。这里暴露的第一个差异是TCP 用 SOCK_STREAM创建完还要 listen、acceptUDP 直接一个 socket 就能收发没有监听和连接的概念。第二设置 SO_REUSEADDR。这个选项在 TCP 上主要应对 TIME_WAIT 状态UDP 没有 TIME_WAIT但加上它依然是好习惯——进程崩溃重启时端口能立刻复用不会出现 bind 失败的难堪场面。真正决定多实例绑定的选项是 SO_REUSEPORT后面第五节再说。第三bind 到 INADDR_ANY 加固定端口。INADDR_ANY 表示绑定机器上的所有网卡地址无论客户端从哪个网卡进来都能收到包。端口必须用 htons 转换字节序这是初学者最容易忽略的点bind 之后发现收不到包先检查端口是不是写成了本机字节序。int fd socket(AF_INET, SOCK_DGRAM, 0); int reuse 1; setsockopt(fd, 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); bind(fd, (struct sockaddr *)addr, sizeof(addr));2.3 主循环与单线程就够了的判断逻辑主循环是服务器最核心的部分也是 UDP 服务器典型的事件驱动形态阻塞在 recvfrom 上收到一个请求处理完回一个响应然后继续阻塞。核心代码如下while (running) { ssize_t n recvfrom(fd, buf, sizeof(buf), 0, (struct sockaddr *)peer, peer_len); if (n 0) { if (errno EINTR) continue; perror(recvfrom); break; } if (n 5) continue; uint32_t seq; memcpy(seq, buf, 4); seq ntohl(seq); char word[MAX_WORD]; if (!normalize(word, sizeof(word), buf 4, n - 4)) { send_reply(fd, peer, seq, 2, ); continue; } const char *def lookup(word); send_reply(fd, peer, seq, def ? 0 : 1, def ? def : ); }运行标记 running 配合 SIGINT 信号处理让 CtrlC 能干净退出。recvfrom 在收到信号后会返回 EINTR此时 continue 重新进入循环由 running 判断决定是否退出这是一种不算优雅但足够可靠的服务关闭方式。send_reply 的实现同样直白把 seq 转回网络字节序拼上 status 和释义文本复制进发送缓冲区一次 sendto 发出去。这里有个小坑recvfrom 的缓冲区如果小于对方发来的报文长度内核会把多余部分直接丢弃且不给你任何提示。所以我故意把服务端 BUF_SIZE 开成 1024而协议最大响应是 41511516 字节等于把截断风险留给了协议外的异常流量。单线程循环够用吗判断标准只有一个单次请求的处理路径上有没有阻塞操作。字典查询是哈希查找O(1) 完成没有磁盘 IO、没有数据库连接整个路径上只有 recvfrom 和 sendto 两个系统调用是慢的而它们本来就是等待型操作。所以在单线程模型下吞吐瓶颈是系统调用本身而不是处理逻辑。我实测在 loopback 上自问自答每秒能处理十几万次查询响应对练手项目完全够用。如果将来词库换成数据库单线程就不够了届时的思路不是上线程锁而是用 SO_REUSEPORT 拉起多个进程让内核帮你分摊数据包第五节展开讲。3. 客户端实现把不可靠变成可用3.1 sendto 成功之后你什么都保证不了先记住一个反直觉的事实sendto 返回成功只代表数据被内核从你的进程里拿走了不代表对方收到了甚至不代表数据离开了本机。UDP 报文的旅程是你的进程 → 内核发送队列 → 网卡 → 网络 → 对端网卡 → 对端内核接收队列 → 对端进程。任何一环都可能出问题发送队列满、网卡出错、网络丢包、对端缓冲区溢出、对端进程没在读。TCP 会在协议栈里用 ACK 和重传把这些问题挡在应用层之外UDP 则是完全撒手不管。这就像寄平信你把信扔进邮筒邮局不会给你回执。对方没收到可能是路上丢了可能是邮筒满了没取走可能是对方压根不在家。你能做的只有一件事过一段时间再寄一封寄几次还杳无音信就认命。UDP 客户端的可靠性设计本质就是在模拟这套再寄一封的逻辑。3.2 用 select 把 recvfrom 变成可超时的等待最简单的等待方式是让 recvfrom 一直阻塞直到有响应但网络丢包是常态一旦丢包这个 recvfrom 会永远等下去程序就挂死了。所以客户端的第一个改造是给等待加超时。实现超时有两种常见写法一种是用 SO_RCVTIMEO 设置套接字接收超时超时后 recvfrom 返回 -1 并置 errno 为 EAGAIN另一种是用 select 在一段时间内等待套接字可读超时返回 0。我选了 select因为它的可组合性更好——将来客户端如果要同时监听标准输入、维护多个套接字fd_set 直接就能扩展而 SO_RCVTIMEO 只对当前 socket 生效。等待逻辑的核心函数如下static int recv_reply(int fd, uint32_t expect_seq, struct sockaddr_in *from, char *def, size_t def_size) { fd_set rset; struct timeval tv; char buf[BUF_SIZE]; FD_ZERO(rset); FD_SET(fd, rset); tv.tv_sec 0; tv.tv_usec 500000; // 500ms 超时 int ready select(fd 1, rset, NULL, NULL, tv); if (ready 0) return -1; // 超时或出错 socklen_t len sizeof(*from); ssize_t n recvfrom(fd, buf, sizeof(buf), 0, (struct sockaddr *)from, len); if (n 5) return -1; uint32_t seq; memcpy(seq, buf, 4); seq ntohl(seq); if (seq ! expect_seq) return -2; // 响应序号不匹配丢弃 int status (unsigned char)buf[4]; if (status 0) snprintf(def, def_size, %s, buf 5); else snprintf(def, def_size, (no definition)); return 0; }主流程就是循环发请求每次发完等 500ms超时后再发总共最多发三遍。三遍都没回应就告诉用户查询超时。超时时间的选取有门道太短会在网络拥塞时频繁重发加剧拥塞太长会让丢包后的单次查询延迟大到不可接受。500ms 对局域网来说很宽裕跨公网场景则需要放大到 1~2 秒同时把重试次数从 3 次降到 2 次避免给一个已经不可达的服务器持续制造流量。3.3 请求序号处理迟到响应和重传响应客户端把同一个请求发三遍服务器可能回三遍。三遍响应里第二遍和第三遍可能因为网络延迟而乱序到达也可能在客户端已经放弃等待后才姗姗来迟。没有 seq 的情况下客户端看到任何响应都当成当前请求的结果——当下一个请求发出去时上一个请求的迟到响应就会污染结果。有了 seq客户端可以精确判断这个包是为哪次请求服务的无关的包直接扔掉。我这个最小客户端里seq 每次运行都从 0 开始去重作用在单次运行里并不明显。想直观看到 seq 的价值把客户端扩展成一次启动连续查询多个单词每次查询 seq 加一然后在服务器端人为延迟某个响应你就能看到如果不用 seq 去重上一个单词的响应会被当成下一个单词的结果这个真实事故。这个模式在真实协议里到处都是DNS 报文头部的 ID 字段、TFTP 的块号确认、QUIC 的 packet number干的全是同一件事。4. 实测踩过的三个坑4.1 长释义触发 IP 分片报文直接静默消失第一次测长词条时我在词库里塞了一条 2000 字节的释义。请求一切正常服务器也正常调用了 sendto客户端却收不到任何响应也没有任何报错。排查到最后才意识到问题出在 IP 分片上UDP 净荷超过 1472 字节后IP 层会把数据报切成两个分片每个分片单独在网络上传送接收端必须重组完整才能交给 UDP 层。我的测试网络开了丢包模拟哪怕只丢其中一个分片重组也无法完成整个数据报被静默丢弃——客户端看到的表象是服务器没回和服务器宕机没有任何区别。注意1472 这个数字是以太网 MTU 1500 - IP 头 20 - UDP 头 8的结果。如果你的网络叠加了 VLAN 标签、隧道头安全上限还要再往下压所以我习惯把应用层报文控制在 1400 字节以内。这个坑的教训有两个层面。第一设计 UDP 应用层协议时报文长度必须按不分片来约束能塞进一个 MTU 的包才是好包。第二就算不分片大型报文的丢失概率也更高因为它占用更多链路时间被中间设备丢弃的窗口更大。所以我的协议把释义上限定在 511 字节是有意为之——宁可让长释义被截断也不要让它跨过 MTU 红线。4.2 接收缓冲区溢出请求消失得无声无息第二个坑来自一次压测。我写了脚本把几千个请求瞬间砸向服务器期望收到等量响应结果少了一截而且丢掉的请求毫无规律。服务器进程没有任何错误日志recvfrom 一直正常工作。最后是netstat -su救了我UDP 统计信息里有 packet receive errors 这一项压测时这个数字一路飙升。道理很简单内核为每个 UDP socket 维护一个接收队列默认容量在 Linux 上约 208KB换算成小请求报文大概能容纳几百个。队列满了之后新到的数据包被内核直接丢弃不给用户进程任何通知。这不是内核 bug而是保护机制——如果接收队列无上限内存会被洪水冲垮。TCP 有流量控制发送方会根据接收方窗口放缓速度UDP 没有这个机制突发流量超出接收能力时丢包就是常态只能靠应用层重传兜住。针对这个场景有三条缓解手段。一是用 setsockopt 调大 SO_RCVBUF把队列容量顶上去适合请求突发但总量可控的场景二是提高处理速度减少队列积压三是接受事实把可靠性交给客户端重传。测任何 UDP 服务记得先建立netstat -su的基线压测时盯着这几个计数器比盯着日志有用得多。4.3 服务没启动时客户端会收到 ECONNREFUSED 假象第三个坑特别容易误导排障。有一次服务器进程没起来客户端照常发第一个请求sendto 居然返回成功等第二个请求发出时sendto 却返回 -1errno 是 ECONNREFUSED。第一次接触时你会觉得莫名其妙UDP 是无连接协议哪来的拒绝实际机制是这样客户端发出的 UDP 报文到达目标主机后内核发现目标端口上没有进程监听就会回复一个 ICMP Port Unreachable 报文。这个 ICMP 报文反向到达客户端后客户端内核把它关联到发送该包的 socket 上在 socket 的错误队列里记下一笔。下一次在这个 socket 上做 recvfrom 或 sendto内核才把错误拿出来返回给应用层。所以你会看到第一个包成功、第二个包失败的诡异现象——第一个包触发的 ICMP 错误要等第二个包的操作才被消费。而且这个错误是一次性的被报告一次后 socket 就恢复正常第三个包 sendto 又会成功直到下一个 ICMP 到达。这个坑的实践价值有两点。第一看到 ECONNREFUSED 不要慌着下结论说协议坏了它大概率表示对端端口没有服务在监听是一个提前暴露问题的信号。第二客户端代码里可以把 ECONNREFUSED 当成立即放弃重传的快捷路径——既然端口不可达重传一万次也不会有结果不如直接报错省下 1.5 秒的重试时间。想要更精细的 ICMP 诊断信息可以研究 IP_RECVERR 配合 recvmsg 的 MSG_ERRQUEUE那是进阶玩法这个项目用不上。5. 验证手段与进阶改造5.1 抓包确认行为比猜靠谱得多写网络程序tcpdump 应该比 gdb 更常用。测试 DictServer 时我几乎全程开着它。抓 UDP 很简单一条命令sudo tcpdump -i any -nn udp and port 6666 -X跑起来之后再发一个查询能看到类似这样的输出IP 192.168.1.10.49300 192.168.1.20.6666: UDP, length 10 IP 192.168.1.20.6666 192.168.1.10.49300: UDP, length 26两个报文一来一回长度对得上说明协议交互正常。抓包最大的价值在于排查我以为发了但实际没发、对方以为回了但实际没回这类问题——tcpdump 看到的是内核和网卡层面的事实不经过任何应用层代码结论不会骗你。请求长度 10 是 4 字节 seq 加 6 字节单词响应长度 26 是 4 字节 seq 加 1 字节 status 加 21 字节释义算一算就能确认字节布局没有错位。5.2 tc netem 模拟丢包让问题浮出水面局域网环境丢包率几乎为零很多 UDP 问题在这种环境里根本复现不出来。Linux 自带的 netem 模块可以给网卡加网络损伤我用两条命令模拟 10% 的丢包率sudo tc qdisc add dev eth0 root netem loss 10% # 测试完删除 sudo tc qdisc del dev eth0 root加了丢包之后客户端的重传机制立刻有了用武之地。三遍请求中大约有 0.1% 的概率全部丢失对应一次完整超时其余情况在第二遍或第三遍后成功。观察到的单次查询延迟从局域网下不到 1 毫秒变成大约 500 毫秒到 1 秒的区间——那 500ms 是等待超时的时间属于最无奈的时间换确定性开销。如果你想进一步模拟网络抖动netem 还有 delay、duplicate、corrupt 等参数组合起来能还原相当真实的弱网环境。提示tc 的修改要在测试结束后及时删除否则整张网卡的所有流量都会受影响。另外不要在生产机器上做这种实验本地虚拟机是最合适的场地。我把没经过 netem 测试的 UDP 程序称作未经验证的程序这话一点不夸张。没有丢包环境你永远不知道自己写的重传逻辑是不是真的在工作。5.3 从单线程到多进程SO_REUSEPORT 的正确用法如果词库规模大到哈希查找仍嫌慢或者响应频率高到单进程无法消化下一步不是加线程而是用 SO_REUSEPORT 拉起多个进程。这个选项允许多个 socket 绑定到同一个 IP 和端口内核收到数据包时根据四元组哈希自动分发到其中一个 socket。对无连接的 UDP 来说这是最简单也最高效的横向扩展方式每个进程独立持有自己的哈希表副本进程之间零共享、零加锁比多线程方案的复杂度低一个量级。做法是把初始化部分改成同时设置 SO_REUSEADDR 和 SO_REUSEPORT然后 fork 出多个子进程每个子进程都执行自己的主循环。需要注意两点词库在 fork 之前加载一次子进程通过写时复制共享内存页省去重复加载SO_REUSEPORT 必须在每个进程 fork 之前、bind 之前就在 socket 上设置。内核分发不是严格负载均衡小数据包场景下会有些许偏差但数据包彼此独立时这个偏差通常不影响整体吞吐。我在四核机器上把进程数开到 4loopback 压测的 QPS 大约提升到单进程的 2.6 倍——没有线性增长因为系统调用和内存带宽还是瓶颈但这正是 UDP 服务从一个小玩具走向正经服务的第 0 步。最后啰嗦一点个人体会。做完这个小项目我最大的收获不是学会了 sendto/recvfrom而是理解了为什么所有正经的 UDP 协议都要自己造可靠性轮子——DNS 报文头部的 ID 字段和重试策略、TFTP 的块号确认与超时重传、QUIC 干脆在用户态实现了一整套可靠传输。它们面对的是同一个问题UDP 把传输控制权完全交给你你拿到一份最快但最不负责任的快递服务要不要签收、怎么确认、多久催一次全部由你决定。DictServer 把这个问题缩小到一屏代码以内是我知道的最低成本的入门路径。你照着跑通之后可以试试把协议加上应答序号、把重传策略改成指数退避、把响应长度约束换成应用层分块——每一个改动都会让你对网络协议多一层理解。
