使用 eBPF 调试 WebRTC SFU：找出你的媒体服务器在哪里 “吞掉” 数据包
内容提要
文章介绍用eBPF测量WebRTC SFU的UDP数据包在内核socket队列中的停留时间，以区分服务器延迟与网络抖动。getStats()只能反映抖动、丢包等聚合指标，无法定位原因。通过挂接内核探针记录入队与读取时间戳，可亚微秒级判断服务器是否因负载导致数据包排队，从而在质量劣化前定位问题。
延伸解读
为什么 getStats() 不够用
getStats() 提供的是接收端聚合指标，如抖动、丢包数和往返时延，能反映质量劣化，却无法区分原因。文章用两个场景说明：数据包在 SFU 的 socket 队列中等待 12ms，与数据包在互联网传输中额外引入 12ms 抖动，在 getStats() 上可能产生相似噪声，但修复方向完全不同。前者需要优化服务器负载，后者需要应对网络状况。因此，仅靠应用层统计无法定位责任方。
eBPF 驻留时间如何区分服务器与网络
文章通过挂接 __udp_enqueue_schedule_skb 和 udp_recvmsg 两个内核探针，记录每个 UDP 数据包进入 socket 接收队列和应用程序读取它的时间戳，两者之差即驻留时间。在演示中，服务器负载场景下平均驻留时间跃升至 76ms，而网络损伤场景下驻留时间保持在 33µs。这说明驻留时间高意味着服务器侧排队，驻留时间低则表明服务器处理及时，问题更可能出在网络传输途中。
早期预警与低开销
文章指出，CPU 饥饿往往首先表现为尾延迟尖峰，远早于聚合利用率指标越过报警阈值。在演示的服务器负载场景中，getStats() 显示抖动攀升但丢包为零、FPS 不变，看似不紧急，而 eBPF 面板已显示驻留时间飙升并触发 ALERT。此外，每次探针调用开销约 100–200ns，在每秒 9000 个数据包、两个探针的情况下，每秒约消耗 3.6ms CPU，即单核的 0.36%，对诊断工具而言可以忽略。
可扩展的内核级观测框架
文章强调，socket 队列驻留时间只是一个指标，同样的模式可扩展到其他测量：挂接 kfree_skb 区分服务器与网络丢包、测量运行队列延迟以了解 SFU 线程等待 CPU 的时间、检测软中断处理延迟，以及每核 IRQ 到应用的时间。这些测量都遵循入口挂 kprobe、出口挂 kretprobe 并计算差值的通用方法，且不依赖 SFU 的具体实现语言或框架。
Q&A
eBPF 是什么？它为什么适合用来调试 WebRTC SFU？
eBPF 是一项 Linux 内核技术，能在内核内部直接运行小型、沙箱化的程序，无需修改内核源代码或加载自定义模块。它允许挂接到内核函数上，提取应用层工具无法触及的度量数据，并在问题变得用户可见之前捕获。由于它在应用层之下运行，同一个跟踪器无论 SFU 用什么语言或实现都适用。
getStats() 在诊断 WebRTC 质量问题时有什么不足？
getStats() 提供的是接收端聚合指标，如 jitter、packetsLost、roundTripTime，能判断质量劣化但不足以定位原因。例如，数据包可能因服务器负载在 socket 队列中排队，也可能因网络拥塞而延迟，两者在 getStats() 上表现相似。在持续压力下，这些指标会模糊在一起，无法区分服务器侧与网络侧的问题。
什么是 RTP 数据包停留时间（dwell time）？它如何帮助区分服务器延迟和网络抖动？
停留时间是指每个 UDP 数据包在被应用程序读取之前，在内核 socket 接收队列中等待的时长。通过 eBPF 测量这个时间，可以亚微秒级判断服务器是否因负载导致数据包排队。如果停留时间高，说明服务器有责任；如果停留时间低，说明服务器处理及时，问题出在网络传输途中。
如何用 eBPF 测量 UDP 数据包在 socket 队列中的停留时间？
挂接 kprobe 到 __udp_enqueue_schedule_skb（数据包入队时）记录纳秒级时间戳到每个 socket 的 FIFO；挂接 kretprobe 到 udp_recvmsg（应用程序读取数据包时）取出最早时间戳，用当前时间减去它计算停留时间，并通过环形缓冲区发送到用户空间。用户空间用 cilium/ebpf 加载程序并聚合事件成直方图。
eBPF 跟踪器的性能开销有多大？
每次探针调用的开销约为 100–200ns。在每秒 9,000 个数据包、使用两个探针的情况下，每秒大约消耗 3.6ms 的 CPU，也就是单核的 0.36%。对于一个诊断工具来说，这可以忽略不计。
在服务器负载和网络损伤两种场景下，eBPF 停留时间指标分别表现如何？
服务器负载场景：平均停留时间跃升至 76ms，最高达 193ms，状态翻转为 ALERT，而 getStats() 显示抖动攀升但丢包为零。网络损伤场景：eBPF 面板保持在 33µs 停留时间，状态为 OK，而 getStats() 显示丢包率上升、RTT 攀升。因此，停留时间高说明服务器有责任，低则说明服务器清白。
除了 socket 队列停留时间，eBPF 还能为 WebRTC 工作负载提供哪些其他测量？
eBPF 还能实现：内核侧丢包计数（挂接 kfree_skb，区分服务器导致的丢包与网络丢包）、运行队列延迟（测量 SFU 线程等待 CPU 时间多久）、软中断处理延迟（检测 NAPI 预算耗尽时数据包交付被推迟的情况），以及每核 IRQ 到应用的时间。模式都是入口挂 kprobe、出口挂 kretprobe、计算差值。
