1. WebRTC实时通信概述：架构、挑战与丢包影响

各位同学好，我是老张。做实时音视频这行十几年了，踩过的坑比走过的路还多。今天咱们开始《WebRTC丢包恢复与抗丢包编码》的第一章，先把地基打牢。

WebRTC这玩意儿，说白了就是浏览器之间直接通话的技术。不用装插件，不用额外客户端，打开网页就能视频。但真正把它用好，你得理解它背后的架构和那些让人头疼的网络问题。

先看一张整体架构图，我习惯把WebRTC分成四层：

核心要点：WebRTC不是单一协议，而是一整套实时通信解决方案的集合。

这四层各司其职。应用层给你提供API，会话层负责建立连接，传输层保证数据安全到达，网络层处理底层的网络通信。我们这门课重点在传输层，尤其是丢包恢复这块。

做实时通信，说白了就是在跟物理定律较劲。我当年做第一个视频通话项目时，天真地以为只要把数据发出去就行了。结果呢？画面卡成PPT，声音断断续续，用户直接投诉到老板那里去了。

实时通信面临的主要挑战，我总结为以下四点：

我的经验：这四个挑战中，丢包是最难处理的。延迟你可以通过优化路由解决，抖动可以用jitter buffer吸收，带宽波动可以动态调整码率。但丢包一旦发生，数据就没了，你得想办法把它找回来或者补上去。

丢包到底有多可怕？咱们分场景来看。

音频数据是连续采样的，每个包包含几十毫秒的音频帧。丢一个包，就意味着这段时间的声音完全丢失。

我记得有一次线上会议，有个同事的网络丢包率到了8%。他说的每句话都像被剪刀剪过一样，我们只能靠猜来理解他的意思。最后不得不让他关掉视频，只保留音频，才勉强能沟通。

视频丢包的影响更直观。视频编码依赖帧间预测，一个关键帧丢了，后面几十个依赖它的帧全废了。

注意：视频丢包有"雪崩效应"。一个I帧丢了，后续所有P帧和B帧都无法解码，直到下一个I帧到来。这会导致画面长时间卡住或绿屏。

我曾经在一个项目中遇到过极端情况：用户网络丢包率15%，视频画面直接变成马赛克拼图，人脸都认不出来。用户说"你们这产品还不如QQ视频"，这话我记了好几年。

丢包率	音频MOS分	视频PSNR(dB)	用户体验评级
0%	4.5	40+	优秀
1%	4.0	35	良好
3%	3.2	28	一般
5%	2.5	22	差
10%+	1.5	15	不可用

你看这个表，丢包率从0%到5%，用户体验直接从"优秀"掉到"差"。这就是为什么我们要花30章来讲丢包恢复——它直接决定了产品的生死。

WebRTC内置了几种丢包恢复机制，我简单列一下，后面每章都会详细讲：

核心思路：没有一种策略能解决所有丢包问题。实际产品中需要组合使用，根据网络状况动态切换。这也是我们这门课要讲的核心——怎么组合、怎么调优。

好了，第一章就到这里。你想想看，丢包这件事，看似简单，但牵扯到编码、传输、解码、播放整个链路。后面我们会一步步深入，把每个环节都吃透。