本系列文章跳转目录如下：
- 是什么，为什么，如何使用
- 信令（交换信令消息后，WebRTC Agent才可以直接相互通信。）
- 连接（ 为什么WebRTC需要专用的子系统进行连接，又是怎样连接的？）
- 安全性（ WebRTC具有哪些安全性保障，又是如何做到的？）
- 搭建实时网络（网络在实时通信中的重要性以及如何处理网络中的各种问题）
- 媒体通信（WebRTC媒体通信的作用及其工作原理）
- 数据通信（WebRTC数据通信的作用及其工作原理）
- WebRTC应用场景（人们使用WebRTC构建什么以及他们是如何实现的）
- 调试（如何分析并定位相关问题，以及一些流行的调试工具）
- 历史（对WebRTC一系列协议作者的采访）
- 常见问题（ 使用WebRTC时常见的问题及解答）
- 术语
WebRTC应用场景
现在你已经知道WebRTC的工作原理，到了使用它的时候了！本章探讨人们使用WebRTC构建什么以及他们是如何实现的。你将学到基于WebRTC发生的所有有趣的事情。WebRTC的功能是有代价的。建立产品级的WebRTC服务相当有挑战性。本章将尝试解释这些挑战性的根源，这样你遇到问题时就能有所准备。
用例
许多人认为WebRTC只是一种在web浏览器中实现电话会议的技术。实际上，它能做的不仅如此！
WebRTC被广泛用于各种用例。新的用例一直在出现。在本章中，我们将列出一些常见的用例，并探讨一下WebRTC是如何对它们进行革新的。
电话会议
电话会议是WebRTC的原始用例。该协议包含浏览器中几个必要功能，这些功能没有其他协议提供支持。你可以使用WebSockets构建会议系统，在各种条件都满足的情况下，它可能可以工作。但如果你希望在现实世界的网络条件下部署一些服务，那么WebRTC是最佳选择。
WebRTC为媒体提供拥塞控制和自适应比特率。随着网络条件的变化，用户仍将获得最佳体验。开发人员不必编写任何其他代码来处理这些情况。
参与者可以发送和接收多个流。在呼叫过程中，他们还可以随时添加和删除这些流。编解码器也经过协商。所有这些功能都是由浏览器提供的，开发人员无需编写任何自定义代码。
数据通道也对电话会议有所助益。用户可以发送元数据或共享文档。如果更看重性能而不是可靠性，可以创建多个流并对其进行配置。
广播
许多使用WebRTC的新项目开始出现在广播领域中。协议为媒体的发布者和消费者都提供了很多支持。
浏览器中的WebRTC使得用户可以轻松发布视频。这样用户不需要下载新的客户端。
任何具有Web浏览器的平台都可以发布视频。发布者可以发送多个音轨/视频流，并可以随时对其进行修改或删除。传统协议中每个连接只允许一个音频或一个视频流，与之相比，这是一个巨大的改进。
WebRTC使开发人员可以更好地控制延迟和质量之间的权衡。如果不允许延迟超过特定阈值更重要，那么为此你可能愿意容忍对解码质量做一些让步。你也可以将播放器配置为在媒体到达时立即播放。如果是使用在TCP之上的其他协议，要完成这一点并不是那么容易。但在浏览器中，你只需要请求数据，就这么简单。
远程访问
远程访问是当你通过WebRTC访问远端的另一台计算机。你可以完全控制远程主机，也可以只控制一个应用程序。当本地硬件无法执行繁重的计算任务时，这非常有用。例如，运行新的视频游戏或CAD软件。WebRTC能够通过下面三种方式彻底改变对物理空间的需求。
WebRTC可用于远程访问那些无法直接路由的主机。使用NAT遍历，你可以访问仅通过STUN可用的计算机。这对于安全性和隐私性非常有用。你的用户不必通过中转或所谓"跳转盒"来路由视频。NAT遍历还使得部署更加容易。你不必担心端口转发问题或提前设置静态IP。
在这种场景下，数据通道也非常强大。可以对它们进行配置，以便仅接受最新数据。使用TCP运行时，可能会遇到队头阻塞的风险。旧式的鼠标点击或按键可能会迟到，并阻止后续的鼠标被接受。
WebRTC的数据通道的设计可以处理此问题，并且可以配置为不重试丢失的数据包。你还可以测量背压，并确保你不会发送更多的数据以至于网络无法支持。
浏览器中提供的WebRTC极大地改善了生活质量。你无需下载专有客户端即可开始会话。捆绑了WebRTC的客户端越来越多，智能电视现在也开始拥有了完整的Web浏览器。
文件共享和审查制度
文件共享和审查规避是截然不同的问题。然而，WebRTC同时解决了他们两者的相同问题。它使得文件既容易获得又更难以阻止。
WebRTC解决的第一个问题是客户端的获取。如果要加入文件共享网络，需要下载客户端。即使网络是分布式的，你仍然需要首先获得客户端。在受限制的网络中，下载通常会被阻止。即使你可以下载它，用户也可能无法安装和运行客户端。而WebRTC在每个Web浏览器中都可用，这点使得它无处不在。
WebRTC解决的第二个问题是流量被阻止的情况。如果你使用的协议仅用于文件共享或审查制度，那么阻止它会容易得多。由于WebRTC是通用协议，阻止它将影响所有人。阻止WebRTC可能会影响网络中的其他用户加入电话会议。
分布式CDN
物联网（IoT）
物联网（IoT）部分涵盖了几种不同的用例。许多人都见过网络连接的安防摄像头。使用WebRTC，你可以将视频流式地传输到另一个WebRTC对等设备，例如电话或浏览器。另一个用例是让设备连接并交换传感器数据。你的局域网中可以有两个设备，互相交换天气，噪音或明亮度的读数。
与传统的视频流协议相比，WebRTC具有巨大的隐私优势。由于WebRTC支持P2P连接，因此摄像头可以将视频直接发送到你的浏览器。没有必要将你的视频发送到第三方服务器。即使视频是经过加密的，攻击者也可以根据通话的元数据做出一些猜测。
互操作性是物联网领域的另一个优势。WebRTC支持多种不同的语言，包括C＃，C ++，C，Go，Java，Python，Rust和TypeScript。这意味着你可以使用最适合你的语言。而且你无需求助于专有协议或格式就可以连接你的客户端。
媒体协议桥接
如果你现有的硬件和软件已经在产生视频，但是你还不能对其进行升级。期望用户下载专有客户端来观看视频是一件令人沮丧的事。解决问题的答案是运行一个WebRTC桥接器。桥接器在两种协议之间进行转换，因此用户可以在浏览器中使用旧的设置。
开发人员桥接使用的许多格式都使用与WebRTC一致的协议。SIP通常通过WebRTC暴露接口，并允许用户从其浏览器拨打电话。RTSP用于许多旧式安保摄像头。它们都使用相同的基础协议（RTP和SDP），因此其计算成本很低。只需要添加或删除WebRTC特定的内容即可完成桥接工作。
数据协议桥接
Web浏览器只能通过一组受限制的协议通信。你可以使用HTTP，WebSockets，WebRTC和QUIC。如果要连接到其他设备，你需要使用协议桥。协议桥是将外部流量转换为浏览器可访问内容的服务器。一个流行的示例是从浏览器使用SSH访问服务器。使用WebRTC的数据通道构建协议桥的话，具有下面两个优势。
WebRTC的数据通道允许不可靠且无序的交付。这在低延迟至关重要的情况下是必需的。你不会希望新数据被旧数据阻挡，这就是所谓的队头阻塞。假设你正在玩多人参与的第一人称射击游戏。你真的在乎玩家在两秒钟前的位置吗？如果这些数据没有及时到达，那么继续尝试发送就没有意义了。不可靠和无序的传送使你在一收到数据时就可以立即得到它。
数据通道还提供压力反馈。这可以告诉你发送数据的速度是否超过了连接所能支持的速度。然后，当这种情况发生时，有两个选择。可以将数据通道配置为缓冲并延迟传送数据，也可以删除尚未实时到达的数据。
远程操作
远程操作是指通过WebRTC数据通道控制远端设备，并通过RTP将视频数据发送回来。现在的开发人员已经可以通过WebRTC远程驾驶汽车了！这种技术可以用来控制施工现场和运送包裹的机器人。使用WebRTC解决这些问题很有意义，原因有两个。
WebRTC的普及使用户可以轻松控制。用户所需的只是一个Web浏览器和一个输入设备。浏览器甚至支持从操纵杆和游戏手柄获取输入。WebRTC完全不需要在用户设备上安装其他客户端。
分布式CDN
分布式CDN是文件共享的子集。分发的文件由CDN操作员配置。当用户加入CDN网络时，他们可以下载和共享允许的文件。用户获得与文件共享相同的所有好处。
当你在外部连接很差但LAN连接很好的办公室中时，这些CDN效果很好。你可以让一个用户下载视频，然后与其他人共享。由于不需要每个人都尝试通过外部网络获取相同的文件，因此传输将更快地完成。
WebRTC拓扑
WebRTC是用于连接两个Agent的协议，那么开发人员如何能同时连接上百人呢？你可以通过下面几种不同的方式来做到这一点，它们各有利弊。这些解决方案大致分为两类；点对点或客户端/服务器。WebRTC的灵活性使我们能够同时创建两者。
一对一
一对一是你使用WebRTC的第一种连接方式。将两个WebRTC Agent直接连接，它们可以双向发送媒体和数据。
连接看起来像这样。
全网格
如果要建立电话会议或多人游戏，那么要使用全网格。在这种拓扑中，每一个用户都直接与其他各个用户建立连接。你可以这样构建应用，但是它有一些缺点。
在全网格拓扑中，每个用户都直接连接（到其他用户）。这意味着你必须为参与通话的每个成员独立编码和上传视频。
由于各个连接的网络条件会有所不同，因此你无法重用同一视频。在这些部署中，错误处理也很困难。你需要仔细考虑连接是不是已经彻底断开了，还是只是丢掉了与单个远端peer的连接。
由于这些问题，全网格最好用于小型群组。对于更大的群组，最好还是使用客户端/服务器拓扑。
混合网格
混合网格是全网格的替代方案，可以减轻全网格的某些问题。在混合网格中，并不是所有每个用户之间都建立连接。作为替代，媒体是通过网络中的peer转发的。这意味着分发媒体时，创建者可以不必使用那么多的带宽。
这种方案确实也有一些缺点。在这种配置下，就算是媒体最初的创建者也不知道视频是谁发送的，也不知道视频是否成功的到达了目标。在混合网格网络中，每增加一跳，延迟也会相应地增加。
选择性转发单元（Selective Forwarding Unit）
SFU（选择性转发单元）同样解决了全网格网络的问题，但它使用了一种完全不同的方案。SFU以客户端/服务器拓扑实现，而不是P2P网络。
每个WebRTC peer都连接到SFU并上传其媒体。然后，SFU将此媒体转发到其他每个连接的客户端。
使用SFU，每个WebRTC Agent只需要执行一次视频的编码和上传。SFU负责将视频分发给所有观看者。
与SFU的连接也比P2P方式容易得多。你可以让SFU运行于一个全世界都可以访问的地址上，从而使得客户端连接更加容易。
你无需担心NAT映射。但你仍然需要确保SFU是可以通过TCP（ICE-TCP或TURN）使用的。
要创建一个简单的SFU，一个周末就可以完成。但建立一个可以处理所有类型客户的高质量SFU，是永无止境的。因为，拥塞控制调优、纠错和提高性能，是一项永无止境的任务。
多点会议单元（Multi-point Conferencing Unit）
MCU（多点会议单元）与SFU的客户端/服务器拓扑类似，但它会对输出流进行组合。MCU将要出站的媒体重新编码为一个供稿，而不是直接分发未经修改的版本。
