1. UDP协议栈全景：从应用层到物理层的UDP数据包旅程

各位好，我是老周。做网络协议栈优化十几年了，每次带新人，我第一件事就是让他们把UDP的完整路径走一遍。为什么？因为你不看全貌，后面调优就是瞎蒙。

今天咱们就从应用层开始，一路往下，看看一个UDP数据包到底经历了什么。嗯，说白了，就是一次从软件到硬件的完整旅行。

核心观点：UDP优化不是改一个参数就完事。你得知道数据在哪层排队、在哪层拷贝、在哪层丢包，才能对症下药。

一切从 sendto() 开始。你写了个UDP客户端，调用这个系统调用，把数据扔给内核。但这里有个坑——很多人以为数据直接就发出去了。

实际上，sendto() 只是把数据从用户空间拷贝到内核空间的套接字缓冲区。这个拷贝操作，我习惯叫它「第一次内存拷贝」。我在项目中遇到过，有人为了省事，每次发1字节数据，结果性能惨不忍睹。为什么？因为每次系统调用都有开销，拷贝也有开销。

我的建议：尽量合并小包发送。比如攒够MTU大小再发，能显著减少系统调用次数。我曾经帮一个游戏服务器团队做优化，就靠这个把CPU使用率降了30%。

数据进了内核，UDP协议栈开始干活。它会给你的数据加上一个8字节的头部。这个头部长这样：

这里有个细节——校验和。很多人觉得UDP不可靠，校验和可有可无。但我在生产环境见过，校验和错误导致的数据静默损坏，排查起来非常痛苦。所以我建议：永远开启UDP校验和。虽然多了一点CPU开销，但值得。

UDP层处理完，数据交给IP层。IP层会加上20字节的IP头部（IPv4标准头）。这里有个关键操作——分片。

如果你的UDP数据包超过MTU（通常是1500字节），IP层会把它切成多个片段。每个片段单独发送，接收端再重组。你想想看，这有多脆弱——只要丢一个片段，整个包就废了。

避坑指南：我曾经在视频流项目中踩过这个坑。UDP包设成了64KB，结果网络稍微抖动就大量丢包。后来强制限制UDP负载不超过1472字节（1500 - 20 IP头 - 8 UDP头），问题立刻解决。

IP层处理完，数据交给数据链路层。这里会加上14字节的以太网帧头（目标MAC、源MAC、类型），尾部还有4字节的FCS校验。

但真正影响性能的，是这层的排队机制。每个网卡都有一个发送队列（TX ring buffer）。如果队列满了，数据包就会被丢弃。UDP没有重传机制，丢了就是丢了。

我记得有一次排查丢包问题，用 ethtool -S eth0 一看，tx_dropped 计数器一直在涨。原因就是发送队列太小，突发流量一来就撑爆了。

最后，数据从网卡的发送队列出来，变成电信号或光信号，走上网线或光纤。这层的优化空间不大，但有个点要注意——网卡中断合并。

现代网卡支持中断合并（coalescing），也就是攒一批包再通知CPU。好处是减少CPU中断次数，坏处是增加延迟。做实时音视频的，通常要关掉这个功能。

下面这张图，把整个流程串起来了。我建议你保存下来，后面每讲一个优化点，都可以回来对照看看它落在哪一层。

我把每层的主要开销整理了一下，方便你快速定位问题：

我的调试习惯：遇到UDP性能问题，先用 perf top 看CPU花在哪层。如果大量时间在 copy_user_enhanced_fast_string，说明内存拷贝是瓶颈；如果大量时间在 ip_rcv，说明网络层处理压力大。对症下药，别盲目调参数。

好了，这一章我们走完了UDP数据包的完整旅程。从应用层的 sendto()，到物理层的比特流，每一层都有它的角色和坑。后面的章节，我们会针对每一层深入展开优化技巧。记住这个全景图，后面所有内容都会回到这张图上。