WebRTC 教程系列2（WebRTC API功能和特性）

来源：Engineering Semester
内容整理：李昊勇
公众号：煤矿工厂

WebRTC API

getUserMedia

首先介绍了webrtc api——getUserMedia，这是一个提供到多媒体流的 API。比如希望存储音视频数据就可以使用 MediaStreamRecorder API。getUserMedia()是一个无论对于开发者还是用户都十分方便的 API：开发者可以仅使用一个函数来获取音视频源数据，而用户也不需要安装其他软件或库。这个 API 只有一个方法，就是 getUserMedia()，从属于 window.navigator.object。

getUserMedia 结构

webrtc api——getUserMedia 方法会提示用户是否有使用一个多媒体的权限，其输入参数是音频或视频的参数，这些参数都是 bool 类型的，你可以根据你的需求选择这些参数，如是否请求一个音视频流。此外还可以添加额外的限定，如分辨率，视频的宽高度等。

错误/异常处理‘’

接着讲者展示了一些 getUserMedia 可能返回的错误及异常处理：

WebRTC API：RTCPeerConnection

RTCPeerConnection 代表了两台计算机之间的端到端连接，它提供了连接到一个远程对端的方式，控制和断开连接的方法。这个 API 是 WebRTC 连接的核心部分，负责了整个端到端连接的生命周期。

RTCPeerConnection 结构

在 WebRTC 中可以使用 RTCPeerConnection()构造函数，来获取一个端到端间最新建立的 RTC 连接。这个 API 接收一个 RTCConfiguration 类为输入参数，并定义了这个端到端连接应如何建立，以及其应使用的 ICE 服务器。

RTCPeerConnection 功能

它会跟踪本地和远程连接流；
它会管理 NAT 穿透的 ICE 工作流；
它会根据需求自动触发流的重新协商；
它会在流之间发送自动的心跳包；
它会为其他 API 提供连接请求，接收答复等。

RTCPeerConnection 概览

接着讲者展示了 RTCPeerConnection 的具体模式：

Session Description Protocal（SDP）

要建立端到端连接，就必须知道对方的公网 IP 地址。假设有以下情况：

两端都在同一网络下，可以直接连接；
两端各在一个子网下，且可能还有防火墙，对于 WebRTC 无法直接建立连接；
一端可能下线、忙碌、或者无意与其他用户初始化连接。

WebRTC 自带的 ICE 协议可以解决必需的路由和连接检查，剩下的问题可以由信令服务器解决。为了使用信令服务器，用户首先需要在同一个信令服务器下，并通过信令服务器来交换其他用户的连接信息。信令服务器通过 SDP 服务来获取用户信息。

SDP 是一种单纯的基于文本的协议，传递一种会话文件：连接的各种属性的列表，如媒体类型、网络参数、编解码器、带宽信息等。WebRTC 提供一个 createOffer()方法来为会话产生 SDP 描述，但是 WebRTC 内部实际上不会直接处理 SDP，它的 JavaScript Session Establishment 会处理所有 SDP 过程的内部工作。SDP 请求产生结束后，会通过信令服务器被发送到远程对端。产生的 offer 称之为会话的 “local description”，对于接收到的 SDP 答复，称之为会话的 “remote description”。

SDP 方法

讲者展示了之前提到的四个最主要的处理 SDP 的函数：

SDP 流程

讲者展示了一张 SDP 流程图：

Interactive Connectivity Establishment (ICE)

端到端连接

由于多层的防火墙和 NAT 设备，用户之间的端到端连接有可能十分困难。假设两个用户各处在一个独立的子网下，WebRTC 框架就可以解决这种情况下的连接问题。RTCPeerConnection 类包含一个 ICE Agent，ICE Agent 可以获取到本地 IP 和端口，并可以完成两端之间的连接性检查，此外还可以保持连接存活。

ICE 工作模式

在确认了会话描述后，ICE 就会开始自动寻找所有可用 IP 地址和端口。首先他会向操作系统请求其公网 IP 地址，假如这一步失败了，ICE Agent 就会向它的 STUN 或者 TURN 服务器请求其公网 IP。如果一个新的节点（ip+port），ICE 就会自动通过 RTCPeerConnection 对其注册。整个 ICE 流程都是在后台自动完成的。在这个过程完成后，就能够找到端到端间路由路径。

Trickle ICE

Trickle ICE 是对于 ICE 协议的一个扩展，允许在端之间进行增性的寻找以及连接检查。RTC 不需要再等待 ICE 寻找过程结束，就可以通过信令服务器向另一端发送增性升级，这样的话另一端就不需要在连接的过程中等待。这样的话两端就可以在没有 ICE 的情况下交换 SDP 请求。尽管 Trickle ICE 会在信令服务器上产生更多的网络流量，但是可以帮助在端到端连接初始化时减小很多时间。简而言之，就是 WebRTC 先发送 SDP 请求，然后一旦有成员被发现就开始 trckle ICE。

在 WebRTC 连接中，没有任何保证连接建立后就能一直保持此状态，这个连接很有可能周期性的断开，这时 ICE Agent 就会尝试找到最优路径来重新建立这个连接。，时长04:05

WebRTC Leak

WebRTC 提供了非常方便好用的在浏览器的实时视频通信系统，但是仍需要考虑线上隐私问题。

WebRTC Leak 指的是：你的公网 ip 地址被你浏览器的 WebRTC 功能所泄露出去。当你使用虚拟专用网(Virtual Private Network:VPN)时，你的 IP 地址还是安全的，但是当你使用了 WebRTC 后，WebRTC 就能通过 STUN/TURN 服务器获得到你的公网 IP 地址。

如何检查 WebRTC Leak

首先使用你的 VPN 并连接到一个服务器，再检查你的公网 IP 地址是什么。然后在 google 中搜索你的 ip 地址，如果搜索到的结果和你本地显示的一样，说明 WebRTC 把你的公网 IP 地址泄露了。

如何避免 WebRTC Leak

目前的唯一方法就是把浏览器的 WebRTC 功能关闭。如果你使用的是火狐浏览器，你就可以在 url 中输入about:config，并将media.peerconnection.enabled一值设置为 false。如果你使用的是 Chrome 浏览器，则需要安装uBlock Origin Chrome扩展来关闭 WebRTC 功能。