Page 310 - Web性能权威指南
P. 310
• 每个 SRTP 分组都包含一个自动递增的序号，以便接收端检测和发现媒体数据是
否乱序；
• 每个 SRTP 分组都包含一个时间戳，表示媒体净荷第一字节的采样时间，用于多
个媒体流（如音频和视频）的同步；
• 每个 SRTP 分组都包含一个 SSRC 标识符，这是个别媒体流中每个分组的唯一
流 ID；
• 每个 SRTP 分组可以包含其他可选的元数据；
• 每个 SRTP 分组都包含加密的媒体净荷，以及（可选的）认证标签，后者用于验
证分组的完整性。
SRTP 分组中包含了媒体引擎实时回放流必需的所有信息。而控制每个 SRTP 分组
交付则是 SRTCP 协议的责任，SRTCP 针对每个媒体流实现了独立的外部反馈渠道。
SRTCP 会跟踪发送及丢失字节和分组的数量，跟踪每个 SRTP 分组的序号、交错到
达抖动，以及其他 SRTP 统计信息。然后，两端定时交换这些数据，以便调整每个
流的发送速率、编码品质和其他参数。
简单地说，SRTP 和 SRTCP 直接在 UDP 之上运行，共同完成对应用提供的音频和
视频流的实时适配和优化。WebRTC 应用不会接触内部的 SRTP 或 SRTCP 协议：
如果你要构建自定义的 WebRTC 客户端，那得直接操作这两个协议，否则浏览器会
替你搭建好所有必要的基础设施。
真想看看 WebRTC 会话的 SRTCP 统计信息？ Chrome 就可以让你看到延
迟、比特率和带宽等情况，详情请见 18.4.5 节中的“使用谷歌 Chrome 浏
览器检测 WebRTC 连接状态”。
适应 WebRTC 的 SRTP 和 SRTCP
我们对 SRTP 和 SRTCP 的介绍简单但重点突出，不过对实现来说，为了让这两个
协议达到 WebRTC 的要求，还需要考虑另外一些细节。
• SRTP 和 SRTCP 都会加密应用净荷数据（WebRTC 的要求），但它们都没有
提供协商密钥的机制！这就是为什么必须先进行 DTLS 握手的原因：DTLS
握手会为两端确定一个共享密钥，随后的 SRTP 和 SRTCP 可以使用这个密钥。
• SRTP 和 SRTCP 都要求对不同的流分配不同的端口，而这对于 NAT 或防火
墙后面的客户端当然就是一个问题。为解决这个问题，WebRTC 使用了另一
个多路复用扩展，以便向同一个目标端口交付多个流（以及相应的控制信道）。
• IETF 还 制 定 了 一 个 新 的 拥 塞 控 制 算 法， 该 算 法 利 用 SRTCP 的 反 馈 对
WebRTC 应用生成的音频和视频流进行优化。
300 ｜ 第 18 章
