如何使用WebRTC创建视频呼叫应用

常见的视频应用程序使用这项技术，称为WebRTC。WebRTC是最近的一项技术，允许开发人员使用您的日常互联网浏览器在Web上交换数据甚至媒体。这是十年来的一次技术变革，因为这样的功能只能作为插件使用，比如同花顺插件。

即使您没有听说过WebRTC，您可能以前已经使用过它。它们被用于WhatApps，Facebook，甚至Google讲义等。这就是所谓的Web实时通信，它允许你在浏览器之间进行直接连接。这项技术至少已经存在7年了，但我最终还是迎头赶上了！我设法创建了我自己的WebRTC应用程序，以便更好地了解该工具。

这是我的WebRTC应用程序，作为我的新玩具！请看这里。

魔术并不是真正的魔术。这只是一堆在表面下完成的密集工作。就像鸭子一样，它们看起来只是在水面上优雅地游动和滑行。但是当你看到这背后的作品时，你会发现这是一大堆老掉牙的玩意儿。

Web应用程序具有不同的组件。大多数都是看不见的，看不见的，比如服务器等等，但它们就像你的汽车引擎。当你开车的时候，你看不到它(除非你开的是一辆Doge Charger R/T)，但这并不意味着引擎也不在那里。

本节我们将详细介绍在整个过程中如何以及何时需要STUN服务器。

这一节我们就简单介绍一下，你什么时候需要轮到服务器。并不是在所有情况下都需要它，但是如果您必须处理稍微不那么直接的用例，那么它是一个需要的组件。

5.对于不同的使用情形和优化的房间容量，可能的WebRTC架构有哪些

当我们谈论WebRTC时，主要有4种体系结构。当您使用ZOOM时，您有没有想过一台服务器如何能够处理多达160名成员的会议？这不是魔术，它实际上需要传输大量的数据，简单地说10分钟的通话就需要万亿字节的数据。

当我在玩我的新玩具时，我设法找到了一些有趣的工具和资源，以适合简单WebRTC应用程序的不同组件。

当我们第一次开始视频聊天会话时，您首先需要向房间发出信号，表示您已经到达。这种告诉别人你到了的方式叫做发信号。如果你是第一个到达聚会场所的人，严格来说，你仍然会打招呼，但不会有人回应你。

从技术意义上讲，信令是交互式连接建立框架的一部分，是通过交换媒体信息找到对方然后协调通信的过程。信令利用会话描述协议(SDP)来收集网络信息，例如用于媒体交换的网际协议地址(IP地址)和端口号。

会话描述协议(SDP)，用作通告和管理会话邀请的标准方法。它以基于文本的格式表示浏览器功能和首选项。

为了使您的浏览器连接到其他浏览器，在SDP中交换的信息包含以下内容：

网络数据，例如外部世界看到的主机的IP地址和端口。

您需要有一个Web应用程序，该应用程序能够在加载或单击按钮时建立连接，然后在同一聊天室中显示由您的同行发送的视频数据。

从更专业意义上讲，您需要创建RTCPeerConnection产品，并将其发送到远程对等点以存储在自己的计算机中。一旦您完成了Web应用程序，您需要将您的Web应用程序托管在Web服务器中的某个位置，以便您的朋友可以公开访问它。

还记得我们提到的信号吗？它用于向特定房间中的所有成员表明您已到达。当您到达时，房间中的每个成员都会通过SDP记录您的远程信息和详细信息，并将其存储到他们的机器上-准备接收来自您的媒体数据。

从技术上讲，WebRTC负责SDP信息的创建和处理，而不是SDP信息的发送和接收部分。因此，此传输需要服务器。利用WebSocket服务器进行此传输和初始化是相当常见的。

此服务器用于检索远程对等方的公用IP地址。为了避免涉及技术细节，我们每个人都有一个公共IP地址，而STUN服务器是用来获取这些信息的。然后，此信息将成为您刚到达时需要发送给您的同行的SDP信息的一部分。

此服务器用作中间人，以便在您需要时为您传递消息，并且无法直接与您的远程对等方联系。有人在Quora中提出了这个问题，您可以在这里查看。

NAT会话穿越实用程序(STUN)。双方都必须至少知道其对等方的IP地址和分配的UDP端口。

无论使用哪种架构，我们总是需要一个信令服务器来注册和出席。我们需要一台TURN服务器来进行网络遍历，并确保内部IP地址可以映射到外部公有IP地址。

现在您可以看到，您的浏览器使用STUN服务器请求您的公共IP地址。这些都是在引擎盖下完成的，看不见。我学到的一件事是，魔术从来不是真正的魔术。幕后有很多事情在发生。如果你想学魔术的话？你必须学会这些幕后的步骤。

使用中继NAT的穿越是用于中继网络流量的协议。有时，当您使用TURN服务器并设法检索远程对等点的公共IP地址时，由于防火墙和一些与网络相关的工具(如果您有兴趣了解，请使用NAT)，您需要一个网络可公开访问的TURN服务器来为您进行媒体中继。这有点像你的中间人帮你传递信息。

客户端对客户端，在电话会议中有3个客户端的情况下，将有2个连接需要加密和建立。正如您在下面的屏幕截图中所看到的，每个人都与每个人联系：

选择性转发单元在会话中间充当智能媒体中继。每个客户端连接到SFU一次以发送媒体，然后每隔一个客户端再连接一次，从而导致每个客户端管理n个单向连接，其中n是连接的客户端的数量。虽然此架构的总连接数为n^2，但客户端只在连接初始化时加密一次，这减轻了设备本身的压力，尤其是对于移动设备。

转发需要额外的服务器基础设施，如SFU，但效率很高。除非激活记录或对数据进行解码，否则SFU不会尝试解密数据包。

混合依赖于多点控制单元(MCU)，它在会话中间充当高性能的媒体混合器。每个客户端连接到MCU一次，无论连接多少个客户端，都只需处理一个双向连接。该连接将用于从服务器发送和接收媒体。

就像转发一样，加密和上传只进行一次，但现在我们也只下载和解密一次。此方法在客户端上效率最高，但从服务器角度看效率最低。解包、解码、混合、编码和打包的负担完全在服务器上执行。此方法具有相当繁重的操作集，需要大量服务器资源才能实时完成。

对于具有大量活动参与者的应用程序(如虚拟教室)或设备特别受资源限制(如带宽)的情况，可以考虑使用此方法。这种架构是以服务器成本为代价的。

顾名思义，混合架构是网状、转发和/或混合的组合。因此，您可以根据最有意义的内容为参与者创建会话。

对于简单的两方呼叫，网格设置很简单，只需要最少的服务器资源。

对于小组会议、广播和现场活动，转发将最适合满足需求。

对于较大的小组会议或电话集成，混合通常是需要考虑的开放式实用选项。

WebRTC应用程序的问题一次又一次地发生在规模化的时候。它消耗了大量的数据。因此，如果您打算扩展WebRTC应用程序，考虑合适的体系结构将是第一场胜利。第二场战斗是数据流量问题。

在对500名参与者进行压力测试的情况下，分成5个参与者只运行6.5分钟的多方通话组。服务器实际上双向传输了52 GB的媒体流量。不到10分钟。

我找到了一个全面的YouTube视频，它可以帮助人们理解WebRTC应用程序是如何工作的。有趣的是，我们发现所有与WebRTC相关的YouTube视频都至少有几年的历史了。WebRTC已经有7年的历史了。我猜约书亚终于赶上了，我希望我今天能设法让你们了解这项古老的技术！