连接过程简析

WebRTC 连接过程简析

WebRTC 连接时序图

要连接两个浏览器,Web RTC 需要执行五个步骤来建立 P2P 连接。

  • 信号处理,以去除音频或视频中的环境噪声。
  • 编解码器处理,以压缩和解压音频或视频。
  • 通过防火墙、(NAT)和中继器建立从一个 Peer 到另一个 Peer 的路由,以创建一个 ICE(交互式链接建立)。
  • 用户数据在进行连接传输前都会进行加密。
  • 管理带宽,给每个 Peer 的带宽不同

信号传递

浏览器中的 P2P 连接由服务器建立,以确保所有 Peer 同意建立会话。Peer 之间共享会话密钥、错误信息、媒体元数据、编解码器、带宽、公共 IP 地址和端口等信息以创建连接。服务器向两个 Peer 发出信号,以确定使用什么媒体格式以及每个 Peer 要向对方发送什么。

与信令服务器通信

网络地址转换(NAT)和 ICE

NATs 将家庭路由器等设备上的私有 IP 地址转换为公网 IP 地址。防火墙和 NATs 通过阻止特定的协议或端口来减慢这一过程。WebRTC 使用的解决方案是 ICE 框架。ICE 通过并行尝试所有连接并选择最有效的路径,在互联网上建立 P2P 连接。有两种类型的连接可选 STUN & TURN

STUN 服务器

它首先连接到 STUN(Session Traversal Utilities for NAT)服务器,获得直接连接。STUN 服务器为请求者提供了公网 IP 地址,以便与他人进行通信。其目的是帮助请求者回答 “我的 IP 地址是啥 “这个问题。

STUN 服务器如何工作

要建立与其他 Peer 的连接,需要终端知道自己的公网 IP 才能与他人共享:当一个 Peer(Calvin)在 NAT/防火墙后面时,它只能识别它的私有 IP 地址,而另一个 Peer(Elana)由于防火墙的安全性,无法连接到本地 IP。这个 Peer 会向 STUN 服务器请求,获取它的公网 IP 地址和一种可用 NAT 类型。另一个 Peer(Elana)可以使用 STUN 服务器给定的公网 IP 地址尝试进行连接。如果成功,数据将通过点对点网络传输,而不需要第三方或其他服务器。为了安全起见,所有 STUN 服务器将被丢弃并等待下一次查询。

但是,上述情况有时可能会失败,IP 地址和端口会发生变化。这种情况称为 “对称 NAT”,STUN 服务器的公网 IP 地址没有足够的能力在这里建立连接,因为端口也需要转换。有些路由器使用对称 NAT,是为了使终端设备更加安全,或者说避免很多陌生人连到你的设备上。对称 NAT 不仅可以将 IP 地址从私有地址转换成公共地址,还可以转换端口。换句话说,路由器只会接受用户已经有过的连接。因此,另一种确保两个 Peer 之间连接的解决方案是通过 TURN 服务器。

作为一种协议,STUN 具有超快、轻量的特点。它可以在很短的时间内将数据直接传送给对方。STUN 有利于加快连接速度,更快地获取结果。当用户使用 LAN 局域网传输数据时,场景类似,比使用 Wi-Fi 传输更快。最重要的是,可以直接在两个 Peer 之间传输数据。

TURN 服务器

TURN(Traversal Using Relays around NAT)服务器作为中继服务器,以防 P2P 连接中断。当 STUN 服务器用于建立连接时,TURN 服务器在整个连接过程中保持活跃。TURN 服务器在 WebRTC Peer 之间不断中继数据。这就是为什么用 “中继 “一词来定义 TURN。

TURN 服务器工作原理

这个中继服务器是在 STUN 服务器出现故障时用来中继流量的,同时也具有 STUN 的功能。TURN 服务器是一个内置传输功能的 STUN 服务器。更具体地说,TURN 是用来中继 Peer 之间的音视频/数据流,而不是信令数据。按照上文 STUN 服务器的步骤运行,如果 STUN 失败,终端用户会与 TURN 服务器建立连接,通知所有 Peer 向服务器发送数据,服务器负责向第一个终端用户传输数据。为什么总是先使用 STUN 服务器,主要原因是 TURN 服务器成本太高,如果在线传输高清视频的话,会消耗大量带宽。

VP9 视频编解码器

为什么很多人开始使用 WebRTC,其中一个主要原因就是因为视频。随着视频直播越来越成为主流,视频质量的要求也越来越高,这就要求数据传输的速度要快,或者数据包的大小要小,才能方便传输速度高。VP9 视频编解码器用于对音频或视频进行压缩和解压。音视频数据压缩后大大减小体积,因此 VP9 可以帮助流媒体视频更快传输。Safari 12.1(通过支持 VP8)可以与其他 Peer 进行在线实时视频。

VP9 与 VP8 对比

VP9 是在 VP8 的基础上改进而来的,是谷歌旗下的由 On2 科技公司创建的视频压缩格式。主要功能是隐藏丢包和清理嘈杂的图像,以及多平台的采集和播放功能。通过 VP9,用户可以使用 WebRTC 传输 720p 视频,而不会出现丢包或延迟。同时,它还可以在同样的带宽下支持 1080p 视频通话,并帮助优化连接和数据使用,避免带宽成本过于高昂。

APIs

有三个主要的 Javascript API 可以处理音频捕获、视频会议和数据传输。

MediaStream

使用用户的摄像头和麦克风来获取和传输音频和视频。使用这个 API 可以让你获得麦克风和网络摄像头等设备的访问权限。当开发人员将 WebRTC 集成到他们的网站中时,他们可以对他们想要的音频和视频流的参数进行设置,比如帧率、视频帧的大小、分辨率等。

这个 API 是作为 HTML 5 的一部分提供的,而其他两个 API 是专门为 WebRTC 提供的。

RTCPeerConnection

将采集到的音视频流实时发送至另一个 WebRTC Peer。使用该 API,用户可以将 getUserMedia 捕获的音频和视频传输给其他 Peer。

该 API 具有连接到远程 Peer,维护和监控连接,并在完成后关闭连接等功能。

RTCDataChannel

传输任意数据。每个数据通道都与一个 RTCPeerConnection 相关联。内置安全(DTLS)和拥塞控制。

安全

在实时通信的数据传输过程中可能会产生很多安全风险。因此,加密是 WebRTC 的强制性功能,并在所有组件上强制执行。WebRTC 使用两种标准加密协议。确保 2 个 Peer 之间连接安全的步骤:

  • 启动信令过程在两个 Peer 之间交换元数据。
  • 执行 ICE 检查,ICE 在双方之间建立通道。
  • 进行 DTLS 握手。如果有多媒体传输,SRTP 使用 DTLS 握手步骤中导出的密钥。
  • 所有 Peer 都有安全通道。
  • Peer 之间交换密钥。

数据报传输层安全协议(DTLS)

一种建立在浏览器中的标准化协议。它用于加密数据流。它基于传输层协议(TLP)。保留了传输语义,DTLS 使用用户数据协议(UDP)。它是安全套接字层(SSL)的扩展;任何 SSL 协议都可以用来保护 WebRTC 数据的安全,允许端到端加密。

安全实时传输协议(SRTP)

用于加密媒体流。它是实时传输协议(RTP)的扩展,RTP 没有任何内置的安全机制。在 RTP 的基础上增加了保护、完整性检查和消息认证。缺点是 虽然它为 RTP 数据包提供了加密,但它并没有对报头进行加密。

上一页