udp在实时音视频传输中被广泛采用，核心是用可接受的丢包换取低延迟和高响应性；其无连接、无重传、8字节轻量头部及独立数据报特性，显著降低端到端延迟，天然适配rtp等音视频协议，并支持fec、nack等应用层可靠性增强机制。
Linux 下 UDP 协议在实时音视频传输中被广泛采用，核心在于它用“可接受的丢包”换来了不可替代的低延迟和高响应性。这不是妥协，而是针对场景的精准选择。
无连接机制大幅降低端到端延迟
UDP 不需要三次握手建连，也不维持连接状态。发送端拿到目标地址后，直接封装数据报发出——整个过程毫秒级完成。比如在 WebRTC 视频通话中，一帧画面从采集、编码到推送到对方屏幕，若走 TCP，仅握手+确认就可能增加 20~50ms 延迟；而 UDP 省掉这部分开销，让首帧更快抵达，对唇音同步、手势反馈等体验至关重要。
- 每个 UDP 数据报独立路由，不依赖前序包状态
- 头部仅 8 字节，比 TCP 的 20+ 字节更轻量
- Linux 内核对 UDP socket 的处理路径短，系统调用开销小
无重传设计避免延迟累积
TCP 的重传机制在音视频场景中反而成“毒药”。一旦某帧关键数据包丢失，TCP 会等待超时再重发，导致后续所有帧被迫排队等待，形成“拖尾延迟”。而 UDP 默认不重传，接收端可立即解码已到达的数据，配合 RTP 时间戳做抖动缓冲与丢帧跳过，整体播放节奏稳定可控。
- 典型直播中，允许单帧丢失 1~2%，人眼几乎无感
- 语音通话中，丢包由 PLC（丢包隐藏）算法插值补偿，比等重传更自然
- 延迟保持在 100~300ms 区间，满足“面对面交流”的感知阈值
天然适配音视频上层协议栈
UDP 本身不干预数据结构，为 RTP、RTCP、SRTP 等专业音视频协议提供了干净载体。RTP 利用 UDP 的数据报边界，天然支持帧粒度划分；RTCP 在同一会话中复用 UDP 端口反馈质量；SRTP 可直接加密 UDP 载荷，无需像 TCP 那样担心流式加密的边界问题。
- RTP 时间戳与序列号由应用层精确控制，实现音画同步与乱序恢复
- 支持单播、多播、广播，便于一对多直播或局域网协同会议
- 防火墙穿透更友好，NAT 类型兼容性优于 TCP（尤其对称型 NAT）
应用层可按需增强可靠性
UDP 的“不可靠”是协议层面的，不等于应用不可靠。现代音视频系统普遍在 UDP 基础上叠加轻量级可靠性机制，兼顾效率与健壮性：
- 前向纠错（FEC）：发送冗余包，接收端无需请求即可恢复部分丢包
- 选择性重传（NACK）：只重传关键帧或接收方明确请求的包，避免泛洪
- 自适应码率（ABR）：根据 RTCP 反馈动态调整编码参数，主动规避拥塞
- 像 KCP 这类“可靠 UDP”库，就是在 UDP 上实现快速重传与滑动窗口，延迟仍远低于 TCP
本质上，Linux UDP 不是“凑合用”，而是为实时音视频量身定制的传输底座——它把复杂性留给更懂业务的应用层，把速度和确定性留给了每一帧画面与每一声语音。
