1. 为什么UDP和TCP是两种生物先撕开数据报这层皮接触Linux网络的人几乎都听过一句话TCP是流式协议UDP是数据报协议。教材上写得很轻巧但到了工程里这句话背后的差距能直接决定你的服务能不能撑住峰值。我见过不少后端同学用TCP的思维去写UDP代码结果压测一上来就各种丢包、乱序、性能腰斩最后还把锅甩给UDP不可靠。实际上UDP的面向数据报不是一种简单的风格偏好它是内核里一整套设计逻辑的出发点。你从socket接口层看下去到协议栈再到驱动每一个环节都在维护一条消息的完整性。这一点和TCP完全不同TCP的发送方只负责往内核丢字节流接收方也只负责按顺序捞字节至于一条应用消息从哪里开始、到哪里结束TCP完全不关心。1.1 从connect和sendto的差异说起先看最直观的接口层。UDP的socket可以不用connect就直接sendto这是大家都知道的事。但很多人没细想过为什么因为UDP没有连接状态内核不需要维护对端信息每次sendto的时候你把目标地址带进来内核用完即走。对应的TCP在调用send之前必须connect内核要维护一堆状态三次握手、序号窗口、拥塞控制、重传队列。这些状态的存在本质上是因为TCP承诺了不丢、不乱、不重所以要追踪每一个字节的去向。而UDP的sendto路径走到内核里做的事情极其干脆把用户缓冲区拷进一个skb设置好IP头里的源地址和目的地址然后直接扔给IP层。没有任何序号没有确认机制没有重传定时器。1.2 数据报的语义基础一次sendto就是一个完整消息所谓面向数据报含义就是应用层一次sendto投递的数据对端一次recvfrom必须完整收到。这个语义是UDP协议设计的第一原则。举个例子我sendto一个长度为2000字节的包。接收方调用recvfrom缓冲区准备的是1500字节那这2000字节会被截断剩下的直接丢弃。注意不是分两次给你而是截断丢剩余。反过来我sendto了两次第一次100字节第二次200字节。接收方如果用一个300字节的缓冲区去recvfrom它只会拿到第一次的100字节不可能把两次的数据拼成一个300字节的包返回。因为在内核里这是两个独立的skb接收路径会把每个skb单独交付一次。这个语义在传输层代码里是怎么保住的关键在于skb的独立性。TCP的数据可以被拆散、重组、甚至和上一个包合并因为TCP不管消息边界。UDP的每个数据报必须单独挂在接收队列上一个个来不允许合并。这就是为什么UDP的接收队列里每个skb就是一个完整的数据报。1.3 从面向记录与面向流的差异看协议设计取舍TCP和UDP的取舍说到底是在可靠性和简单性之间做权衡。TCP为了保证可靠付出了头部开销、状态维护、时延增加的代价。UDP放弃了可靠性换来了极低的协议开销和处理延迟。但有一个关键点经常被忽略UDP不是不可靠的协议而是不承诺可靠的协议。它仍然提供校验和能检测出数据损坏它仍然提供端口复用能正确地分发到对应进程。只是它不试图修复丢失和错乱。这就像寄平信和寄挂号信的区别。平信没有回执但邮局还是会尽力送到油墨会盖邮戳地址不对也会退件。UDP的校验和就是那枚邮戳它不保证你一定收到但能告诉收件人这封信在途中没破相。所以当你设计UDP应用时不要在可靠性上抱怨协议而是应该在应用层自己补上确认重传的逻辑。很多游戏服务器、实时音视频系统都是这样做的UDP负责快速传输原始数据应用层自行维护关键数据的可靠性。2. 发送缓冲区UDP其实只有扣留区没有堆积仓库很多从TCP转过来的同学第一反应是问UDP的发送缓冲区多大要不要调TCP遇到发送缓冲区满会阻塞UDP会怎样答案可能让人意外在Linux里UDP的发送路径基本不依赖发送缓冲区。它更像是过路中转站数据包进来立刻被装配成skb随即交给IP层和网卡。如果你硬要查发送队列的占用长度你会看到它长期是0或者极短。2.1 走进内核从sendto到ip_append_data的路径我用源码视角大概描述一下sendto的路径。应用层调用sendto后最终会落到内核的sock_sendmsg在UDP场景下进入udp_sendmsg()。在udp_sendmsg()里有几个关键判断如果socket没有connect过且此次sendto带了显式地址就用这个地址作为目的地址如果socket之前connect过则每次sendto必须不带地址否则报错EISCONN相关逻辑然后调用ip_append_data()准备skb和IP头。ip_append_data()会判断当前发送队列长度和阈值。对于UDP大包如果超过MTU就需要分片。注意这里的发送队列长度指的是skb占用的字节数由sk_wmem_alloc跟踪。关键来了UDP没有像TCP那样的重传机制也不需要积压大量待发送数据。TCP的发送缓冲区是为了在未确认之前保存数据的副本以便超时重传UDP根本不做重传所以数据发了就发了内核不需要保存副本。这就是为什么UDP的发送缓冲区远小于TCP——因为压根不需要那么大。2.2 skb的一次性如何保证数据报边界skb是Linux内核网络栈里最核心的数据结构你可以把它想成一个数据信封里面装的是实际载荷外层还有一系列元信息协议头、长度、时间戳等。在UDP发送路径里每个sendto调用都会生成一个独立的skb。如果数据大于MTUIP层会把它拆成多个分片但每个分片仍然属于同一个skb队列接收方重组完再交给上层UDP。关键设计在这里每个skb携带完整的UDP头头里的长度字段标明整个数据报的大小。接收方不需要猜测消息边界直接看UDP头里的长度就够了。这就意味着数据报边界不是约定俗成而是被协议头里的字段强制的。TCP没有这个字段它是纯字节流所以只能靠应用层自定义消息格式。2.3 所谓UDP发送缓冲区和真正瓶颈是什么UDP发送缓冲区虽然存在但它的作用更像是保护系统内存不被无限消耗。默认的wmem_default一般是几十KB到几百KB如果你一次性sendto一个超大缓冲区比如几MB内核会判断是否超过sk_sndbuf上限如果超过sendto会返回EAGAIN。但真正限制UDP吞吐的往往不是发送缓冲区而是这几个因素数据从用户态拷贝到内核态的耗时一次大包拷贝比多次小包更划算IP分片带来的重组负担网卡的发送队列/中断处理能力。以我的实测经验在万兆网卡上用UDP发小包时能达到的PPS每秒包数远高于发大包时的吞吐量。因为小包的主要瓶颈是系统调用次数和中断次数大包的主要瓶颈是内存拷贝和分片重组。2.4 实测为什么UDP发大包和发小包差别巨大我曾经做过一个简单的压测客户端用UDP发送一个socket服务端只有一个recvfrom循环不做任何处理。发送缓冲区设为64KB第一种场景每次sendto 4字节连续发送100万次第二种场景每次sendto 1400字节连续发送100万次。结果非常典型小包场景下CPU几乎全部消耗在系统调用和锁竞争上吞吐量上不去大包场景下虽然单次拷入内耗更大但总吞吐高出好几倍。原因很简单每一次sendto都是一次系统调用syscall的固定开销不会因为包小而减少。理论上最好的方案是把多个小消息拼成一个UDP数据报发送减少syscall次数但这又会牺牲每条消息独立的语义。这个取舍没有标准答案完全取决于你的业务需不需要单条消息的天然边界。3. 接收缓冲区真实占比极小一旦满就丢UDP的接收侧和发送侧不对称这也是很多工程师容易踩坑的地方。发送侧不保留副本所以发送缓冲区可以小接收侧必须在消息到达后把数据先存下来等待应用层读取所以接收缓冲区必须存在而且满了之后会直接丢包。3.1 udp_queue_rcv_skb与sk_receive_queue当网络包经过网卡、IP层、路由判断最终进入UDP协议栈时会调用udp_queue_rcv_skb()。这个函数做的事情简单来说校验UDP头和校验和检查目标端口是否有人监听检查接收队列是否有空间有空间就把skb挂到接收队列上唤醒阻塞的recvfrom没空间就丢包并更新统计计数。这里的空间是由sk_rmem_alloc衡量的它表示接收队列当前累计占用的内存。内核规定了一个上限默认是net.core.rmem_max可调而UDP socket的sk_rcvbuf默认值往往只有数百KB。注意UDP接收缓冲区的大小通常远小于TCP因为UDP不需要为无序数据提供乱序重排缓存。TCP的接收窗口可能很大以支持窗口缩放和突发流量UDP只能硬扛满了就丢。3.2 阈值逻辑为什么收发不平衡时接收端先死如果你在压测时发现服务端处理不过来然后客户端也不行了很可能就是接收缓冲区满了。看一个具体场景我用一个UDP客户端以最大速率发包服务端每个包只做简单的解析然后丢进队列后由另一个线程处理。处理线程跟不上接收线程仍然在疯狂recvfrom这时候会发生什么接收线程每次recvfrom取走队列头部的一个skb处理队列堆积接收线程来不及处理内核的接收队列里skb越来越多sk_rmem_alloc不断上涨一旦超过sk_rcvbufudp_queue_rcv_skb直接丢弃新到的skb。结果就是应用层根本看不到这些被丢弃包你只有在netstat或者/proc/net/snmp里看到UDP的RcvbufErrors计数在涨。这个现象告诉我们UDP接收端的瓶颈几乎总是在应用层的处理速度。内核已经尽力缓存但缓存有限。要做高吞吐UDP必须保证接收线程的处理速度足够快或者直接用多线程/多队列方案让每个socket或者每个队列都有独立的接收路径。3.3 内核统计UDP丢包计数怎么查想要判断UDP到底丢了多少包不要靠猜直接看内核统计。cat /proc/net/snmp | grep Udp:输出的字段里有几个特别重要的InDatagrams接收到的UDP数据报总数InErrors接收时出错的数量比如校验和错误、长度错误RcvbufErrors因为接收缓冲区满被丢弃的包数SndbufErrors因为发送缓冲区满导致send失败或包被丢弃的次数。如果你看到RcvbufErrors一直增加说明应用层的接收速度顶不住了赶紧优化用户态代码而不是盲目调大内核缓冲区。虽然调大net.core.rmem_max和socket的SO_RCVBUF能暂时缓解但治标不治本。本质上数据到达速率大于应用消费速率缓冲区再大也只是延迟了丢包时间点。3.4 背压之外IP分片与重组对缓冲区的影响还有一个被忽略的问题IP分片。当一个UDP数据报大于MTU典型1500字节时IP层会拆成多个分片接收方必须等所有分片到齐后重组再交给UDP层。问题在于分片是独立传输的任何一片丢失整个数据报就废了而且重组时有超时机制超时未到的分片会触发重组失败内核丢弃整个数据报。更麻烦的是分片重组需要额外的内存缓冲区这部分在Linux里有一个独立的限值叫net.ipv4.ipfrag_high_thresh。如果系统里有大量分片包且重组速度跟不上就会触发ipfrag内存压力导致分片被直接丢弃。工程上对UDP报文建议尽量控制在MTU以内要么用UDP应用层分帧要么用GSO/GRO让网卡帮忙处理大包别让IP层来做分片。IP分片不仅效率低、浪费带宽还会让丢包率成倍增加。4. 粘包在UDP里到底存不存在报文边界与截断问题粘包这个词通常出现在TCP新手教程里。TCP是字节流两次send的数据可能在下一次recv时一起出现需要应用层自己切分。UDP则不存在这个问题每个recvfrom返回一个完整的数据报。但我发现很多人在实际写UDP代码时还是会犯粘包思维的错误——他们总担心收到的数据不是一个完整逻辑消息于是额外做一层解析反而把事情搞复杂。4.1 为什么TCP需要粘包处理而UDP不需要TCP的粘包根源在于TCP不维护消息边界。应用层send的字节到了内核会按照MSS、拥塞窗口等参数被拆成段接收方再按照自己的节奏把字节交给应用层。两次send可能合并成一次recv返回也可能一次send被半个recv取走。UDP没有这个问题。每个数据报在发送端就是一个独立的单元接收端每次recvfrom只会返回一个数据报。这个边界由UDP头里的长度字段保证内核在接收路径上根本不会合并两个skb。如果你在写UDP消费端时准备一个大缓冲区然后用加上收到的字节数来拼接消息基本就是多此一举。一个recvfrom返回的长度就是当前数据报的完整长度不需要你再去看什么\r\n分隔符。4.2 recvfrom(recv)的最长行为与MSG_TRUNC这里有一个容易踩的坑如果我调recvfrom时缓冲区小于数据报的真实长度会发生什么答案是数据报被截断多余部分直接被内核丢弃而且不会通知你有截断。有些人的代码里缓冲区只准备了1480字节但发来的数据报是3000字节他们发现收到的数据总是不完整。正确的做法是在recvfrom时传入MSG_TRUNC标志Linux特有并在调用后检查返回值。如果设置了MSG_TRUNCrecvfrom的返回值是数据报的真实长度即使你的缓冲区不够大。没设置MSG_TRUNC时返回值是实际拷贝到缓冲区的字节数。通过对比返回值和你传入的缓冲区长度就能判断是否有截断。提示在Linux上写UDP接收代码建议缓冲区至少分配65536字节这样能接住最大65535字节的数据报UDP头的长度字段是16位的算上头部最大载荷是65507字节。4.3 16位长度字段与65507的由来UDP头里有个16位的长度字段最大表示65535。这个长度包括8字节的UDP头和载荷因此最大载荷是65535-865527字节。但还要减去20字节的IP头才能放进IPv4的65535长度限制里所以对IPv4来说UDP最大载荷是65507字节。如果发送端尝试sendto一个超过65507字节的缓冲区Linux会返回EMSGSIZE错误——在内核里这个检查在udp_sendmsg()里就会触发不会等到IP层。顺便提一句UDP数据报长度的上限是协议本身决定的不是socket缓冲区决定的。所以即使你把socket接收缓冲区调到2GB单个数据报也不可能超过65507字节。这个限制意味着一个UDP数据报在单次传输里可以承载的数据量很小。想在UDP上传输大文件或大消息必须自己做拆分和重组而且要在应用层处理丢片重传。4.4 UDPL4校验和的弱校验问题与零拷贝情况说明UDP的校验和是16位覆盖IP头里的伪首部源IP、目的IP、协议号、UDP长度以及UDP头和载荷。但IPv4下UDP头里的校验和可以设置为0表示不校验虽然大多数实现会默认校验但你在某些嵌入式或者跨网络场景下可能会碰到校验和设为0的包。更值得关注的是UDP校验和的强度。16位校验和本质上是对数据做简单的二进制补码和检出连续多位错误的概率不算高。对可靠性要求高的业务应用层应该再加一层CRC或消息认证码。零拷贝的话题这里顺带提一下。Linux下UDP收发可以通过PACKET_MMAP、AF_XDP等机制实现零拷贝但常规的socket API无法避免用户态和内核态之间的数据拷贝。接收路径上数据从网卡DMA进内存再从内核skb拷到用户缓冲区全程至少一次拷贝。这也是高吞吐UDP场景中CPU占用高的重要原因之一。5. 从源码再到应用层那些被误解的UDP特性前几节我们把UDP的内核路径和数据报语义都过了一遍这一节聊聊工程上最常见的几个误解这些误解几乎每天都能在技术社区和线上事故分析里看到。5.1 对方不回应UDP不会有任何错误提示这是我见过最多的一个坑客户端用UDP发了一个包到服务器对方服务没起来这个包会怎样答案是不会被通知。在IPv4下如果目标端口没有进程监听对方主机会回一个ICMP Port Unreachable。这个ICMP到达你的机器后Linux会查找对应的UDP socket然后把这个错误信号挂到这个socket上。但问题来了如果你的程序一直不去recv或者send这个socket这个错误永远不会被主动告知。也就是说UDP的错误提示是异步的、被动的、且可能丢失的。如果你指望UDP像TCP的RST一样立刻让send返回错误那会大失所望。处理方式是应用层自己维护超时机制。发完包后如果一定时间内没收到对端的应用层ACK就判定为失联该重发就重发该换路就换路。另外ICMP错误在Linux下很多情况下会被/proc/sys/net/ipv4/icmp_ratelimit限制频繁触发时可能被抑制所以更不能指望它。5.2 有连接UDP的设计初衷connect只是本地白名单我在不少代码里见过用UDP的人都坚持不调connect理由是UDP是无连接的connect会破坏语义。这个理解其实不准确。对UDP调用connect并不会真的建立连接不会向对端发任何包。它只是在本地为socket指定一个默认目的地址内核后续send时可以直接用这个地址不用每次再传入。connect后的UDP有几个实际好处send时可以直接调send/sendmsg不用带地址参数减少了一次地址拷贝和参数校验内核只接收来自这个对端的包其他来源的包会被丢弃相当于一个内核态白名单某些场景下可以获得异步错误通知ICMP错误更有机会传递到应用层。但要注意connect后的UDP不能再用sendto指定其他地址必须用connect重新指定。在需要固定对端的高频通信场景比如游戏服务器和客户端之间、DNS客户端请求固定服务器我都推荐调用connect性能上会有可感知的提升。5.3 UDP的时延优势为什么在Nagle之外还有更多原因TCP的时延高很多人第一反应是Nagle算法关掉TCP_NODELAY就行了。但Nagle只是原因之一。TCP还有确认机制、慢启动、拥塞窗口的逐步扩大这些都会拖慢前几个包的发送。UDP压根没有这些机制它是即发即走的。如果你对时延极度敏感实时对战、VoIP、直播推流UDP天然比TCP更合适因为在协议层它不需要任何握手和窗口管理。但时延低不等于体验好。UDP丢包后不会重传如果网络本身有丢包率你可能需要应用层重传最关键的包。这里要掌握的平衡是哪些数据走UDP、哪些数据走TCP或者同一个UDP流里区分可靠通道和不可靠通道。5.4 应用层补救手段的取舍总结根据我做过几个UDP项目的实际经验给大家一个应用层的补救菜单关键小数据登录、支付、重要状态应用层ACK超时重传海量实时数据音视频帧、位置上报允许丢旧帧不重传但带上序号接收方做乱序丢弃和去重大文件可靠传输在UDP之上做分片、序列号、滑动窗口、ACK和重传——这基本是重造TCP除非有特殊需求否则建议直接用TCP或者QUIC需要权衡吞吐和时延时可以尝试自行调节发送节奏避免突发风暴减少接收端缓冲区溢出。提到QUIC它本质上就是UDP之上实现了可靠传输和拥塞控制同时保留UDP的灵活性和头部开销。如果你的服务既要低时延又要可靠传输QUIC已经帮我们把重传和乱序问题解决好了没必要再造轮子。6. 实战中的一点体会写UDP代码我的经验总结起来就是三不不指望内核帮你维护状态不指望丢包能被协议层发现不指望接收队列是无穷无尽的。最开始做UDP服务时我也犯过错把接收缓冲区调得巨大以为就永远不会丢包了。结果压测一上RcvbufErrors照样疯涨。后来才明白UDP的根本矛盾在于应用层的消费速度和数据到达速度之间的差距缓冲区只是把矛盾往后推了一点点。真正解决问题的方式永远是让应用层的接收和处理更高效减少每个包的解析开销用多线程分担负载或者用内核旁路如AF_XDP把数据直接交给用户态处理。此外网络观测的习惯要建立起来。收到任何异常现象第一时间去看/proc/net/snmp里的UDP统计再去看网卡统计最后才猜测应用层问题。排查顺序一旦搞反很容易被表象带偏。最后说一个很多人没注意到的细节UDP的校验和可以在socket选项里关闭SO_NO_CHECK虽然不推荐但在某些数据完整性要求不高的场景下能省一点CPU。如果要做这个优化建议只在单跳可信网络里用并且要在架构上接受数据可能损坏的风险。写这篇文章的时候我脑子里全是这些年踩着各种坑慢慢梳理出来的经验。UDP的源码并不复杂复杂的是你要理解它为什么这样设计以及在这些设计约束下怎么写出能抗住压力的应用。希望这篇内容能帮你少走一些弯路。
1. 为什么UDP和TCP是两种生物先撕开数据报这层皮接触Linux网络的人几乎都听过一句话TCP是流式协议UDP是数据报协议。教材上写得很轻巧但到了工程里这句话背后的差距能直接决定你的服务能不能撑住峰值。我见过不少后端同学用TCP的思维去写UDP代码结果压测一上来就各种丢包、乱序、性能腰斩最后还把锅甩给UDP不可靠。实际上UDP的面向数据报不是一种简单的风格偏好它是内核里一整套设计逻辑的出发点。你从socket接口层看下去到协议栈再到驱动每一个环节都在维护一条消息的完整性。这一点和TCP完全不同TCP的发送方只负责往内核丢字节流接收方也只负责按顺序捞字节至于一条应用消息从哪里开始、到哪里结束TCP完全不关心。1.1 从connect和sendto的差异说起先看最直观的接口层。UDP的socket可以不用connect就直接sendto这是大家都知道的事。但很多人没细想过为什么因为UDP没有连接状态内核不需要维护对端信息每次sendto的时候你把目标地址带进来内核用完即走。对应的TCP在调用send之前必须connect内核要维护一堆状态三次握手、序号窗口、拥塞控制、重传队列。这些状态的存在本质上是因为TCP承诺了不丢、不乱、不重所以要追踪每一个字节的去向。而UDP的sendto路径走到内核里做的事情极其干脆把用户缓冲区拷进一个skb设置好IP头里的源地址和目的地址然后直接扔给IP层。没有任何序号没有确认机制没有重传定时器。1.2 数据报的语义基础一次sendto就是一个完整消息所谓面向数据报含义就是应用层一次sendto投递的数据对端一次recvfrom必须完整收到。这个语义是UDP协议设计的第一原则。举个例子我sendto一个长度为2000字节的包。接收方调用recvfrom缓冲区准备的是1500字节那这2000字节会被截断剩下的直接丢弃。注意不是分两次给你而是截断丢剩余。反过来我sendto了两次第一次100字节第二次200字节。接收方如果用一个300字节的缓冲区去recvfrom它只会拿到第一次的100字节不可能把两次的数据拼成一个300字节的包返回。因为在内核里这是两个独立的skb接收路径会把每个skb单独交付一次。这个语义在传输层代码里是怎么保住的关键在于skb的独立性。TCP的数据可以被拆散、重组、甚至和上一个包合并因为TCP不管消息边界。UDP的每个数据报必须单独挂在接收队列上一个个来不允许合并。这就是为什么UDP的接收队列里每个skb就是一个完整的数据报。1.3 从面向记录与面向流的差异看协议设计取舍TCP和UDP的取舍说到底是在可靠性和简单性之间做权衡。TCP为了保证可靠付出了头部开销、状态维护、时延增加的代价。UDP放弃了可靠性换来了极低的协议开销和处理延迟。但有一个关键点经常被忽略UDP不是不可靠的协议而是不承诺可靠的协议。它仍然提供校验和能检测出数据损坏它仍然提供端口复用能正确地分发到对应进程。只是它不试图修复丢失和错乱。这就像寄平信和寄挂号信的区别。平信没有回执但邮局还是会尽力送到油墨会盖邮戳地址不对也会退件。UDP的校验和就是那枚邮戳它不保证你一定收到但能告诉收件人这封信在途中没破相。所以当你设计UDP应用时不要在可靠性上抱怨协议而是应该在应用层自己补上确认重传的逻辑。很多游戏服务器、实时音视频系统都是这样做的UDP负责快速传输原始数据应用层自行维护关键数据的可靠性。2. 发送缓冲区UDP其实只有扣留区没有堆积仓库很多从TCP转过来的同学第一反应是问UDP的发送缓冲区多大要不要调TCP遇到发送缓冲区满会阻塞UDP会怎样答案可能让人意外在Linux里UDP的发送路径基本不依赖发送缓冲区。它更像是过路中转站数据包进来立刻被装配成skb随即交给IP层和网卡。如果你硬要查发送队列的占用长度你会看到它长期是0或者极短。2.1 走进内核从sendto到ip_append_data的路径我用源码视角大概描述一下sendto的路径。应用层调用sendto后最终会落到内核的sock_sendmsg在UDP场景下进入udp_sendmsg()。在udp_sendmsg()里有几个关键判断如果socket没有connect过且此次sendto带了显式地址就用这个地址作为目的地址如果socket之前connect过则每次sendto必须不带地址否则报错EISCONN相关逻辑然后调用ip_append_data()准备skb和IP头。ip_append_data()会判断当前发送队列长度和阈值。对于UDP大包如果超过MTU就需要分片。注意这里的发送队列长度指的是skb占用的字节数由sk_wmem_alloc跟踪。关键来了UDP没有像TCP那样的重传机制也不需要积压大量待发送数据。TCP的发送缓冲区是为了在未确认之前保存数据的副本以便超时重传UDP根本不做重传所以数据发了就发了内核不需要保存副本。这就是为什么UDP的发送缓冲区远小于TCP——因为压根不需要那么大。2.2 skb的一次性如何保证数据报边界skb是Linux内核网络栈里最核心的数据结构你可以把它想成一个数据信封里面装的是实际载荷外层还有一系列元信息协议头、长度、时间戳等。在UDP发送路径里每个sendto调用都会生成一个独立的skb。如果数据大于MTUIP层会把它拆成多个分片但每个分片仍然属于同一个skb队列接收方重组完再交给上层UDP。关键设计在这里每个skb携带完整的UDP头头里的长度字段标明整个数据报的大小。接收方不需要猜测消息边界直接看UDP头里的长度就够了。这就意味着数据报边界不是约定俗成而是被协议头里的字段强制的。TCP没有这个字段它是纯字节流所以只能靠应用层自定义消息格式。2.3 所谓UDP发送缓冲区和真正瓶颈是什么UDP发送缓冲区虽然存在但它的作用更像是保护系统内存不被无限消耗。默认的wmem_default一般是几十KB到几百KB如果你一次性sendto一个超大缓冲区比如几MB内核会判断是否超过sk_sndbuf上限如果超过sendto会返回EAGAIN。但真正限制UDP吞吐的往往不是发送缓冲区而是这几个因素数据从用户态拷贝到内核态的耗时一次大包拷贝比多次小包更划算IP分片带来的重组负担网卡的发送队列/中断处理能力。以我的实测经验在万兆网卡上用UDP发小包时能达到的PPS每秒包数远高于发大包时的吞吐量。因为小包的主要瓶颈是系统调用次数和中断次数大包的主要瓶颈是内存拷贝和分片重组。2.4 实测为什么UDP发大包和发小包差别巨大我曾经做过一个简单的压测客户端用UDP发送一个socket服务端只有一个recvfrom循环不做任何处理。发送缓冲区设为64KB第一种场景每次sendto 4字节连续发送100万次第二种场景每次sendto 1400字节连续发送100万次。结果非常典型小包场景下CPU几乎全部消耗在系统调用和锁竞争上吞吐量上不去大包场景下虽然单次拷入内耗更大但总吞吐高出好几倍。原因很简单每一次sendto都是一次系统调用syscall的固定开销不会因为包小而减少。理论上最好的方案是把多个小消息拼成一个UDP数据报发送减少syscall次数但这又会牺牲每条消息独立的语义。这个取舍没有标准答案完全取决于你的业务需不需要单条消息的天然边界。3. 接收缓冲区真实占比极小一旦满就丢UDP的接收侧和发送侧不对称这也是很多工程师容易踩坑的地方。发送侧不保留副本所以发送缓冲区可以小接收侧必须在消息到达后把数据先存下来等待应用层读取所以接收缓冲区必须存在而且满了之后会直接丢包。3.1 udp_queue_rcv_skb与sk_receive_queue当网络包经过网卡、IP层、路由判断最终进入UDP协议栈时会调用udp_queue_rcv_skb()。这个函数做的事情简单来说校验UDP头和校验和检查目标端口是否有人监听检查接收队列是否有空间有空间就把skb挂到接收队列上唤醒阻塞的recvfrom没空间就丢包并更新统计计数。这里的空间是由sk_rmem_alloc衡量的它表示接收队列当前累计占用的内存。内核规定了一个上限默认是net.core.rmem_max可调而UDP socket的sk_rcvbuf默认值往往只有数百KB。注意UDP接收缓冲区的大小通常远小于TCP因为UDP不需要为无序数据提供乱序重排缓存。TCP的接收窗口可能很大以支持窗口缩放和突发流量UDP只能硬扛满了就丢。3.2 阈值逻辑为什么收发不平衡时接收端先死如果你在压测时发现服务端处理不过来然后客户端也不行了很可能就是接收缓冲区满了。看一个具体场景我用一个UDP客户端以最大速率发包服务端每个包只做简单的解析然后丢进队列后由另一个线程处理。处理线程跟不上接收线程仍然在疯狂recvfrom这时候会发生什么接收线程每次recvfrom取走队列头部的一个skb处理队列堆积接收线程来不及处理内核的接收队列里skb越来越多sk_rmem_alloc不断上涨一旦超过sk_rcvbufudp_queue_rcv_skb直接丢弃新到的skb。结果就是应用层根本看不到这些被丢弃包你只有在netstat或者/proc/net/snmp里看到UDP的RcvbufErrors计数在涨。这个现象告诉我们UDP接收端的瓶颈几乎总是在应用层的处理速度。内核已经尽力缓存但缓存有限。要做高吞吐UDP必须保证接收线程的处理速度足够快或者直接用多线程/多队列方案让每个socket或者每个队列都有独立的接收路径。3.3 内核统计UDP丢包计数怎么查想要判断UDP到底丢了多少包不要靠猜直接看内核统计。cat /proc/net/snmp | grep Udp:输出的字段里有几个特别重要的InDatagrams接收到的UDP数据报总数InErrors接收时出错的数量比如校验和错误、长度错误RcvbufErrors因为接收缓冲区满被丢弃的包数SndbufErrors因为发送缓冲区满导致send失败或包被丢弃的次数。如果你看到RcvbufErrors一直增加说明应用层的接收速度顶不住了赶紧优化用户态代码而不是盲目调大内核缓冲区。虽然调大net.core.rmem_max和socket的SO_RCVBUF能暂时缓解但治标不治本。本质上数据到达速率大于应用消费速率缓冲区再大也只是延迟了丢包时间点。3.4 背压之外IP分片与重组对缓冲区的影响还有一个被忽略的问题IP分片。当一个UDP数据报大于MTU典型1500字节时IP层会拆成多个分片接收方必须等所有分片到齐后重组再交给UDP层。问题在于分片是独立传输的任何一片丢失整个数据报就废了而且重组时有超时机制超时未到的分片会触发重组失败内核丢弃整个数据报。更麻烦的是分片重组需要额外的内存缓冲区这部分在Linux里有一个独立的限值叫net.ipv4.ipfrag_high_thresh。如果系统里有大量分片包且重组速度跟不上就会触发ipfrag内存压力导致分片被直接丢弃。工程上对UDP报文建议尽量控制在MTU以内要么用UDP应用层分帧要么用GSO/GRO让网卡帮忙处理大包别让IP层来做分片。IP分片不仅效率低、浪费带宽还会让丢包率成倍增加。4. 粘包在UDP里到底存不存在报文边界与截断问题粘包这个词通常出现在TCP新手教程里。TCP是字节流两次send的数据可能在下一次recv时一起出现需要应用层自己切分。UDP则不存在这个问题每个recvfrom返回一个完整的数据报。但我发现很多人在实际写UDP代码时还是会犯粘包思维的错误——他们总担心收到的数据不是一个完整逻辑消息于是额外做一层解析反而把事情搞复杂。4.1 为什么TCP需要粘包处理而UDP不需要TCP的粘包根源在于TCP不维护消息边界。应用层send的字节到了内核会按照MSS、拥塞窗口等参数被拆成段接收方再按照自己的节奏把字节交给应用层。两次send可能合并成一次recv返回也可能一次send被半个recv取走。UDP没有这个问题。每个数据报在发送端就是一个独立的单元接收端每次recvfrom只会返回一个数据报。这个边界由UDP头里的长度字段保证内核在接收路径上根本不会合并两个skb。如果你在写UDP消费端时准备一个大缓冲区然后用加上收到的字节数来拼接消息基本就是多此一举。一个recvfrom返回的长度就是当前数据报的完整长度不需要你再去看什么\r\n分隔符。4.2 recvfrom(recv)的最长行为与MSG_TRUNC这里有一个容易踩的坑如果我调recvfrom时缓冲区小于数据报的真实长度会发生什么答案是数据报被截断多余部分直接被内核丢弃而且不会通知你有截断。有些人的代码里缓冲区只准备了1480字节但发来的数据报是3000字节他们发现收到的数据总是不完整。正确的做法是在recvfrom时传入MSG_TRUNC标志Linux特有并在调用后检查返回值。如果设置了MSG_TRUNCrecvfrom的返回值是数据报的真实长度即使你的缓冲区不够大。没设置MSG_TRUNC时返回值是实际拷贝到缓冲区的字节数。通过对比返回值和你传入的缓冲区长度就能判断是否有截断。提示在Linux上写UDP接收代码建议缓冲区至少分配65536字节这样能接住最大65535字节的数据报UDP头的长度字段是16位的算上头部最大载荷是65507字节。4.3 16位长度字段与65507的由来UDP头里有个16位的长度字段最大表示65535。这个长度包括8字节的UDP头和载荷因此最大载荷是65535-865527字节。但还要减去20字节的IP头才能放进IPv4的65535长度限制里所以对IPv4来说UDP最大载荷是65507字节。如果发送端尝试sendto一个超过65507字节的缓冲区Linux会返回EMSGSIZE错误——在内核里这个检查在udp_sendmsg()里就会触发不会等到IP层。顺便提一句UDP数据报长度的上限是协议本身决定的不是socket缓冲区决定的。所以即使你把socket接收缓冲区调到2GB单个数据报也不可能超过65507字节。这个限制意味着一个UDP数据报在单次传输里可以承载的数据量很小。想在UDP上传输大文件或大消息必须自己做拆分和重组而且要在应用层处理丢片重传。4.4 UDPL4校验和的弱校验问题与零拷贝情况说明UDP的校验和是16位覆盖IP头里的伪首部源IP、目的IP、协议号、UDP长度以及UDP头和载荷。但IPv4下UDP头里的校验和可以设置为0表示不校验虽然大多数实现会默认校验但你在某些嵌入式或者跨网络场景下可能会碰到校验和设为0的包。更值得关注的是UDP校验和的强度。16位校验和本质上是对数据做简单的二进制补码和检出连续多位错误的概率不算高。对可靠性要求高的业务应用层应该再加一层CRC或消息认证码。零拷贝的话题这里顺带提一下。Linux下UDP收发可以通过PACKET_MMAP、AF_XDP等机制实现零拷贝但常规的socket API无法避免用户态和内核态之间的数据拷贝。接收路径上数据从网卡DMA进内存再从内核skb拷到用户缓冲区全程至少一次拷贝。这也是高吞吐UDP场景中CPU占用高的重要原因之一。5. 从源码再到应用层那些被误解的UDP特性前几节我们把UDP的内核路径和数据报语义都过了一遍这一节聊聊工程上最常见的几个误解这些误解几乎每天都能在技术社区和线上事故分析里看到。5.1 对方不回应UDP不会有任何错误提示这是我见过最多的一个坑客户端用UDP发了一个包到服务器对方服务没起来这个包会怎样答案是不会被通知。在IPv4下如果目标端口没有进程监听对方主机会回一个ICMP Port Unreachable。这个ICMP到达你的机器后Linux会查找对应的UDP socket然后把这个错误信号挂到这个socket上。但问题来了如果你的程序一直不去recv或者send这个socket这个错误永远不会被主动告知。也就是说UDP的错误提示是异步的、被动的、且可能丢失的。如果你指望UDP像TCP的RST一样立刻让send返回错误那会大失所望。处理方式是应用层自己维护超时机制。发完包后如果一定时间内没收到对端的应用层ACK就判定为失联该重发就重发该换路就换路。另外ICMP错误在Linux下很多情况下会被/proc/sys/net/ipv4/icmp_ratelimit限制频繁触发时可能被抑制所以更不能指望它。5.2 有连接UDP的设计初衷connect只是本地白名单我在不少代码里见过用UDP的人都坚持不调connect理由是UDP是无连接的connect会破坏语义。这个理解其实不准确。对UDP调用connect并不会真的建立连接不会向对端发任何包。它只是在本地为socket指定一个默认目的地址内核后续send时可以直接用这个地址不用每次再传入。connect后的UDP有几个实际好处send时可以直接调send/sendmsg不用带地址参数减少了一次地址拷贝和参数校验内核只接收来自这个对端的包其他来源的包会被丢弃相当于一个内核态白名单某些场景下可以获得异步错误通知ICMP错误更有机会传递到应用层。但要注意connect后的UDP不能再用sendto指定其他地址必须用connect重新指定。在需要固定对端的高频通信场景比如游戏服务器和客户端之间、DNS客户端请求固定服务器我都推荐调用connect性能上会有可感知的提升。5.3 UDP的时延优势为什么在Nagle之外还有更多原因TCP的时延高很多人第一反应是Nagle算法关掉TCP_NODELAY就行了。但Nagle只是原因之一。TCP还有确认机制、慢启动、拥塞窗口的逐步扩大这些都会拖慢前几个包的发送。UDP压根没有这些机制它是即发即走的。如果你对时延极度敏感实时对战、VoIP、直播推流UDP天然比TCP更合适因为在协议层它不需要任何握手和窗口管理。但时延低不等于体验好。UDP丢包后不会重传如果网络本身有丢包率你可能需要应用层重传最关键的包。这里要掌握的平衡是哪些数据走UDP、哪些数据走TCP或者同一个UDP流里区分可靠通道和不可靠通道。5.4 应用层补救手段的取舍总结根据我做过几个UDP项目的实际经验给大家一个应用层的补救菜单关键小数据登录、支付、重要状态应用层ACK超时重传海量实时数据音视频帧、位置上报允许丢旧帧不重传但带上序号接收方做乱序丢弃和去重大文件可靠传输在UDP之上做分片、序列号、滑动窗口、ACK和重传——这基本是重造TCP除非有特殊需求否则建议直接用TCP或者QUIC需要权衡吞吐和时延时可以尝试自行调节发送节奏避免突发风暴减少接收端缓冲区溢出。提到QUIC它本质上就是UDP之上实现了可靠传输和拥塞控制同时保留UDP的灵活性和头部开销。如果你的服务既要低时延又要可靠传输QUIC已经帮我们把重传和乱序问题解决好了没必要再造轮子。6. 实战中的一点体会写UDP代码我的经验总结起来就是三不不指望内核帮你维护状态不指望丢包能被协议层发现不指望接收队列是无穷无尽的。最开始做UDP服务时我也犯过错把接收缓冲区调得巨大以为就永远不会丢包了。结果压测一上RcvbufErrors照样疯涨。后来才明白UDP的根本矛盾在于应用层的消费速度和数据到达速度之间的差距缓冲区只是把矛盾往后推了一点点。真正解决问题的方式永远是让应用层的接收和处理更高效减少每个包的解析开销用多线程分担负载或者用内核旁路如AF_XDP把数据直接交给用户态处理。此外网络观测的习惯要建立起来。收到任何异常现象第一时间去看/proc/net/snmp里的UDP统计再去看网卡统计最后才猜测应用层问题。排查顺序一旦搞反很容易被表象带偏。最后说一个很多人没注意到的细节UDP的校验和可以在socket选项里关闭SO_NO_CHECK虽然不推荐但在某些数据完整性要求不高的场景下能省一点CPU。如果要做这个优化建议只在单跳可信网络里用并且要在架构上接受数据可能损坏的风险。写这篇文章的时候我脑子里全是这些年踩着各种坑慢慢梳理出来的经验。UDP的源码并不复杂复杂的是你要理解它为什么这样设计以及在这些设计约束下怎么写出能抗住压力的应用。希望这篇内容能帮你少走一些弯路。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
