Page 308 - Web性能权威指南

身份与验证

WebRTC 两端之间的 DTLS 握手有赖于自签名证书。而这样的证书不能用于验证
身份，因为没有要验证的信任链（4.4 节“信任链与证书颁发机构”）。必要的情况
下，WebRTC 应用必须自己对参与各端进行认证和身份验证：

• Web 应用可以利用之前用于建立 WebRTC 会话的身份验证系统（比如通过登
录来验证用户）；
• 此外，每一端也可以在生成 SDP 提议 / 应答时指定各自的“身份颁发机构”，
等对端接收到 SDP 消息后，可以联系指定的身份颁发机构验证收到的证书。
后一种“身份颁发机构”机制是 W3C WebRTC 工作组目前还在讨论和制定的一种
机制。要了解最新进展，可以阅读相应的规范和邮件列表。

18.5.2 通过SRTP和SRTCP交付媒体

WebRTC 以完全托管的形式提供媒体获取和交付服务：从摄像头到网络，再从网络
到屏幕。WebRTC 应用指定获取流的媒体约束，然后通过 RTCPeerConnection 对象注
册它们（图 18-13）。从此以后，就都是浏览器提供的 WebRTC 媒体和网络引擎的事
了：编码优化、处理丢包、网络抖动、错误恢复、流量、控制，等等。

ᆌᆩ ᆌᆩ

एᇀUDPڦSRTP

图 18-13：通过 SRTP 和 SRTCP 交付音频和视频

这种架构设计的用意很简单，就是应用除了在一开始指定媒体流的约束外（如 720p
还是 360p 视频），无法直接控制媒体如何优化以及如何交付给另一端。这样的设计
是有意为之的，毕竟，通过带宽波动、分组延迟的不可靠传输机制交付高品质、实
时的音频和视频，不是一件容易的事。浏览器可以替我们做这些事。

• 不用关心提供的媒体流的品质和大小，网络组件会实现自己的流和拥塞控制算法，
让每个连接开始时的比特率保持较低（<500 Kbit/s），然后再根据带宽调整流的
品质；

298 ｜ 第 18 章