《Web性能权威指南》-WebRTC-读书笔记

本文是《Web性能权威指南》第四部分——WebRTC的读书笔记。
第一部分——网络技术概览，请参考网络技术概览；
第二部分——无线网络性能，请参考无线网络性能；
第三部分——HTTP，请参考HTTP；
第四部分——浏览器API与协议的前四章，请参考浏览器API与协议。

WebRTC

Web Real-Time Communication，Web实时通信，WebRTC，由一组标准、协议和JS API组成，用于实现浏览器之间（端到端）的音频、视频及数据共享。WebRTC使得实时通信变成一种标准功能，任何Web应用都无需借助第三方插件和专有软件，而是通过简单的JavaScript API即可利用。

要实现涵盖音频和视频的电话会议等完善、高品质的RTC应用、端到端的数据交换，需要浏览器具备很多新功能：音频和视频处理能力、支持新应用API、支持好几种新网络协议。浏览器把前述这些复杂性抽象成三个主要API：

• MediaStream：获取音频和视频流；
• RTCPeerConnection：音频和视频数据通信；
• RTCDataChannel：任意应用数据通信。

WebRTC通过UDP传输数据。

标准和WebRTC的发展

WebRTC架构由十余个标准组成，涵盖应用和浏览器API，以及很多必要的协议和数据格式：

• W3C的Web Real-Time Communications（WEBRTC）Working Group负责制定浏览器API；
• IETF的Real-Time Communication in Web-browsers（RTCWEB）工作组负责定义协议、数据格式、安全及其他在浏览器中实现端到端通信必需的内容。

设计WebRTC时也会考虑已有通信系统：VOIP（VoiceOver IP）、各种SIP客户端、PSTN（Public Switched Telephone Network，公共交换电话网）等。

音频和视频引擎

要实现电话会议功能，浏览器必须访问系统硬件采集音频和视频；还需对它们分别加以处理以增强品质，保证同步，而且要适应不断变化的带宽和客户端之间的网络延迟调整输出的比特率。

接收端的处理过程相反，必须实时解码音频和视频流，并适应网络抖动和时延。

如上图，浏览器会负责：

• 音频流降噪和回声消除处理、优化的窄带或宽带音频编解码器编码、错误补偿算法消除网络抖动和丢包造成的损失；
• 视频的影像品质，选择最优的压缩和编解码方案，应用抖动和丢包补偿。

浏览器要动态调整其处理流程，以适应不断变化的音频和视频流及网络条件。

W3C的Media Capture and Streams规范规定一套JS API：

解读：

• MediaStream对象包含一或多个Track（MediaStreamTrack）；
• MediaStream中的多个Track相互之间是同步的；
• 输入源可以是物理设备，如麦克风、摄像头、用户硬盘或另一端远程服务器中的文件；
• MediaStream的输出可被发送到一或多个目的地：本地的视频或音频元素、后期处理的JS代理，或远程另一端。

MediaStream对象表示一个实时的媒体流，以便应用代码从中取得数据，操作个别的Track和控制输出。所有的音频和视频处理，比如降噪、均衡、影像增强等都由音频和视频引擎自动完成。

getUserMedia()，从底层平台取得音频和视频流的简单API；负责获准访问用户的麦克风和摄像机，并获取符合指定要求的流。取得流之后，还可以将它们提供给其他浏览器API：

• 通过Web Audio API在浏览器中处理音频；
• 通过Canvas API采集个别视频帧并加以处理；
• 通过CSS3和WebGL API为输出的流应用各种2D/3D特效。

当前的WebRTC实现使用Opus和VP8编解码器：

• Opus编解码器用于音频，支持固定和可变的比特率编码，适合的带宽范围为6~510Kbit/s。这个编解码器可以无缝切换，以适应不同的带宽。
• VP8编解码器用于视频编码，要求带宽为100~2000+Kbit/s，比特率取决于流的品质，如180p，360p，720p。

实时网络传输

实时通信讲究的就是及时、当下。因此，处理音频和视频流的应用一定要补偿间歇性的丢包：音频和视频编解码器可以填充小的数据空白，通常对输出品质的影响也很小。类似地，应用必须实现自己的逻辑，以便因传输其他应用数据而丢包或延迟时快速恢复。及时和低延迟比可靠更重要。

UDP协议才更适合用于传输实时数据。UDP提供下列不服务：

• 不保证消息交付：不确认，不重传，无超时；
• 不保证交付顺序：不设置包序号，不重排，不会发生队首阻塞；
• 不跟踪连接状态：不必建立连接或重启状态机；
• 不需要拥塞控制：不内置客户端或网络反馈机制。

UDP是浏览器实时通信的基础，但要完全达到WebRTC的要求，浏览器还需要位于其上的大量协议和服务的支持，如下图所示：

WebRTC的协议分层：

• ICE：Interactive Connectivity Establishment，RFC 5245
• STUN：Session Traversal Utilities for NAT，RFC 5389
• TURN：Traversal Using Relays around NAT，RFC 5766
• SDP：Session Description Protocol，会话描述协议，RFC 4566
• DTLS：Datagram Transport Layer Security，RFC 6347
• SCTP：Stream Control Transport Protocol，RFC 4960
• SRTP：Secure Real-Time Transport Protocol，RFC 3711

ICE、STUN和TURN是通过UDP建立并维护端到端连接所必需的。DTLS用于保障传输数据的安全，加密是WebRTC强制的功能。SCTP和SRTP属于应用层协议，用于在UDP之上提供不同流的多路复用、拥塞和流量控制，以及部分可靠的交付和其他服务。

RTCPeerConnection API

RTCPeerConnection接口负责维护每一个端到端连接的完整生命周期：

• 管理穿越NAT的完整ICE工作流；
• 发送自动（STUN）持久化信号；
• 跟踪本地流；
• 跟踪远程流；
• 按需触发自动流协商；
• 提供必要的API，以生成连接提议，接收应答，允许查询连接的当前状态等。

RTCPeerConnection把所有连接设置、管理和状态都封装在一个接口中。

DataChannel API用于实现端到端之间的任意应用数据交换，类似于WebSocket，但却是端到端交换。而且，底层传输机制的属性也是可定制的。每个DataChannel可以经过配置提供以下特性：

• 发送消息可靠或部分可靠的交付；
• 发送消息有序或乱序交付。

不可靠的乱序交付等同于原始UDP，即消息可能到达，也可能不到达，而且到达次序也没有保证。然而可让信道部分可靠，也就是设定重传的最大次数或时间限制：WebRTC的各个层负责处理确认和超时。

建立端到端的连接

打开XHR、EventSource或新WebSocket会话很简单ÿ