3、网络带宽与UDP吞吐量：理论带宽计算、实际吞吐量影响因素、链路层开销对UDP的影响
聊UDP性能，绕不开带宽和吞吐量这两个词。
很多人以为，带宽是1Gbps，UDP就能跑满1Gbps。我刚开始做网络开发时也这么想，结果被现实狠狠教育了一顿。说白了，理论带宽和实际吞吐量之间，隔着一整条链路层的开销鸿沟。
这一节，我们就来拆解这个鸿沟。
3.1 理论带宽计算：理想情况下的天花板
理论带宽，就是物理层能提供的最大传输速率。比如千兆以太网，理论带宽就是1,000,000,000 bits/s（注意是小写b，代表比特）。
UDP的理论吞吐量上限，可以用一个简单公式估算：
UDP理论吞吐量 = 链路带宽 × (UDP有效载荷 / (以太网帧总长))
其中，以太网帧总长 = 前导码(8B) + 以太网帧头(14B) + IP头(20B) + UDP头(8B) + 有效载荷 + 帧间隙(12B)
举个例子，千兆以太网，MTU=1500字节，UDP有效载荷最大1472字节（1500 - 20 - 8）。
算一下帧总长：8 + 14 + 20 + 8 + 1472 + 12 = 1534字节。
理论吞吐量 = 1Gbps × (1472 / 1534) ≈ 0.96 Gbps。
嗯，看起来还不错，能跑96%的线速。但这是理想情况，实际中你几乎不可能达到。
3.2 实际吞吐量影响因素：为什么跑不满？
实际吞吐量，才是我们真正关心的数字。我见过太多人拿着理论值去压测，结果发现只能跑到600Mbps，然后开始怀疑网卡坏了。
影响实际吞吐量的因素，我归纳为以下四大类：
| 因素类别 | 具体影响 | 典型损失 |
|---|---|---|
| CPU瓶颈 | 中断处理、数据拷贝、协议栈开销 | 10%~40% |
| 内存带宽 | DMA拷贝、缓存命中率 | 5%~20% |
| PCIe带宽 | 网卡与CPU之间的总线瓶颈 | 5%~15% |
| 应用层处理 | 系统调用、锁竞争、内存分配 | 10%~50% |
我曾经在一个项目中，UDP接收端只能跑到400Mbps，CPU占用率却已经100%了。排查后发现，是应用层每次recvfrom都做了一次内存拷贝和日志打印。去掉日志后，直接飙到800Mbps。你想想看，一个日志打印就能吃掉一半的吞吐量。
我的经验：实际吞吐量通常只有理论值的60%~80%。如果低于50%，说明某个环节存在严重瓶颈。优先检查CPU软中断占用率和应用层处理逻辑。
3.3 链路层开销对UDP的影响：被忽视的隐形杀手
链路层开销，是UDP吞吐量最容易被忽视的坑。很多人只算了IP头和UDP头，却忘了以太网帧的前导码、帧间隙和帧头。
我们来看一个完整的以太网帧结构：
| 前导码(7B) | 帧起始定界符(1B) | 目的MAC(6B) | 源MAC(6B) | 类型(2B) | 数据(46~1500B) | FCS(4B) | 帧间隙(12B) |注意，前导码和帧间隙虽然不算在MTU里，但它们实实在在地占用了物理层的传输时间。对于小包UDP，这个开销占比会非常恐怖。
举个例子，发送64字节的UDP小包：
- 有效载荷：64 - 20(IP) - 8(UDP) = 36字节
- 帧总长：8 + 14 + 20 + 8 + 36 + 4 + 12 = 102字节
- 有效载荷占比：36 / 102 ≈ 35.3%
也就是说，千兆以太网发64字节UDP包，理论吞吐量只有350Mbps左右。剩下的650Mbps，全被链路层开销吃掉了。
避坑指南：我曾经在一个VoIP项目中，用默认的UDP小包（每个包只带20ms音频，约320字节）做传输，结果带宽利用率不到50%。后来我把多个音频帧合并到一个UDP包中发送，吞吐量直接翻倍。记住，小包是UDP吞吐量的天敌。
3.4 核心知识体系：一张图看懂
下面这张图，把带宽、吞吐量、链路层开销的关系梳理清楚了。建议你保存下来，做性能分析时对照着看。
3.5 实战：如何估算你的UDP吞吐量上限
说了这么多理论，来点实际的。我一般用下面这个步骤来估算一个系统的UDP吞吐量上限：
- 确定链路带宽：比如1Gbps、10Gbps、25Gbps。
- 确定包大小：UDP有效载荷是多少字节？
- 计算帧总长：8(前导码) + 14(以太网头) + 20(IP头) + 8(UDP头) + 有效载荷 + 4(FCS) + 12(帧间隙)。
- 计算理论包率：带宽 / (帧总长 × 8)。
- 计算理论吞吐量：理论包率 × 有效载荷 × 8。
- 打折扣：乘以0.7（保守估计），得到实际吞吐量上限。
举个例子：
10Gbps网卡，UDP有效载荷1400字节。
帧总长 = 8 + 14 + 20 + 8 + 1400 + 4 + 12 = 1466字节。
理论包率 = 10,000,000,000 / (1466 × 8) ≈ 852,000 pps。
理论吞吐量 = 852,000 × 1400 × 8 ≈ 9.54 Gbps。
实际预估 = 9.54 × 0.7 ≈ 6.68 Gbps。
嗯，这个数字比较靠谱。如果实际跑下来低于5Gbps，就该排查系统瓶颈了。
3.6 避坑总结：我踩过的三个坑
最后，分享三个我亲身踩过的坑，希望能帮你省点时间：
- 坑一：忽略帧间隙。我曾经算理论吞吐量时忘了加12字节帧间隙，结果怎么测都差一截。后来加上去，数字就对上了。
- 坑二：小包压测CPU先爆。64字节UDP小包，千兆网卡理论包率约1.48M pps。但很多CPU在1M pps时软中断就已经100%了。这时候不是带宽瓶颈，是CPU瓶颈。
- 坑三：MTU设置不当。默认MTU 1500，但如果你在内网环境，可以开启巨帧（Jumbo Frame，MTU 9000）。UDP有效载荷从1472变成8972，帧总长占比大幅提升，吞吐量能涨30%~50%。当然，前提是你的交换机也支持。
记住，UDP吞吐量不是算出来的，是测出来的。理论计算只是给你一个参考天花板，真正的瓶颈往往藏在你想不到的地方。