WebRTC速成课程

WebRTC速成课程

目录

1. WebRTC 概述

2. WebRTC 揭秘

2.3 Traversal Using Relays around NAT: TURN

2.4 Interactive Connectivity Establishment: ICE

2.5 Session Description Protocol: SDP

2.6 信令交换：Signaling

工作流程总结

3. Demo

4. WebRTC的优缺点

1. 优点

2. 缺点

5. 扩展内容

5.3 自定义 TURN 和 STUN 服务器

5.4 公共 STUN 服务器

WebRTC 概述

WebRTC 揭秘：NAT、STUN、TURN、ICE、SDP、信令

Demo

WebRTC的优缺点

扩展内容

1. WebRTC 概述

首先想到的问题是我们为何要建立 WebRTC？

建立它的理由是人们需要用一种标准的、低延迟的方式来传递媒体数据（视频&音频）。所谓“标准的”意味着我们需要简单易使用的 API；而所谓“低延迟的”意味着需要一种合适的协议，UDP 显然是一个好的选择，因为 UDP 没有过多的应答过程（Acknowledgment）。但我们需要的协议要比 UDP 更好，要能支持 P2P 的通信。因为一旦依赖服务器来传递内容就会因为反向代理或者穿透引入额外的延迟，用户需要进行终止、观察、处理、转化流等操作，这些都会造成额外消耗。对于视频传输、特别是直播、会话等场景，用户希望内容到达得越快越好，所以 P2P 是最快的路径。

那么在 WebRTC 中究竟发生了哪些事呢？

举个例子，A 想要与 B 进行通信，但 A 与 B 之间“互不相识”。所以 A 首先需要找到所有 Public（不是 B）能连接到它的途径，检查 A 是否有一个公共 IP 能被 Public 识别或使用，如果没有检查 A 的路由器是否允许公开端口转发规则、是否在路由上有公共代表等等。B 也做了以上同样的事。

此外，A 和 B 还会收集自身所支持的加密方式、安全参数、视频编解码器等等大量的信息，注意这些信息还没有被送到对端，在这个阶段只是广泛地收集。所有这些信息，构成了“SDP”。

接下来，A 和 B 会通过其他方式（可以是 WhatsApp、QR、Tweet、WebSockets、HTTP Fetch…）发出会话信息，这种方式具体是什么 WebRTC 并不关心，只要能从 A 到 B（B 到 A）就可以。

这种工作方式表面上是有些“愚蠢的”，部分人可能会认为“既然我已经有了 A 和 B 之间通信的线路，那还要 WebRTC 做什么呢？”但认真思考一下就可以发现，WebRTC 只要首次通信双方交换了 SDP，后面就会实现真正的 P2P 通信，不再需要 WhatsApp、QR 等等中间途径，不会有比这更快的通信路径。因此最终 A 通过最优路径连接到了 B，这就是 WebRTC 的工作流程。

更详细的阐释这个例子如下：

如上图所示，假设 A 找到了 A1、A2、A3 三种方式可以访问它，同时还找到了安全参数、媒体选项等信息。同时，B 也做了一样的工作。接下来，他们通过一些方式（例如 WhatsApp）交换了以上信息。然后 A 找到 B2 是可用的最佳路径，而 B 也发现 A1 是可用的最佳路径，那么二者将通过这条路径直接连接彼此。本质上 WebRTC 就是这样工作的。

2. WebRTC 揭秘

接下来我们对 WebRTC 进行深入理解，对细节内容进行讲述。首先了解 NAT 的细节，学习 WebRTC 是如何进行正确的网络地址转换；其次了解为什么我们需要 STUN 和 TURN；此外还会介绍 ICE、SDP 以及信令交换的相关内容。

2.1 Network Address Translation: NAT

如果你有一个公开的 Public IP 地址，连接过程将不会有什么问题。因为你会像 Web 服务器一样一直监听端口，把端口和 IP 都提供给对方后，你和它就可以直接进行连接了。但在大多数情况下，用户都是隐藏在公共网络之后的，无法直接连接。如下图所示的示例中，路由器有一个 Public IP 5.5.5.5，也有一个 Private IP 10.0.0.1（也被称为 gateway），你的机器只有一个 Private IP 10.0.0.2，但你想要访问 IP 为 4.4.4.4:80 的机器，要如何实现呢？

在这之后，服务器 4.4.4.4:80 将向你的机器发送回复，工作原理和上述相同，根据 NAT 表查询对应地址完成通信。

一对一 NAT（完全圆锥型 NAT）：One to One NAT（Full-cone NAT）路由器上要发送到外部 IP:port 的数据包总是可以映射到内部 IP:port ，无一例外。举例说明，所有发送到 5.5.5.5:3333 的数据包总是会被自动转发到 10.0.0.2:8992，无论这个包是来自 4.4.4.4:80 或者其他任何地址。

IP 受限型 NAT：Address restricted NAT出于安全考虑，部分路由器会地址限制，考虑之前是否与该地址进行过通信。即路由器上要发送到外部 IP:port 的数据包可以映射到内部 IP:port，前提是数据包的源地址与 NAT 表相符，无所谓端口是什么。举例说明，发送到 5.5.5.5:3333 的数据包中，只有源 IP 是 4.4.4.4 或其他表中有过记录的 IP 才会被自动转发到 10.0.0.2:8992，即使这个 IP 之前并不是和 3333 端口进行的通信。

端口受限型 NAT：Port restricted NAT与前者相比，增加了端口限制，即路由器上要发送到外部 IP:port 的数据包可以映射到内部 IP:port，前提是数据包的源 IP 和 Port 都要与 NAT 表相符。举例说明，发送到 5.5.5.5:3333 的数据包中，只有来自 4.4.4.4:80 或其他表中有过记录的 IP:Port 才会被自动转发到 10.0.0.2:8992，即使这个 IP:Port 之前并不是和 3333 端口进行的通信。

对称 NAT：Symmetric NAT该方式是限制最多的一种，即必须匹配完整的 IP:port，区别在于发送到 5.5.5.5:3333 的数据包中，只有来自 4.4.4.4:80 的才会被自动转发到 10.0.0.2:8992，其他的包均无法通过。这种方式无法在 WebRTC 中使用，因为 WebRTC 需要 STUN 服务器。一旦 STUN 服务器建立了一个 Public 代表，Symmetric NAT 要求只能与一个特定的对端通信，这种限制不适合 WebRTC。

2.2 Session Traversal Utilities for NAT：STUN

STUN 是可以赋予一个应用程序所需要的 Public IP 和 Port，适用于 Full-cone、Address restricted 和 Port restricted NAT，无法用于 Symmetric NAT。STUN 服务器通常在 3478 端口上运行，TLS 端口为 5349。STUN 是非常轻量级的，用户可以使用 docker 建立一个 STUN 服务器。STUN 服务器的目的就是让用户找到自己的 Public 表示，并通过这个 Public 表示与其他用户进行通信。如果我们使用的是像大约 1996 年或 2000 年早期时那样的 Public IP 地址，通信也将非常简单。但就现在而言，我们必须使用 STUN 服务器。STUN 服务器的工作流程如下图所示：

首先创建一个数据包进行 STUN 请求，STUN 服务器的地址为 9.9.9.9:3478，同样在路由器创建了 NAT 表并进行了地址转换，然后数据包被送到了 STUN 服务器。

服务器收到请求后，为 10.0.0.2 的机器构建了一个 Public 表示 5.5.5.5:3333，并把这个信息打包进一个数据包进行反馈。

上述是一个 STUN 请求的详细过程，以下图为例 STUN 在整个通信过程中进行了以下工作：首先给予 10.0.0.2 的机器一个 Public 表示 5.5.5.5:3333，同时给予 192.168.1.2 的机器一个 Public 表示 7.7.7.7:4444。随后二者都使用获得的 Public 表示进行连接。

值得注意的是，这二者之前并没有进行过通信。如果是 Full-cone NAT，那么没有问题可以连接；如果是 Address restricted NAT，第一个请求连接的请求将会失败。在这种情况下，用户需要通过服务器建立至少一个通信请求，先让两个地址都能保存在两端的路由器中，这样再次通过 Public 表示进行连接请求时就能找到匹配的地址，继而可以完成连接。Port restricted NAT 工作原理与之类似。

2.3 Traversal Using Relays around NAT: TURN

在应用 Symmetric NAT 的情况下，必须使用 TURN。所有的通信内容都要经过 TURN 服务器的转发，所以 TURN 服务器的维护成本比较高，这也是为什么几乎没有人免费提供这种服务器供用户使用。下图是一个 TURN 服务器工作流程的示例，二者之间并不是直接的 P2P 通信，所有的信息都经过了 TURN 服务器进行转发。

2.4 Interactive Connectivity Establishment: ICE

在建立了很多 STUN 和 TURN 服务器后，从 A 到 B 之间的路径有了非常多的选择，为了更好的处理这些路径，人们提出了 ICE。ICE 会收集所有可用的通信路径作为“候选人”（ICE Candidates），有可能是本地 IP 地址、STUN 和 TURN 服务器提供的地址等等。收集到的所有地址都将放入 SDP 中，再送到对端，对端通过解析 SDP 来了解我方提供的重要信息。因此，ICE 是 WebRTC 中非常关键的组成部分。

2.5 Session Description Protocol: SDP

2.6 信令交换：Signaling

Signaling 过程是将用户产生的 SDP 通过某种方式传递给想要通信的那方，如上所述，以何种方式传递并不重要。很多人通过 Websockets 或者 socket io 来传递 SDP 信息，这个过程就是 Signal SDP。尽管要找到所有的 ICE candidate 是耗费时间的，但一旦完成了这个过程，下一步就是创建一个 SDP，进而生成一个 QR code 并把 QR code 公布到 twitter 上，其他人扫描了这个二维码就可以获取相应的 SDP。这个过程是通过 twitter、QR code、Whatsapp、WebSockets、还是 HTTP 请求都不重要，因为实际上就是将一个长字符串传递给其他人罢了。简而言之，Signaling 就是将 SDP 信息传递给另外一方。

工作流程总结

A 想要和B建立连接；

A 创建了一个 offer，它寻找所有的 ICE candidate、安全选项、音视频选项等并创建 SDP，简单来说这个 offer 就是 SDP；

A 将 SDP 信令传递给 B（Signaling）；

B 根据 A 的 offer 进行设置，并创建应答（answer）；

B 将 Answer 信令传递给 A（Signaling）；

连接建立。

3. Demo

在两个浏览器间进行通信（浏览器 A 和浏览器 B）；

A 创建一个 offer（SDP），并设置它为本地描述；

B 接收一个 offer 并设置它为远端描述；

B 创建一个 answer 并设置它为本地描述，并将其传递给 A；

A 接收 answer 并设置它为远端描述；

建立连接、建立数据通道、交换数据。

4. WebRTC的优缺点

1. 优点

P2P 通信是非常棒的，对于高带宽内容可以有降低的延迟。P2P 是最快的路径，不需要经过其他的第三方进行通信。即使通互联网传输要经过大量的路由器，但如果内容已经被加密了所有的路由器都不会查看内容，它们会直接传递数据包，所以 P2P 是非常好的通信方式。对于高带宽内容，它们通过 UDP 直接被“送入”和“推出”，通过 P2P UDP 传递这些内容（特别是视频内容），用户将收获最好的性能。

标准可用的 APIWebRTC 有一套非常标准、非常优雅的 API，可以直接在浏览器中应用，不需要安装其他的包、也不需要用多余的开发工具。

2. 缺点

5. 扩展内容

5.1 Media API

getUserMedia 函数可以用于获取麦克风和摄像头，进而获得一个流（stream），这个流的内容会通过RTCPConnection.addTrack(stream)送入 RTC 连接中。理论上你可以用数据通道传递任何类型的数据，但如果你想要传递媒体信息就要用到 stream，这些数据的传递将使用不同的协议。

5.2 onIceCandidate 和 addIceCandidate

这两个函数可用于在新的 Candidate 加入或离开时维护连接。用户每次从系统获取一个 ICE Candidate 时，onIceCandidate 函数就会被调用。onIceCandidate 函数将告知用户“在 SDP 已经被创建后，又有了新的 Candidate”。新的 Candidate 将被告知对端，告知的方式可以是 Signaling，也可以直接通过同一个 SDP 连接。对端通过 addIceCandidate 函数将新的 Candidate 加入 SDP。

5.3 自定义 TURN 和 STUN 服务器

在创建 RTCP 连接时，可以选择传递配置信息，下图为一个配置信息示例。基本上用户可以自定义 ICE 服务器，其中有很多可选项。

5.4 公共 STUN 服务器

stun1.l.google.com:19302

stun2.l.google.com:19302

stun3.l.google.com:19302

stun4.l.google.com:19302

stun.stunprotocol.org:3478

审核编辑 ：李倩

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。