视频通话的 200 毫秒里发生了什么
内容提要
实时视频通话需在200毫秒内完成采集、传输、缓冲与渲染。WebRTC让浏览器无需插件即可实现，通过NAT打洞和中继服务器建立连接，用编解码器在弱网下降质保流畅，并强制加密。一对一通话常走点对点最短路径，将延迟预算用于双方之间。
延伸解读
200毫秒预算如何分配
文章将200-300毫秒的延迟预算拆解为采集编码、网络传输、抖动缓冲、解码渲染四个阶段，其中网络传输可能吃掉四分之三的预算。这意味着工程优化的重点往往不在编解码本身，而在于如何对抗网络抖动和丢包。读者可以理解，为什么弱网下通话质量下降是必然的，而“故意变差”的策略正是为了保住对话的连续性。
WebRTC的连接建立与NAT穿透
两台位于家用路由器后的设备无法直接互访，WebRTC通过NAT打洞和中继服务器完成“引荐”。大约五分之一的通话需要中继，这增加了延迟和服务器成本。一对一通话常走点对点最短路径，将延迟预算全部用于双方之间，而群组通话因需要服务器混流，每一跳都会累积延迟。这解释了为什么一对一视频往往比群组通话更流畅。
弱网下的降质策略与音频优先
编解码器在弱网下会主动降低分辨率、推测补帧，而不是冻结画面。音频被放在专属的“受保护车道”，因为用户对画面模糊容忍度高，但声音卡顿会迅速导致挂断。拥塞控制每秒数十次探测调整，类似冰面轻点油门。这些设计共同保证了通话能跨越复杂网络环境，甚至中途切换网络也不中断。
强制加密与编解码器之争的深层影响
WebRTC不允许明文传输，DTLS和SRTP强制加密，代价仅是几毫秒的建立时间。编解码器方面，Opus持续调整码率，视频则在VP8、H.264、VP9、AV1之间竞争，AV1在同等感知质量下压缩率提升约30%。这些效率提升降低了可观看通话的带宽下限，决定了视频能否在乡村线路或拥挤蜂窝网络中工作，本质上关乎谁有资格拥有这场对话。
Q&A
实时视频通话为什么必须把延迟控制在200毫秒以内？
因为从开口到被听到，如果间隔超过200–300毫秒，对话就会开始撞车，出现两人同时道歉、互相等待的沉默。实时音视频的每一个设计决策都源自这条硬性约束。
WebRTC是如何让两台家用路由器后面的设备建立连接的？
WebRTC先让每台设备弄清自己在外部看来公网地址是什么，尝试通过NAT打洞建立直接路径，同时保留一台中继服务器作为后备，以应对约五分之一直接路径不通的电话。整个协商在“正在呼叫……”到画面出现之间的两秒内完成。
在网络状况糟糕时，WebRTC如何保证通话不中断？
编解码器会“故意变差”而不是“卡死冻结”：分辨率会柔软地降下来一两秒，丢失的帧从相邻帧推测补出。音频走专属的“受保护车道”，因为人们对模糊画面可以容忍，但声音一卡就会挂断。拥塞控制每秒数十次探测连接并调整。
WebRTC的加密是可选的吗？
不是。WebRTC不允许以明文方式发送媒体，没有明文模式或配置开关。视频流动前，DTLS完成密钥交换，随后SRTP为每个数据包提供保护。代价只是几毫秒的建立时间，被埋在“正在连接”阶段。
为什么一对一视频通话通常比群组通话延迟更低？
一对一通话可以常走点对点路线，即两张脸之间最短的路径，端到端加密，整个延迟预算全部花在同一段关系上。而群组通话需要服务器混流和路由，每一跳都要付出几毫秒的代价。
视频编解码器的效率提升为什么比画质更重要？
每一点效率提升都会降低一场对话保持可观看所需的带宽下限，这个下限决定了视频在乡村线路或拥挤蜂窝网络中能否工作。因此编解码器之争本质上是在争论谁有资格拥有这场对话。
