1. 先搞清楚 UDP 到底是个什么东西1.1 一个真实踩过的坑为什么我的数据丢了先说个我自己的经历。早些年接手一个实时数据采集的下行通道服务端按固定周期往外推数据客户端那边一直报数据不全。第一反应是网络问题结果抓包一看服务端发出去的包一个不少客户端网卡也全都收到了问题出在客户端进程里——它在做业务处理时阻塞了两百多毫秒UDP 接收缓冲区被塞满后面来的包内核直接扔了连个错误码都不会返回给发送方。这就是 UDP 最本质的性格它只负责把数据从 A 搬到 B 的门口敲一下门就走门开不开、东西有没有人接它一概不管。这件事在 TCP 上几乎不可能发生因为 TCP 有滑动窗口和确认重传接收方处理不过来时窗口会收缩发送方自然就慢下来。UDP 没有这个机制发送方的节奏完全由应用自己控制。所以讨论 UDP永远绕不开一句话协议本身不保证什么所有的保证都得你在应用层自己实现。这句话听起来像废话但它是理解后面所有细节的总纲。你在 UDP 上遇到的每一个诡异问题——丢包、乱序、重复、截断——追到根上都是这一句。1.2 控制权在谁手里UDP 与 TCP 的分工逻辑把两者的差异摊开看其实不是谁好谁坏而是把复杂度放在哪一层的问题。TCP 把可靠性、顺序性、流量控制、拥塞控制全打包进了内核应用层拿到的是一条看起来永远不会出错的字节流。代价是你没法干预它的决策它认为该重传就重传该等就等你觉得延迟高也没辙除非换协议。UDP 则把这些全部剥离内核只做三件事加个 8 字节的头部、算一下校验和、按目的端口投递。剩下的可靠性、顺序、拥塞控制全部交给你。这意味着你可以做出 TCP 做不到的事比如不要重传。直播场景丢一帧画面无所谓但如果为了补那一帧卡住 200 毫秒体验反而更差。TCP 的队头阻塞在这是致命的UDP 天然没有这个问题。自己决定拥塞策略。有些业务知道自己的链路质量能比内核的通用算法调得更激进或者更保守。多路复用一条连接。QUIC 就是个典型多个逻辑流共用一个 UDP 端口某个流丢包不阻塞其他流。反过来说如果你的业务对丢数据零容忍又没什么特殊需求那老老实实用 TCP别为了快去用 UDP。我见过太多团队为了省那点握手延迟上了 UDP结果花三个月补可靠性层最后做出来的东西性能还不如 TCP因为他们的重传逻辑写得比内核差得远。1.3 哪些场景天生适合 UDP哪些千万别碰判断标准其实很朴素看数据的时间价值。时效性远大于完整性的UDP 是正解。音视频通话、实时对战、行情推送、监控画面这些场景里一个 200 毫秒前的位置更新毫无意义不如直接丢掉等下一个。DNS 查询也是经典案例一个请求一个响应用 TCP 得先握手三次UDP 一个来回就完事丢了就重发查询代价很低。状态同步类业务同样合适比如游戏里客户端每隔几十毫秒上报一次位置中间丢一两个包完全不影响因为下一个包会覆盖掉旧状态。这类最新值覆盖的模型UDP 用起来非常顺手。反过来文件传输、配置下发、账务流水、指令确认这些绝对不能丢的就别折腾了。还有一类容易忽略的响应体很大的请求。UDP 单个数据报最大 65507 字节IPv4 下减去 IP 头和 UDP 头一旦超过 MTU 就会被 IP 层分片而分片只要丢一片整个数据报就废了等于放大了丢包率。大包场景下 UDP 的表现会比 TCP 差得多。我通常给人一条粗糙但好用的判断线单条消息在 1200 字节以内、能容忍偶发丢失、或者丢了自己能重发且重发代价低满足这三条就可以考虑 UDP否则先老老实实 TCP。2. 报文结构8 个字节里的全部信息2.1 逐字段拆解每个字段都有坑UDP 头部短得让人安心就四个 16 位字段一共 8 字节。字段长度作用容易踩的坑源端口2 字节标识发送方端口可选置 0 表示不需要回包某些场景会导致中间设备不建映射目的端口2 字节用于投递无监听时回 ICMP 端口不可达但很多防火墙会吞掉长度2 字节头部数据的字节数最小为 8值不可信接收方应使用 IP 层给的实际长度校验和2 字节覆盖伪首部UDP 头数据IPv4 下可为 0 表示不校验IPv6 下强制必填长度字段这里有个细节值得说。理论上发送方填什么接收方就信什么但真实网络中经常出现长度字段和实际 IP 载荷长度对不上的情况中间设备改写、驱动 bug、虚拟化层的问题。Linux 内核的处理是以 IP 层提供的长度为准备长度字段只用来做校验。你自己写解析器时也别直接信这个字段容易越界读。校验和字段在 IPv4 下填 0 是合法的表示我不校验接收方直接放行。这个设计在当年是为了省算力现在基本没人这么干了因为一旦链路上有静默错误你收到的就是脏数据。IPv6 直接取消了这个选项必须计算。另一个必须知道的事实校验和是有可能算错的而且算错的方式很隐蔽。因为它用的是 16 位反码求和一个比特翻转能被检出的概率很高但不是 100%。对于要求高的场景光靠 UDP 校验和不够还得在应用层加一层 CRC 或者哈希。2.2 伪首部那个不存在的 12 字节算校验和的时候参与计算的不只是 UDP 报文本身前面还要虚拟地拼上一段伪首部内容包括源 IP、目的 IP、一个填 0 的字节、协议号 17、以及 UDP 长度。这段东西不会真的发到线路上只是为了让校验和能覆盖到 IP 地址防止包被错误投递到别的主机还能通过校验。IPv4 下伪首部是 12 字节IPv6 下是 40 字节两个 16 字节地址加 4 字节长度加 3 字节零和 1 字节下一头部。如果你的程序要手算校验和这里最容易出错——很多人算出来的校验和对不上99% 是伪首部拼错了或者是长度字段填了数据的长度而没算上 8 字节头部。UDP 长度在伪首部和真头部里出现的值是一样的都是8 数据长度。计算过程本身不复杂把所有 16 位字按大端拼起来相加溢出的高位回卷加到低位最后取反码。发出去的时候校验和字段本身先填 0。def udp_checksum(src_ip, dst_ip, payload): pseudo bytes(map(int, src_ip.split(.))) \ bytes(map(int, dst_ip.split(.))) \ b\x00\x11 len(payload).to_bytes(2, big) data pseudo payload if len(data) % 2: data b\x00 total 0 for i in range(0, len(data), 2): total (data[i] 8) data[i 1] total (total 0xffff) (total 16) return (~total) 0xffff这段代码可以直接拿去做单元测试验证方式很简单把你算出来的结果填进头部然后对整个报文含伪首部再算一遍结果应该是 0。2.3 MTU 与分片为什么你的大包总是收不全这是 UDP 实操里最常见的问题没有之一。以太网的标准 MTU 是 1500 字节减去 20 字节 IP 头、8 字节 UDP 头单个 UDP 数据报的载荷最多 1472 字节。超过这个数IP 层就会分片把一个 UDP 数据报拆成多个 IP 分片发送。分片的问题在于任何一个分片丢失整个 UDP 数据报都无法重组接收方直接丢弃全部。假设链路丢包率 1%一个拆成 4 片的数据报全部到达的概率是 0.99^4 ≈ 96%等效丢包率一下涨到 4%。如果拆成 10 片等效丢包率接近 10%。这就是为什么说大包会放大丢包。更麻烦的是路径 MTU。从你到对方中间可能经过 PPPoE、隧道、虚拟网络实际可用的 MTU 可能只有 1400 甚至更低。如果设置了 IP 层的不分片标志DF超大的包会被中间设备丢弃并可能返回一个 ICMP 需要分片的错误——但这个 ICMP 在很多网络里是被过滤掉的于是你看到的现象就是小包能过大包全丢毫无线索。我的经验做法是业务层把单个 UDP 载荷控制在 1200 字节以内。这个数字留了足够余量能覆盖绝大多数现实网络路径。如果你的数据本来就大别指望 IP 分片自己在应用层切块、编号、重组这样至少能知道哪一块丢了、要不要补。3. 动手搭一个能用的 UDP 通道3.1 先跑通最小可用的收发先把裸的收发跑通别急着上业务逻辑。服务端大概长这样import socket srv socket.socket(socket.AF_INET, socket.SOCK_DGRAM) srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) srv.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 4 * 1024 * 1024) srv.bind((0.0.0.0, 9999)) print(listening, srv.getsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF)) while True: data, addr srv.recvfrom(2048) seq int.from_bytes(data[:4], big) srv.sendto(seq.to_bytes(4, big), addr)两个细节要留意。一个是我用recvfrom(2048)而不是 65535因为缓冲区开太大会让每次系统调用的开销变大而实际业务包根本到不了那么大如果你的业务确实需要收大包那再调。另一个是打印出来的SO_RCVBUF值会是你设置值的两倍——这不是 bug内核在记账时按两倍计算用来覆盖协议头的额外开销所以你设 4MB实际生效的可能是 8MB但这个值仍然受net.core.rmem_max上限约束。客户端import socket cli socket.socket(socket.AF_INET, socket.SOCK_DGRAM) cli.settimeout(1.0) for i in range(5): cli.sendto(i.to_bytes(4, big), (127.0.0.1, 9999)) try: resp, _ cli.recvfrom(2048) print(ack, int.from_bytes(resp, big)) except socket.timeout: print(timeout, i)注意这里的settimeout只是让recvfrom不永久阻塞它并不会让内核帮你重传。超时之后要不要重发、重发几次、间隔多久全是你的决定。3.2 在应用层补一个够用的可靠层绝大多数业务不需要完整的 TCP 语义只需要重要消息必达 重复消息去重。照着这个目标设计头部 12 字节就够偏移长度含义04会话 ID区分不同客户端44序列号单调递增81标志位bit0 表示需要确认91消息类型102载荷长度打包用struct.pack(!IIBBH, sid, seq, flags, mtype, plen)就行注意用大端。接收侧维护一个滑动窗口和已收到的序列号集合序列号小于窗口左边界的直接判为重复丢弃落在窗口内的收下并记录同时回一个只带序列号的 ACK序列号跳跃说明中间丢了先缓存后面的包等缺口补齐再按顺序交给业务层如果业务不要求顺序这一步可以省掉。重传策略上我不建议用固定间隔。首次重传等 200 毫秒之后每次翻倍上限 2 秒重传超过 5 次就判定链路失效。这个参数组合在局域网和普通公网环境下都比较稳弱网环境下可以适当放宽首包时间。有个容易忽略的点ACK 本身也可能丢。如果接收方收到重复包就重发 ACK发送方可能会收到多个 ACK这无所谓去重逻辑在发送侧处理掉就行。反过来如果接收方对重复包不理不睬发送方就会一直重传直到次数耗尽。所以规则要定清楚收到重复包照样回 ACK但不要重复提交给业务层。3.3 抓包验证眼见为实写完代码一定要抓包看光靠日志看不出真相。tcpdump -i any -nn udp port 9999 -vv -X -c 20-X会把十六进制和 ASCII 一起打出来你能直接对着自己设计的头部逐字节核对。有一次我死活对不上序列号最后发现是struct.pack漏了!用了本机字节序在小端机器上打包顺序全反了。还有一个抓包时的经典困惑你会看到自己发出的包校验和是错的。别慌这是网卡和内核的校验和卸载机制在起作用抓包点位于计算之前所以抓到的是未计算状态真实包发到线上是正确的。验证办法是在接收端抓如果接收端算出来是对的就说明没问题。4. 内核参数与高并发收包4.1 缓冲区最容易成为瓶颈的地方UDP 没有流控发送方想发多快就发多快接收方处理不过来时超出缓冲区容量的包直接丢弃。这个丢弃是静默的应用层收不到任何错误只能通过内核计数器发现。先看要监控什么nstat -az | grep -i udp ss -uanm | head -20重点看几个计数器UdpRcvbufErrors表示因接收缓冲区满而丢弃的包数UdpInErrors是各类入向错误的总和UdpInCsumErrors是校验和失败UdpNoPorts是目的端口没人监听。只要UdpRcvbufErrors在涨就说明你的应用处理速度跟不上或者缓冲区太小。调参顺序我一般是这样的参数作用建议值按业务量级net.core.rmem_max单个 socket 接收缓冲区上限8MB ~ 32MBnet.core.netdev_max_backlog网卡到协议栈的队列长度5000 ~ 20000net.core.rmem_default默认接收缓冲区1MB ~ 4MBnet.ipv4.udp_memUDP 全局内存页数低/压力/高按物理内存 5%~10% 估net.ipv4.ipfrag_high_threshIP 分片重组队列上限按需调大但别指望它改完rmem_max之后应用里setsockopt设置的值才能生效否则内核会把它悄悄截断到上限你设了 32MB 实际只有 208KB然后纳闷为什么还是丢包。另一个提升收包能力的办法是批量收包。Linux 提供recvmmsg一次系统调用能取多个报文在高包量场景下能把 CPU 占用砍掉一大截。Python 没有直接暴露这个接口得用ctypes或者换成 C/Go。如果你的 QPS 到了每秒几万包的量级一次收一个包的开销就开始显著了。4.2 中间设备不待见沉默的 UDP这个坑我踩过不止一次。UDP 是无连接的中间设备为了省资源会给每个映射表项设置老化时间通常是几十秒。如果你的应用长时间不发包表项就被回收了之后对方再发过来的包找不到对应关系直接被丢。现象很有迷惑性连接看起来还在但一段时间没数据之后突然就收不到了重连一下又好了。解决办法是心跳但心跳间隔要掐准。默认老化时间如果是 30 秒那你得在 15 到 20 秒内至少发一次包。不要去猜直接问网络运维拿实际配置或者自己做实验每隔一秒发个探针看第几次开始收不到回包。心跳包还有个小技巧带上递增的序号并且要求对端回 ACK。单向发包只能保活自己这侧的表项如果对侧也要保活必须有来回。4.3 多线程与端口复用单个 UDP socket 在多核机器上会成为瓶颈因为所有包都进同一个接收队列。SO_REUSEPORT能让多个进程/线程绑定到同一端口内核按四元组做哈希分发每个 socket 有独立的队列天然并行。int one 1; setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, one, sizeof(one));要注意的是哈希分发是按四元组来的同一个客户端的所有包会固定落到同一个 socket 上所以这不会打乱单个会话的包顺序但也意味着热点客户端无法被分摊。如果你的流量集中在少数几个大客户端上SO_REUSEPORT帮助有限得改架构。还有一点SO_REUSEPORT时不要指望SO_REUSEADDR帮你解决一切。两者语义不同前者是负载均衡后者是允许绑定处于 TIME_WAIT 状态的端口混用会出问题尤其多进程启动时可能出现某个进程一个包都收不到。5. 排查实录六类高频问题5.1 问题速查表现象最可能的原因排查动作完全收不到包绑定了 127.0.0.1 / 防火墙拦截 / 端口填错ss -uan看是否监听在 0.0.0.0对端nc -u试探小包正常大包 100% 丢路径 MTU 小于包长且 DF 置位ping -M do -s 1472逐级试探业务层限长 1200偶发丢包且UdpRcvbufErrors涨接收缓冲区满调大rmem_max和SO_RCVBUF优化处理逻辑UdpInCsumErrors持续增长链路错误或中间设备篡改抓包对比检查是否有设备做内容改写空闲一段时间后断流中间设备映射表项老化加双向心跳间隔小于老化时间sendto返回ENOBUFS发送缓冲区满或本地路由不可达检查SO_SNDBUF、网卡队列、路由表5.2 几个不那么明显的细节第一个bind的地址。绑定127.0.0.1只能收本机回环的包绑定0.0.0.0才是所有网卡。这个错误太低级但我见过在容器环境里因为绑定到了容器内部 IP导致宿主机转发过来的包被丢的情况。第二个端口不可达的反馈是 ICMP。你往一个没监听的端口发 UDP对端会回一个 ICMP 端口不可达。但很多网络设备会过滤这类消息所以你看到的是发了没反应而不是连接被拒绝。这也意味着 UDP 的connect()并不会真正建立连接它只是在内核里记下对端地址方便用send()而不是sendto()。第三个recvfrom的缓冲区大小决定截断。如果传入的 bufsize 小于实际数据报长度多出来的部分会被静默丢弃返回的长度是 bufsize 而不是真实长度。你在应用层看到的就是数据被截断了但没有任何错误提示。这就是开头那个故事的另一个版本——所以缓冲区大小一定要比预期最大包长还大一点。第四个零长度 UDP 包是合法的。头部 8 字节载荷 0 字节能正常收发。有些扫描工具会用它探测端口你的代码如果假设收到包至少有几个字节容易在解析头部时崩掉。第五个并发下的乱序比想象中更常见。不只是网络路径会导致乱序多线程收包、多队列网卡、SO_REUSEPORT分发加上不同核之间的调度延迟都可能让包的处理顺序和到达顺序不一致。所以但凡业务依赖顺序序列号必须在应用层判别假设内核会按序交给你。第六个容器和虚拟化环境的 MTU 往往不是 1500。常见的是 1450 或 1400叠了隧道之后可能更低。跨环境部署时不要硬编码 1472启动时做一次探测或者直接把上限压到 1200省心。6. 我在实际项目里的一些处理习惯写得差不多了说几个不成体系但确实管用的习惯。永远在应用层给 UDP 加一个序列号和时间戳。就算业务不要求可靠加上这两个字段也几乎没有成本但出问题时能立刻判断是丢了、重了还是晚了。没有序列号的 UDP 日志基本没法分析你连到底丢了多少都说不清。别迷信UDP 一定比 TCP 快。在丢包率低的链路上两者的差距远没有想象中大尤其当你自己实现的重传逻辑不如内核精细时。我测过一些场景加了简单重传层的 UDP 在弱网下反而不如 TCP 稳定。选型时先量一量实际链路质量别凭感觉。压测要模拟真实网络条件。本机回环测出来的数据毫无参考价值因为回环几乎不丢包也不乱序。用tc netem注入延迟和丢包再去测tc qdisc add dev eth0 root netem delay 50ms loss 1% reorder 5%这行命令能让你在实验室里重现大部分线上问题调完参数记得tc qdisc del dev eth0 root清掉不然忘了这回事会把后面的测试结果全带偏。监控一定要盯内核计数器而不是只看应用日志。应用层能看到的只是我收到了什么看不到内核替我扔了什么。把UdpRcvbufErrors、UdpInErrors这两个指标接进监控设个告警阈值比出事后翻日志高效得多。最后一条如果你的可靠性需求超过了重发几次 去重这个量级认真考虑一下现成的方案。自己从零写拥塞控制、流控、多路复用投入产出比通常很差而且很容易在某些边界条件下出问题。这部分工作量远比看起来大我见过不止一个团队低估了它。 
长河君 · 2026/10/25 4:26:46 · 阅读 1.2k UDP协议原理、应用层可靠传输与高并发调优实战
1. 先搞清楚 UDP 到底是个什么东西1.1 一个真实踩过的坑为什么我的数据丢了先说个我自己的经历。早些年接手一个实时数据采集的下行通道服务端按固定周期往外推数据客户端那边一直报数据不全。第一反应是网络问题结果抓包一看服务端发出去的包一个不少客户端网卡也全都收到了问题出在客户端进程里——它在做业务处理时阻塞了两百多毫秒UDP 接收缓冲区被塞满后面来的包内核直接扔了连个错误码都不会返回给发送方。这就是 UDP 最本质的性格它只负责把数据从 A 搬到 B 的门口敲一下门就走门开不开、东西有没有人接它一概不管。这件事在 TCP 上几乎不可能发生因为 TCP 有滑动窗口和确认重传接收方处理不过来时窗口会收缩发送方自然就慢下来。UDP 没有这个机制发送方的节奏完全由应用自己控制。所以讨论 UDP永远绕不开一句话协议本身不保证什么所有的保证都得你在应用层自己实现。这句话听起来像废话但它是理解后面所有细节的总纲。你在 UDP 上遇到的每一个诡异问题——丢包、乱序、重复、截断——追到根上都是这一句。1.2 控制权在谁手里UDP 与 TCP 的分工逻辑把两者的差异摊开看其实不是谁好谁坏而是把复杂度放在哪一层的问题。TCP 把可靠性、顺序性、流量控制、拥塞控制全打包进了内核应用层拿到的是一条看起来永远不会出错的字节流。代价是你没法干预它的决策它认为该重传就重传该等就等你觉得延迟高也没辙除非换协议。UDP 则把这些全部剥离内核只做三件事加个 8 字节的头部、算一下校验和、按目的端口投递。剩下的可靠性、顺序、拥塞控制全部交给你。这意味着你可以做出 TCP 做不到的事比如不要重传。直播场景丢一帧画面无所谓但如果为了补那一帧卡住 200 毫秒体验反而更差。TCP 的队头阻塞在这是致命的UDP 天然没有这个问题。自己决定拥塞策略。有些业务知道自己的链路质量能比内核的通用算法调得更激进或者更保守。多路复用一条连接。QUIC 就是个典型多个逻辑流共用一个 UDP 端口某个流丢包不阻塞其他流。反过来说如果你的业务对丢数据零容忍又没什么特殊需求那老老实实用 TCP别为了快去用 UDP。我见过太多团队为了省那点握手延迟上了 UDP结果花三个月补可靠性层最后做出来的东西性能还不如 TCP因为他们的重传逻辑写得比内核差得远。1.3 哪些场景天生适合 UDP哪些千万别碰判断标准其实很朴素看数据的时间价值。时效性远大于完整性的UDP 是正解。音视频通话、实时对战、行情推送、监控画面这些场景里一个 200 毫秒前的位置更新毫无意义不如直接丢掉等下一个。DNS 查询也是经典案例一个请求一个响应用 TCP 得先握手三次UDP 一个来回就完事丢了就重发查询代价很低。状态同步类业务同样合适比如游戏里客户端每隔几十毫秒上报一次位置中间丢一两个包完全不影响因为下一个包会覆盖掉旧状态。这类最新值覆盖的模型UDP 用起来非常顺手。反过来文件传输、配置下发、账务流水、指令确认这些绝对不能丢的就别折腾了。还有一类容易忽略的响应体很大的请求。UDP 单个数据报最大 65507 字节IPv4 下减去 IP 头和 UDP 头一旦超过 MTU 就会被 IP 层分片而分片只要丢一片整个数据报就废了等于放大了丢包率。大包场景下 UDP 的表现会比 TCP 差得多。我通常给人一条粗糙但好用的判断线单条消息在 1200 字节以内、能容忍偶发丢失、或者丢了自己能重发且重发代价低满足这三条就可以考虑 UDP否则先老老实实 TCP。2. 报文结构8 个字节里的全部信息2.1 逐字段拆解每个字段都有坑UDP 头部短得让人安心就四个 16 位字段一共 8 字节。字段长度作用容易踩的坑源端口2 字节标识发送方端口可选置 0 表示不需要回包某些场景会导致中间设备不建映射目的端口2 字节用于投递无监听时回 ICMP 端口不可达但很多防火墙会吞掉长度2 字节头部数据的字节数最小为 8值不可信接收方应使用 IP 层给的实际长度校验和2 字节覆盖伪首部UDP 头数据IPv4 下可为 0 表示不校验IPv6 下强制必填长度字段这里有个细节值得说。理论上发送方填什么接收方就信什么但真实网络中经常出现长度字段和实际 IP 载荷长度对不上的情况中间设备改写、驱动 bug、虚拟化层的问题。Linux 内核的处理是以 IP 层提供的长度为准备长度字段只用来做校验。你自己写解析器时也别直接信这个字段容易越界读。校验和字段在 IPv4 下填 0 是合法的表示我不校验接收方直接放行。这个设计在当年是为了省算力现在基本没人这么干了因为一旦链路上有静默错误你收到的就是脏数据。IPv6 直接取消了这个选项必须计算。另一个必须知道的事实校验和是有可能算错的而且算错的方式很隐蔽。因为它用的是 16 位反码求和一个比特翻转能被检出的概率很高但不是 100%。对于要求高的场景光靠 UDP 校验和不够还得在应用层加一层 CRC 或者哈希。2.2 伪首部那个不存在的 12 字节算校验和的时候参与计算的不只是 UDP 报文本身前面还要虚拟地拼上一段伪首部内容包括源 IP、目的 IP、一个填 0 的字节、协议号 17、以及 UDP 长度。这段东西不会真的发到线路上只是为了让校验和能覆盖到 IP 地址防止包被错误投递到别的主机还能通过校验。IPv4 下伪首部是 12 字节IPv6 下是 40 字节两个 16 字节地址加 4 字节长度加 3 字节零和 1 字节下一头部。如果你的程序要手算校验和这里最容易出错——很多人算出来的校验和对不上99% 是伪首部拼错了或者是长度字段填了数据的长度而没算上 8 字节头部。UDP 长度在伪首部和真头部里出现的值是一样的都是8 数据长度。计算过程本身不复杂把所有 16 位字按大端拼起来相加溢出的高位回卷加到低位最后取反码。发出去的时候校验和字段本身先填 0。def udp_checksum(src_ip, dst_ip, payload): pseudo bytes(map(int, src_ip.split(.))) \ bytes(map(int, dst_ip.split(.))) \ b\x00\x11 len(payload).to_bytes(2, big) data pseudo payload if len(data) % 2: data b\x00 total 0 for i in range(0, len(data), 2): total (data[i] 8) data[i 1] total (total 0xffff) (total 16) return (~total) 0xffff这段代码可以直接拿去做单元测试验证方式很简单把你算出来的结果填进头部然后对整个报文含伪首部再算一遍结果应该是 0。2.3 MTU 与分片为什么你的大包总是收不全这是 UDP 实操里最常见的问题没有之一。以太网的标准 MTU 是 1500 字节减去 20 字节 IP 头、8 字节 UDP 头单个 UDP 数据报的载荷最多 1472 字节。超过这个数IP 层就会分片把一个 UDP 数据报拆成多个 IP 分片发送。分片的问题在于任何一个分片丢失整个 UDP 数据报都无法重组接收方直接丢弃全部。假设链路丢包率 1%一个拆成 4 片的数据报全部到达的概率是 0.99^4 ≈ 96%等效丢包率一下涨到 4%。如果拆成 10 片等效丢包率接近 10%。这就是为什么说大包会放大丢包。更麻烦的是路径 MTU。从你到对方中间可能经过 PPPoE、隧道、虚拟网络实际可用的 MTU 可能只有 1400 甚至更低。如果设置了 IP 层的不分片标志DF超大的包会被中间设备丢弃并可能返回一个 ICMP 需要分片的错误——但这个 ICMP 在很多网络里是被过滤掉的于是你看到的现象就是小包能过大包全丢毫无线索。我的经验做法是业务层把单个 UDP 载荷控制在 1200 字节以内。这个数字留了足够余量能覆盖绝大多数现实网络路径。如果你的数据本来就大别指望 IP 分片自己在应用层切块、编号、重组这样至少能知道哪一块丢了、要不要补。3. 动手搭一个能用的 UDP 通道3.1 先跑通最小可用的收发先把裸的收发跑通别急着上业务逻辑。服务端大概长这样import socket srv socket.socket(socket.AF_INET, socket.SOCK_DGRAM) srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) srv.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 4 * 1024 * 1024) srv.bind((0.0.0.0, 9999)) print(listening, srv.getsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF)) while True: data, addr srv.recvfrom(2048) seq int.from_bytes(data[:4], big) srv.sendto(seq.to_bytes(4, big), addr)两个细节要留意。一个是我用recvfrom(2048)而不是 65535因为缓冲区开太大会让每次系统调用的开销变大而实际业务包根本到不了那么大如果你的业务确实需要收大包那再调。另一个是打印出来的SO_RCVBUF值会是你设置值的两倍——这不是 bug内核在记账时按两倍计算用来覆盖协议头的额外开销所以你设 4MB实际生效的可能是 8MB但这个值仍然受net.core.rmem_max上限约束。客户端import socket cli socket.socket(socket.AF_INET, socket.SOCK_DGRAM) cli.settimeout(1.0) for i in range(5): cli.sendto(i.to_bytes(4, big), (127.0.0.1, 9999)) try: resp, _ cli.recvfrom(2048) print(ack, int.from_bytes(resp, big)) except socket.timeout: print(timeout, i)注意这里的settimeout只是让recvfrom不永久阻塞它并不会让内核帮你重传。超时之后要不要重发、重发几次、间隔多久全是你的决定。3.2 在应用层补一个够用的可靠层绝大多数业务不需要完整的 TCP 语义只需要重要消息必达 重复消息去重。照着这个目标设计头部 12 字节就够偏移长度含义04会话 ID区分不同客户端44序列号单调递增81标志位bit0 表示需要确认91消息类型102载荷长度打包用struct.pack(!IIBBH, sid, seq, flags, mtype, plen)就行注意用大端。接收侧维护一个滑动窗口和已收到的序列号集合序列号小于窗口左边界的直接判为重复丢弃落在窗口内的收下并记录同时回一个只带序列号的 ACK序列号跳跃说明中间丢了先缓存后面的包等缺口补齐再按顺序交给业务层如果业务不要求顺序这一步可以省掉。重传策略上我不建议用固定间隔。首次重传等 200 毫秒之后每次翻倍上限 2 秒重传超过 5 次就判定链路失效。这个参数组合在局域网和普通公网环境下都比较稳弱网环境下可以适当放宽首包时间。有个容易忽略的点ACK 本身也可能丢。如果接收方收到重复包就重发 ACK发送方可能会收到多个 ACK这无所谓去重逻辑在发送侧处理掉就行。反过来如果接收方对重复包不理不睬发送方就会一直重传直到次数耗尽。所以规则要定清楚收到重复包照样回 ACK但不要重复提交给业务层。3.3 抓包验证眼见为实写完代码一定要抓包看光靠日志看不出真相。tcpdump -i any -nn udp port 9999 -vv -X -c 20-X会把十六进制和 ASCII 一起打出来你能直接对着自己设计的头部逐字节核对。有一次我死活对不上序列号最后发现是struct.pack漏了!用了本机字节序在小端机器上打包顺序全反了。还有一个抓包时的经典困惑你会看到自己发出的包校验和是错的。别慌这是网卡和内核的校验和卸载机制在起作用抓包点位于计算之前所以抓到的是未计算状态真实包发到线上是正确的。验证办法是在接收端抓如果接收端算出来是对的就说明没问题。4. 内核参数与高并发收包4.1 缓冲区最容易成为瓶颈的地方UDP 没有流控发送方想发多快就发多快接收方处理不过来时超出缓冲区容量的包直接丢弃。这个丢弃是静默的应用层收不到任何错误只能通过内核计数器发现。先看要监控什么nstat -az | grep -i udp ss -uanm | head -20重点看几个计数器UdpRcvbufErrors表示因接收缓冲区满而丢弃的包数UdpInErrors是各类入向错误的总和UdpInCsumErrors是校验和失败UdpNoPorts是目的端口没人监听。只要UdpRcvbufErrors在涨就说明你的应用处理速度跟不上或者缓冲区太小。调参顺序我一般是这样的参数作用建议值按业务量级net.core.rmem_max单个 socket 接收缓冲区上限8MB ~ 32MBnet.core.netdev_max_backlog网卡到协议栈的队列长度5000 ~ 20000net.core.rmem_default默认接收缓冲区1MB ~ 4MBnet.ipv4.udp_memUDP 全局内存页数低/压力/高按物理内存 5%~10% 估net.ipv4.ipfrag_high_threshIP 分片重组队列上限按需调大但别指望它改完rmem_max之后应用里setsockopt设置的值才能生效否则内核会把它悄悄截断到上限你设了 32MB 实际只有 208KB然后纳闷为什么还是丢包。另一个提升收包能力的办法是批量收包。Linux 提供recvmmsg一次系统调用能取多个报文在高包量场景下能把 CPU 占用砍掉一大截。Python 没有直接暴露这个接口得用ctypes或者换成 C/Go。如果你的 QPS 到了每秒几万包的量级一次收一个包的开销就开始显著了。4.2 中间设备不待见沉默的 UDP这个坑我踩过不止一次。UDP 是无连接的中间设备为了省资源会给每个映射表项设置老化时间通常是几十秒。如果你的应用长时间不发包表项就被回收了之后对方再发过来的包找不到对应关系直接被丢。现象很有迷惑性连接看起来还在但一段时间没数据之后突然就收不到了重连一下又好了。解决办法是心跳但心跳间隔要掐准。默认老化时间如果是 30 秒那你得在 15 到 20 秒内至少发一次包。不要去猜直接问网络运维拿实际配置或者自己做实验每隔一秒发个探针看第几次开始收不到回包。心跳包还有个小技巧带上递增的序号并且要求对端回 ACK。单向发包只能保活自己这侧的表项如果对侧也要保活必须有来回。4.3 多线程与端口复用单个 UDP socket 在多核机器上会成为瓶颈因为所有包都进同一个接收队列。SO_REUSEPORT能让多个进程/线程绑定到同一端口内核按四元组做哈希分发每个 socket 有独立的队列天然并行。int one 1; setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, one, sizeof(one));要注意的是哈希分发是按四元组来的同一个客户端的所有包会固定落到同一个 socket 上所以这不会打乱单个会话的包顺序但也意味着热点客户端无法被分摊。如果你的流量集中在少数几个大客户端上SO_REUSEPORT帮助有限得改架构。还有一点SO_REUSEPORT时不要指望SO_REUSEADDR帮你解决一切。两者语义不同前者是负载均衡后者是允许绑定处于 TIME_WAIT 状态的端口混用会出问题尤其多进程启动时可能出现某个进程一个包都收不到。5. 排查实录六类高频问题5.1 问题速查表现象最可能的原因排查动作完全收不到包绑定了 127.0.0.1 / 防火墙拦截 / 端口填错ss -uan看是否监听在 0.0.0.0对端nc -u试探小包正常大包 100% 丢路径 MTU 小于包长且 DF 置位ping -M do -s 1472逐级试探业务层限长 1200偶发丢包且UdpRcvbufErrors涨接收缓冲区满调大rmem_max和SO_RCVBUF优化处理逻辑UdpInCsumErrors持续增长链路错误或中间设备篡改抓包对比检查是否有设备做内容改写空闲一段时间后断流中间设备映射表项老化加双向心跳间隔小于老化时间sendto返回ENOBUFS发送缓冲区满或本地路由不可达检查SO_SNDBUF、网卡队列、路由表5.2 几个不那么明显的细节第一个bind的地址。绑定127.0.0.1只能收本机回环的包绑定0.0.0.0才是所有网卡。这个错误太低级但我见过在容器环境里因为绑定到了容器内部 IP导致宿主机转发过来的包被丢的情况。第二个端口不可达的反馈是 ICMP。你往一个没监听的端口发 UDP对端会回一个 ICMP 端口不可达。但很多网络设备会过滤这类消息所以你看到的是发了没反应而不是连接被拒绝。这也意味着 UDP 的connect()并不会真正建立连接它只是在内核里记下对端地址方便用send()而不是sendto()。第三个recvfrom的缓冲区大小决定截断。如果传入的 bufsize 小于实际数据报长度多出来的部分会被静默丢弃返回的长度是 bufsize 而不是真实长度。你在应用层看到的就是数据被截断了但没有任何错误提示。这就是开头那个故事的另一个版本——所以缓冲区大小一定要比预期最大包长还大一点。第四个零长度 UDP 包是合法的。头部 8 字节载荷 0 字节能正常收发。有些扫描工具会用它探测端口你的代码如果假设收到包至少有几个字节容易在解析头部时崩掉。第五个并发下的乱序比想象中更常见。不只是网络路径会导致乱序多线程收包、多队列网卡、SO_REUSEPORT分发加上不同核之间的调度延迟都可能让包的处理顺序和到达顺序不一致。所以但凡业务依赖顺序序列号必须在应用层判别假设内核会按序交给你。第六个容器和虚拟化环境的 MTU 往往不是 1500。常见的是 1450 或 1400叠了隧道之后可能更低。跨环境部署时不要硬编码 1472启动时做一次探测或者直接把上限压到 1200省心。6. 我在实际项目里的一些处理习惯写得差不多了说几个不成体系但确实管用的习惯。永远在应用层给 UDP 加一个序列号和时间戳。就算业务不要求可靠加上这两个字段也几乎没有成本但出问题时能立刻判断是丢了、重了还是晚了。没有序列号的 UDP 日志基本没法分析你连到底丢了多少都说不清。别迷信UDP 一定比 TCP 快。在丢包率低的链路上两者的差距远没有想象中大尤其当你自己实现的重传逻辑不如内核精细时。我测过一些场景加了简单重传层的 UDP 在弱网下反而不如 TCP 稳定。选型时先量一量实际链路质量别凭感觉。压测要模拟真实网络条件。本机回环测出来的数据毫无参考价值因为回环几乎不丢包也不乱序。用tc netem注入延迟和丢包再去测tc qdisc add dev eth0 root netem delay 50ms loss 1% reorder 5%这行命令能让你在实验室里重现大部分线上问题调完参数记得tc qdisc del dev eth0 root清掉不然忘了这回事会把后面的测试结果全带偏。监控一定要盯内核计数器而不是只看应用日志。应用层能看到的只是我收到了什么看不到内核替我扔了什么。把UdpRcvbufErrors、UdpInErrors这两个指标接进监控设个告警阈值比出事后翻日志高效得多。最后一条如果你的可靠性需求超过了重发几次 去重这个量级认真考虑一下现成的方案。自己从零写拥塞控制、流控、多路复用投入产出比通常很差而且很容易在某些边界条件下出问题。这部分工作量远比看起来大我见过不止一个团队低估了它。