WebRTC

本文参考 High Performance Browser Networking，获取更多详细内容请查看原文。

WebRTC与实时通信的崛起

网络实时通信（WebRTC）是一套标准、协议和JavaScript API的组合，使得浏览器能够实现点对点的音频、视频及数据传输。WebRTC的出现使得传统的依赖于第三方插件的实时交互方式得以被淘汰，它为开发者提供了无缝集成的机会。

为了实现流畅的音视频会议以及数据共享，浏览器内需实现许多新特性，如音频和视频处理能力、应用程序接口（API）以及对新网络协议的支持。为了简化开发，WebRTC将大部分复杂性封装在三个主要的API中：

MediaStream：用于捕获和处理音频视频数据流
RTCPeerConnection：负责音视频数据间的通信
RTCDataChannel：用于传输任意应用数据

凭借仅需少量JavaScript代码，开发者便可打造出强大的实时通信平台，而这些API只是整体架构的一部分：在信令、连接协商、安全性及新协议层面，组合开发平台还需要其他许多组件。

既然如此，支持WebRTC的架构及协议特点也决定了其性能体现：例如连接建立延迟、协议开销及交付语义等。WebRTC不同于其他浏览器通信的地方在于它通过UDP传输数据，然而，仅依赖UDP远远不够。接下来，让我们一同深入了解它的设计驱动力。

WebRTC的标准与未来展望

实现浏览器中的实时通信是非常有挑战性的任务之一，自Web平台推出以来，这一功能的引入意味着浏览器网络层亟待升级，并伴随着全新的媒体栈——这对实现高效音视频处理至关重要。

WebRTC架构不仅包括超过12项不同的标准，它还涵盖了应用程序及浏览器API，以及实现其正常操作所需的各种协议及数据格式：

WEBRTC W3C工作组：负责定义相关浏览器API。
RTCWEB IETF工作组：负责建立所需的协议、数据格式及安全性。

重要的是，WebRTC设计不仅限于浏览器之间的实时通信，它也令现有通信系统得以整合，包括但不限于语音超IP（VoIP）、各种SIP应用及公共交换电话网络（PSTN）等，提供了可能的应用。

简而言之，WebRTC为网络领域注入了新的活力，资助了一个高达4.7万亿美元的电信行业。因而，原理的复杂性严谨而引人入胜，许多电信运营商与企业开始体会到这一变革所蕴藏的巨大价值。

音视频引擎的核心技术

为了提供高质量的电话会议体验，浏览器必须直接访问底层硬件，从而无需第三方插件。原始的音视频流还需经处理以提升音效、保证流畅度，并适应不断变化的带宽和延迟。

比如在接收端，客户端需实时解码流，适应网络条件的变化并解决延迟问题。简言之，音视频捕获与处理绝非易事，但WebRTC为浏览器提供了一个高效的音视频引擎（[IMAGE_MARKER_1]），能够承担相关职责，帮助开发者简化实现。

引擎在接入音频流后会自动进行降噪和回声抑制，同时根据相应编解码器实时进行编码，使其输出能适应当前的网络状态。伴随着所有技术细节的处理，浏览器再将优化后的媒体流输送至本地接口或为其对等点而准备输出。

利用getUserMedia API获取流

Media Capture and Streams W3C规范创建了一系列新的JavaScript API，允许开发者从平台请求音频和视频流，以及处理这些流。MediaStream对象（[IMAGE_MARKER_2]）则是启用这一功能的核心接口。

MediaStream对象封装了一个或多个媒体轨道（MediaStreamTrack），并确保各轨道之间的同步。这些输入源可能是物理设备如麦克风，或者是来自存储设备或网络点对点的文件。这些音视频流最终会通过该接口传输至本地或远程接收器。

通过使用getUserMedia API，开发者可以请求音视频轨道，同时可以设置必须和可选的约束条件以适配应用需求：

var constraints = {
   audio: true,
   video: {
       mandatory: {
           minWidth: 320,
           minHeight: 180
       },
       optional: [
           { maxWidth: 1280 },
           { frameRate: 30 },
           { facingMode: "user" }
       ]
   }
};
navigator.getUserMedia(constraints, getStream, logError);

这段代码请求了一系列音视频参数，也展示了如何使用API处理所需的MediaStream流。

实时传输的挑战

实时通信极为依赖时间敏感性，音视频应用程序设计需容忍间歇性丢包现象，通常，编解码器可合理处理小规模空白，而对任何应用传输数据的丢失或延迟则需开发者实现自有恢复逻辑。时间要义与低延迟更是关键。

音视频传输不仅仅是程序上传输数据，还涉及对我们大脑解读信息的独特方式。因此，UDP协议成为实时数据传输的首选。虽然TCP能够确保数据传输的可靠性、顺序性，但在现实中，UDP能提供更好时效性和灵活的传输方案。

为了实现点对点之间的真实数据传输，WebRTC采用了UDP，而如何穿越NAT和防火墙等网络障碍，协商连接参数且保障数据安全，则是当下的热点话题。

至此，UDP为WebRTC的实时化交流建立了基础，但进一步的协议与服务添加亦不可或缺（[IMAGE_MARKER_3]）。

RTCPeerConnection API的职责

尽管对等连接的建立需利用多项协议，但应用程序提供的 API 设计则相对简单明了。RTCPeerConnection接口（[IMAGE_MARKER_4]）全面管理每一个点对点连接中的生命周期。

该接口负责以下几个方面：

管理ICE工作流程
发送与接收ICE保持连接
跟踪本地与远程流
触发流重新协商

概括来说，RTCPeerConnection封装了连接的配置、管理与状态，确保开发者能专注于实现实时应用的业务逻辑。

实现对等连接

启动一个对等连接的工作量远不止一般的XHR或新的WebSocket会话，这些仅作为客户端到服务器的沟通方式。相较之下，WebRTC面临的挑战在于对等点多处于不同的NAT后，彼此互通并不简单。

要打开连接，需要解决以下几个问题：

首先，通知对方希望开启连接。
其次，识别连接的可用路径并传递该信息。
再者，交换音视频和数据流参数。

值得一提的是，WebRTC通过ICE协议为开发者处理了大部分复杂性，信令和会话协商工作则交由应用程序来实现。

信令与会话协商

在进行连接检查前，各对等方必须确认彼此可达，而互相的报价和应答则为此服务。在这当中，创建一个信令通道尤其重要，WebRTC对此并没有规定具体的实现方式：

如使用常见的信令协议SIP、XMPP或者其他的自定义协议；通用性促进了不同通信基础设施之间的良好整合。

通过信令服务器完成远程对等点的连接协商后，双方能够交换流必要的信息及参数。接下来便是SDP的使用。

会话描述协议（SDP）的应用

SDP的主要功能在于描述对等连接的各项参数，而非直接传输媒体。它涵盖了使用者所需的媒体类型、网络传输协议以及使用的编码设置。在通过信令通道发送SDP报价与答案后，双方便可打开连接。

例如，在接收到一方的SDP报价并在本地存储后，另一方便能注册本地流、生成SDP答案，并将其传回给报价的一方。这样双方便协商高清音频、视频流及其它数据的一致性。

交互式连通建立方式（ICE）

为确保能够相互传递数据包，ICE协议发挥着至关重要的作用。首先，ICE代理需要查询本地及公共IP，并执行连接检查。ICE代理会向操作系统请求本地IP地址并寻找STUN服务器，确保能顺利找到对方的端口。

一旦发现了诸多候选IP地址，ICE代理便会将其注册到RTCPeerConnection中，并向应用程序反馈。成功后，ICE代理会开始连接认证，确认双方的数据传递情况，进而保障稳定的实时交流。

结合一切

我们从信令业务到SDP数据传输，ICE协议为双方建立起可靠的通信机制，接下来便是开始和管理实时数据流的准备。

WebRTC在设计上使所有参与者能够快速便捷地激活连接，然而在实际执行过程中维持性能同时还有诸多挑战。最终，这一模块的合理设计为用户提供了享受高效、透明和灵活的对等通信环境的基础。