2、UDP性能指标定义：吞吐量、延迟、抖动、丢包率

聊UDP性能，不能光凭感觉说“快”或“慢”。你得有尺子。我个人习惯，先盯死四个核心指标：吞吐量、延迟、抖动、丢包率。这四个数，基本能还原一条UDP链路的真实面貌。

但注意，UDP场景下，这些指标的含义和TCP不太一样。你想想看，TCP有重传、有拥塞控制，指标之间会互相拉扯。UDP呢？它不管这些，指标更“赤裸”，也更危险。

吞吐量，说白了就是单位时间内成功送达的数据量。单位通常是Mbps或pps（每秒包数）。

UDP场景下的特殊含义：

应用层吞吐 vs 网络层吞吐：UDP没有ACK，应用层发出去的包，网络层不一定全送到了。我习惯把“应用层认为已发送的速率”叫发送吞吐，把“对端实际收到的速率”叫有效吞吐。两者之差，就是丢包造成的浪费。
小包吞吐陷阱：UDP常用于小包（比如DNS、NTP、游戏同步）。小包场景下，pps才是瓶颈，而不是带宽。我曾经在项目中遇到过，千兆网卡发64字节小包，吞吐量死活上不去，最后发现是CPU中断处理不过来，网卡收包速率卡在了1.4Mpps。

    核心公式：有效吞吐 = 发送速率 × (1 - 丢包率)

    这个公式在UDP场景下比TCP更关键，因为UDP不会自动补偿丢包。

延迟就是单程时间。单位毫秒（ms）。

UDP场景下的特殊含义：

无连接延迟：UDP不需要握手，第一个包就能直接发。相比TCP的SYN/SYN-ACK，UDP天然省掉了1个RTT的建立延迟。这对实时性要求高的场景（比如VoIP、视频会议）是巨大优势。
延迟的组成：我习惯拆成四段——发送延迟（应用层到网卡）、传播延迟（光速跑）、处理延迟（路由器转发）、排队延迟（缓冲区等待）。UDP场景下，排队延迟最不可控。因为UDP没有流控，发送端可以瞬间把路由器缓冲区塞满，导致延迟飙升。

避坑指南：我曾经在金融行情系统中遇到过，UDP组播延迟在开盘瞬间从0.5ms跳到200ms。查了半天，发现是交换机缓冲区被突发流量撑爆了。后来我们强制在发送端做了速率整形，才把延迟拉回来。

抖动，就是延迟的变化量。单位也是ms。公式很简单：抖动 = |当前延迟 - 平均延迟|。

UDP场景下的特殊含义：

抖动比延迟更致命：对于实时音视频，200ms的稳定延迟可以接受，但10ms的剧烈抖动会直接导致卡顿。UDP没有TCP的平滑机制，抖动完全暴露给上层。
抖动来源：主要是路由器的队列调度和CPU的调度延迟。我见过一个案例，服务器上跑着多个UDP服务，其中一个服务突发发包，导致其他服务的抖动从1ms飙到50ms。这就是典型的“吵闹邻居”问题。

注意：抖动在UDP场景下，通常用Jitter Buffer来吸收。但Jitter Buffer本身会引入额外延迟。这是一个典型的“延迟-抖动”权衡。

丢包率 = 丢失包数 / 总发送包数 × 100%。

UDP场景下的特殊含义：

UDP丢包不可见：TCP丢包后，发送端会感知到（因为没收到ACK），然后重传。UDP丢包，发送端完全不知道。除非应用层自己实现确认机制，否则丢包就是“静默消失”。
丢包原因：除了网络拥塞，UDP还容易因为接收缓冲区溢出而丢包。我曾经遇到过，接收端应用层处理太慢，内核缓冲区满了，新来的UDP包直接被丢弃。从网络层面看，链路是好的，但应用层就是收不到。

    关键认知：UDP丢包率 ≠ 网络丢包率。应用层丢包可能来自：

    - 接收缓冲区满（内核丢包）

    - 应用层处理不过来（应用丢包）

    - 校验和错误（静默丢弃）

这四个指标不是孤立的。我画了一张图，帮你理清它们之间的影响关系。

测量UDP性能，工具和方法和TCP不太一样。我列个表，方便你对比。

指标	测量工具	UDP场景注意事项
吞吐量	iperf3 -u, nuttcp	必须指定带宽上限（-b），否则UDP会打满链路
延迟	ping, hping3, sockperf	UDP ping需要服务端监听，否则收不到回包
抖动	iperf3 -u -J, Wireshark	Wireshark的“IO Graph”可以看延迟分布
丢包率	iperf3 -u, netstat -s	netstat -s 可以看“packet receive errors”

我的习惯：测量UDP吞吐量时，我会先用iperf3跑一次不带-b的，看看链路能撑多少。然后逐步降低-b，找到“不丢包的最大吞吐量”。这个值，才是你应用层能安全使用的上限。

这四个指标，是诊断UDP性能问题的起点。记住：