WebRTC 中的 ICE：服务器设置和相对性能

admin 音视频 暂无评论 1,365 浏览

专用 WebRTC 端点通常通过从源到目的地进行映射的网络与公共互联网隔离开来。映射有助于进出私有系统的流量到达正确的主机。此过程称为网络地址转换或 NAT。

虽然不一定是限制性的，但这些接口需要被针孔化以创建公私对，以便媒体流从外部世界流入 WebRTC 浏览器。如RFC 8445中所定义，这种收集候选者并确定其优先级以便与远程对等方成功建立媒体连接的过程称为交互式连接建立或 ICE。

对于不在同一网络上的各方之间的呼叫，很大一部分 WebRTC 呼叫都有网络限制。这包括来自具有对称公私配对 (NAT) 的对等方的呼叫，或来自具有额外防火墙限制的网络（例如在大学或办公空间中）的呼叫。这些可能面临黑屏问题（丢失馈送/无数据包接收）或在 ICE 收集阶段失败导致无连接。这种情况可以受益于两个主要协议：

  1. STUN (Session Traversal Utilities for NAT)用于 IP 发现以获取外部网络地址。
  2. TURN（Traversal Using Relays around NAT）用于通过它中继媒体来中继对等点之间的流量。这是绕过限制性防火墙的有效方法。
    • UDP：首选 
    • TCP：不太受欢迎，因为保证数据包的有序交付意味着开销

此外，还有 TURN over TLS：

  1. TURNS（使用围绕 NAT 的中继的安全遍历）用于通过 TURN 服务器在 TCP/TLS 连接上中继媒体。它通过 TLS 套接字绕过极其严格的防火墙规则。

这篇文章描述了在没有 ICE 服务器、公共 STUN 服务器和自托管 CoTURN 服务器的情况下的相对性能。实验通过多个限制性网络防火墙、公共互联网连接、宽带以及 4G 数据连接进行。观察结果在每一节的末尾注明。

没有 ICE 服务器：阻塞网络无法建立媒体连接

如果对等点具有阻止防火墙策略并且无法建立互连性，则媒体流将无法从本地到达远程，反之亦然，从而导致无连接或黑色远程视频。

图中描绘了在不使用 ICE 服务器时被阻止的媒体流量导致通过防火墙的 WebRTC 媒体会话失败。
ICE 收集失败的屏幕截图，因为 WebRTC 客户端无法收集候选人以在没有 STUN 或 TURN 的情况下建立对等媒体连接。 

成功的 ICE 候选配对：

ICE connection state: new => checking => connected
Connection state: new => connecting => connected
Signaling state: new => have-local-offer => stable
ICE Candidate pair: 66.194.72.49:15695 <=> 129.203.xxx.xxx:28043

不成功的 ICE 候选配对：

ICE connection state: new => checking => disconnected
Connection state: new => connecting => failed
Signaling state: new => have-local-offer => stable
ICE Candidate pair: (not connected)

ICE 术语

  • Trickle ICE：如果端点位于同一网络中，则加强连接设置。如果 TURN 服务器响应 ICE 请求，请从此回购中检查。
  • ICE 候选人类型 
    • Host：直接从本地网络适配器收集，候选主机是 LAN 上计算机的内部 IP 地址和端口。它们只能在同一子网上的对等点之间路由。
    • Srflx：服务器自反候选者，它是由 STUN 服务器分配的中间地址。
    • Prflx : peer reflexive candidate 与 srflx 相似，但是通常在连接建立后由 peer 直接收集（例如，如果现有连接失败）
    • 中继：TURN 服务器用于在对等方之间转发媒体的 IP 地址。
  • NAT（网络地址转换）将公共 IP 转换为本地网络中具有内部 IP 的私有系统。诸如路由器之类的代理促进了这种映射。广泛的 NAT 是类型
    • 对称 NAT： NAT 映射和 L4 是 1:1 的关系，即一个连接对于任何唯一的套接字组合（协议、本地 IP 和端口、目标 IP 和端口）都是唯一的
    • 非对称NAT：一个协议、本地IP、端口与不同目的IP和端口的连接。 

STUN：在保护较少的网络中成功连接，但不适用于大多数企业防火墙和网络策略

一些 ICE 候选人使用谷歌提供的 STUN 服务器收集。

这些适用于简单的 NATing 场景，其中私有 IP 链接到网络中的公共 IP，例如电信提供的网络 (4G) 或大多数 Wifi 网络。但是，当存在防火墙限制时，它就无法正常工作。下面重点介绍一个这样的案例：

图描绘了当防火墙受到限制并且 STUN 提供的 IP 地址无法进行 WebRTC 媒体会话时被阻止的媒体流量。

此设置的配置是非 SIP，仅使用 Google 提供的 STUN 服务器。

 

https://<ip>:8081/index.html#34900, { iceServers: [stun:stun.l.google.com:19302], iceTransportPolicy: all, bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: "unified-plan", extmapAllowMixed: true }

下面分享了 WebRTC 内部的一个用例，其中 WebRTC 客户端无法收集到足够的候选人来建立对等媒体连接：

ICE 收集失败的屏幕截图。尽管有 STUN，WebRTC 客户端仍无法收集到足够的候选人来建立对等媒体连接。

自托管 TURN 服务器，CoTURN

STUN 在不直接影响媒体流的情况下尽最大努力执行网络发现和打孔以连接本地和远程，并在连接建立后退出画面。相反，TURN 服务器在建立连接后仍保留在媒体路径中，通过自身中继媒体数据包。

CoTURN 是一个开源的 STUN 和 TURN 支持的 ICE 服务器。它是由开发者社区贡献的。它符合 RFC 标准，经常被 VoIP 集成商用于他们的实时通信解决方案。 

图中描绘了在存在限制性防火墙的情况下通过 TURN 中继的 WebRTC 媒体流量。

CoTURN 设置

以下是安装 CoTURN 及其在非 SIP 通信客户端中的使用的快速概述：https://webrtc.ventures/2017/08/quick-guide-stunturn-webrtc/。CoTURN 服务运行后，我们需要在 JavaScript WebRTC 网页中添加以下内容：

iceServers: [
{ 'url': 'stun: <username>@<serverip>: <port>'},
{ 'url': 'turn: <username>@<serverip>: <port>', 'credential': '<password>'}]
使用 CoTURN 服务器成功连接网络的屏幕截图。 

从下载的 WebRTC 内部转储文件并使用https://fippo.github.io/webrtc-dump-importer/提供的工具，我们可以对 WebRTC 会话进行后期分析： 

通过自托管 CoTURN 显示 UDP TCP ICE 的屏幕截图和注释。

通过观察迹线的突出显示部分，确保 ICE Candidate 是一对活跃的。例如，在轨迹中，活动对以粗体突出显示：

CoTURN 性能 

TURN 基于中继的 ICE 候选者的优先级通常低于 STUN 的反射性候选者。在没有防火墙限制的情况下，本研究的 QoS 指标显示了本地连接（即在同一区域和网络内）的无可比拟的性能。然而，TURN 在远距离（即跨大陆的 WebRTC 对等点）上的表现明显优于 STUN。对于防火墙，TURN 是克服网络限制和建立点对点流的最佳证明和广泛使用的方法。

屏幕截图显示通过 TURN 服务器的媒体流。 
ICE候选：Local udp prflx，Remote udp relay 

本地对等反射候选和远程中继候选的性能

CoTURN 建立的媒体会话的比特率性能截图。
CoTURN 已建立媒体会话的数据包发送和接收性能的屏幕截图。
CoTURN 建立的媒体会话的 QoS 属性的屏幕截图。

相关博文

WebRTC 中的 ICE：服务器设置和相对性能
赏
标签: