实时通信（一）：网络基础，延迟、抖动、丢包与拥塞控制

实时通信不是一个单独协议能完成的事情。一次语音通话从麦克风到扬声器，要经过物理介质、链路接入、IP 路由、传输协议、媒体协议和应用逻辑。分层的意义是：每层只解决自己能解决的问题，上层不要把所有问题都误判成“网络不好”。

普通文件下载关心总耗时，实时音视频关心每一小段声音和画面能不能按时到。一个视频包晚到 500 ms，即使最终没丢，对播放器也几乎等价于丢了：它错过了播放时刻。

延迟通常由传播、传输、处理和排队组成。传播延迟来自物理距离，无法用代码消除；传输延迟来自链路速率和包大小；处理延迟来自编码、解码、加密、转发；排队延迟则来自路由器、系统 socket buffer、发送队列和服务端媒体队列。实时通信优化最常见的战场就是排队延迟。

在进入 WebRTC 之前，先要分清网络栈里的两个基础传输协议：TCP 和 UDP。它们都工作在 IP 之上，负责把一台机器上的应用数据送到另一台机器上的应用端口；区别在于，TCP 把网络伪装成一条可靠、有序的字节流，UDP 则只提供最小的数据报投递能力。

TCP 三次握手：为什么连接要来回三步

TCP 不是“发一个包就开始传业务数据”。它先要建立连接状态，让两端确认彼此都能收发，并同步初始序列号。这个过程就是三次握手。

为什么媒体更偏爱 UDP

TCP 适合网页、文件、接口请求，但对实时媒体有一个根本问题：队头阻塞。只要前面的字节没补齐，后面的字节即使已经到达，也不能交给应用层。对视频来说，这可能意味着为了等一个过期包，把后面已经可播放的新画面也堵住。

UDP 把选择权交给应用层：哪些包值得等，哪些包过期就丢，哪些关键帧需要重发，码率如何降，是否打开 FEC 或 NACK。WebRTC 正是建立在这种思路上：媒体通常走 UDP/RTP，可靠性和拥塞控制由实时媒体栈自己做。

WebRTC：不是一个协议，而是一套实时媒体协议栈

UDP 和 RTP 的关系：UDP 送包，RTP 说明这个包是什么

UDP 只知道“从 A 端口发一个数据报到 B 端口”，它不知道这个数据报里是音频、视频、关键帧还是普通帧。RTP 负责给实时媒体数据加上时间戳、序列号、载荷类型、同步源标识等信息，让接收端可以判断包的顺序、播放时间和属于哪一路媒体流。

FEC 和 NACK：实时媒体怎么补救丢包

UDP 不自动重传，实时媒体就必须自己决定“丢了以后怎么办”。最常见的两种机制是 FEC 和 NACK。

实时通信的发送端需要持续估计可用带宽。发少了，画质差；发多了，路由器和服务端队列堆积，延迟上升，最后丢包和卡顿一起出现。现代 RTC 的拥塞控制会综合丢包、延迟梯度、RTT、接收端反馈和码率变化，动态调整编码码率、分辨率、帧率和发送节奏。

graph LR
    A["发送端编码器"] --> B["RTP 包发送"]
    B --> C["网络队列 / 丢包 / 抖动"]
    C --> D["接收端统计"]
    D --> E["RTCP feedback"]
    E --> F["带宽估计 / 拥塞控制"]
    F --> A

真实线上问题通常不是“网络不好”四个字能解释。要先判断坏的是建连、上行、下行、编码、解码、渲染，还是服务端转发。网络层常用的切入口包括 RTT 是否升高、jitter 是否突刺、丢包是上行还是下行、NACK/PLI/FIR 是否频繁、发送码率是否被带宽估计压低、socket 或 pacer 队列是否堆积。