用纯C实现UDP字典服务：理解无连接协议的关键

做网络编程练手项目，大部分人第一站是 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 没有内核帮你做协议解析，收进来的就是裸字节，收发双方必须对"第几个字节是什么"有完全一致的约定。我的协议定义如下：

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、accept，UDP 直接一个 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 信号处理，让 Ctrl+C 能干净退出。recvfrom 在收到信号后会返回 EINTR，此时 continue 重新进入循环，由 running 判断决定是否退出，这是一种不算优雅但足够可靠的服务关闭方式。

send_reply 的实现同样直白：把 seq 转回网络字节序，拼上 status 和释义文本，复制进发送缓冲区，一次 sendto 发出去。这里有个小坑：recvfrom 的缓冲区如果小于对方发来的报文长度，内核会把多余部分直接丢弃，且不给你任何提示。所以我故意把服务端 BUF_SIZE 开成 1024，而协议最大响应是 4+1+511=516 字节，等于把截断风险留给了协议外的异常流量。

单线程循环够用吗？判断标准只有一个：单次请求的处理路径上有没有阻塞操作。字典查询是哈希查找，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 却返回 -1，errno 是 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 上设置。内核分发不是严格负载均衡，小数据包场景下会有些许偏差，但数据包彼此独立时，这个偏差通常不影响整体吞吐。我在四核机器上把进程数开到 4，loopback 压测的 QPS 大约提升到单进程的 2.6 倍——没有线性增长，因为系统调用和内存带宽还是瓶颈，但这正是 UDP 服务从一个小玩具走向正经服务的第 0 步。

最后啰嗦一点个人体会。做完这个小项目，我最大的收获不是学会了 sendto/recvfrom，而是理解了为什么所有正经的 UDP 协议都要自己造可靠性轮子——DNS 报文头部的 ID 字段和重试策略、TFTP 的块号确认与超时重传、QUIC 干脆在用户态实现了一整套可靠传输。它们面对的是同一个问题：UDP 把传输控制权完全交给你，你拿到一份"最快但最不负责任"的快递服务，要不要签收、怎么确认、多久催一次，全部由你决定。DictServer 把这个问题缩小到一屏代码以内，是我知道的最低成本的入门路径。你照着跑通之后，可以试试把协议加上应答序号、把重传策略改成指数退避、把响应长度约束换成应用层分块——每一个改动都会让你对网络协议多一层理解。