WebRTC工作流程
WebRTC Working Process
我想在 iOS 上使用视频通话，我为此进行了研发，发现 Webrtc 是此选项。
正如我发现 WebRTC 是点对点的 communication.And 它的演示示例包含一个服务器 LINK。
所以我的问题是，如果 WebRTC 是点对点的，那么为什么要使用服务器。
WebRTC 可用于多项任务，但实时点对点音频和视频（即多媒体）通信是主要优势。为了通过 Web 浏览器与另一个人（即对等方）通信，每个人的 Web 浏览器都必须同意开始通信，知道如何定位彼此，绕过安全和防火墙保护，并实时传输所有多媒体通信。
与基于浏览器的对等通信相关的最大挑战之一是了解如何定位和建立与另一台计算机的 Web 浏览器的网络套接字连接，以便双向传输多媒体数据。与此相关的困难乍一看可能并不明显，但让我进一步解释一下。
访问网站时，通常会输入网址或单击 link 来查看页面。向服务器发出请求，服务器通过提供网页进行响应（HTML、CSS 和 JavaScript）。这里的关键是您向已知且易于定位（通过 DNS）的服务器发出 HTTP 请求并返回响应（即网页）。
现在假设我想和我亲爱的妈妈视频聊天。我妈妈的电脑不是网络服务器。因此，问题是我如何直接请求并实际接收到她的音视频数据，同时不通过外部服务器直接将我的音视频数据发送给她？
得到了HERE
的帮助
应用程序一直监听新连接是不安全的，您通常只希望应用程序中的出站连接，入站连接在服务器应用程序中找到。
这是点对点的问题，因为如果两个点都只连接出站，他们将如何建立连接？答案是所有对等点都连接到一个信令服务器。当开始呼叫时，对等点向服务器发出信号，表明它想呼叫另一个对等点。服务器然后可以让其他对等方知道有来电。
到这里还没有结束，仍然没有联系，但至少双方都知道会有一个。两个同行现在将开始产生 ICE 候选人。通过 ICE，对等点找到建立连接的路由。有时您现在可以点对点连接，但通常至少涉及 1 个防火墙（大多数时候更多）。在那种情况下，协议会尝试一个 STUN 服务器，它在防火墙中 'punches a hole'（基本上，它以安全的方式打开一个端口）。这涵盖了所有点对点连接的 90%，但仍有一些情况下点对点连接是不可能的。这就是 TURN 的用武之地，它是一个中继服务器，您的对等方可以使用它来将数据中继到其他对等方。这种连接不是点对点的。
我想在 iOS 上使用视频通话，我为此进行了研发，发现 Webrtc 是此选项。 正如我发现 WebRTC 是点对点的 communication.And 它的演示示例包含一个服务器 LINK。 所以我的问题是，如果 WebRTC 是点对点的，那么为什么要使用服务器。
WebRTC 可用于多项任务，但实时点对点音频和视频（即多媒体）通信是主要优势。为了通过 Web 浏览器与另一个人（即对等方）通信，每个人的 Web 浏览器都必须同意开始通信，知道如何定位彼此，绕过安全和防火墙保护，并实时传输所有多媒体通信。
与基于浏览器的对等通信相关的最大挑战之一是了解如何定位和建立与另一台计算机的 Web 浏览器的网络套接字连接，以便双向传输多媒体数据。与此相关的困难乍一看可能并不明显，但让我进一步解释一下。
访问网站时，通常会输入网址或单击 link 来查看页面。向服务器发出请求，服务器通过提供网页进行响应（HTML、CSS 和 JavaScript）。这里的关键是您向已知且易于定位（通过 DNS）的服务器发出 HTTP 请求并返回响应（即网页）。
现在假设我想和我亲爱的妈妈视频聊天。我妈妈的电脑不是网络服务器。因此，问题是我如何直接请求并实际接收到她的音视频数据，同时不通过外部服务器直接将我的音视频数据发送给她？
得到了HERE
的帮助应用程序一直监听新连接是不安全的，您通常只希望应用程序中的出站连接，入站连接在服务器应用程序中找到。
这是点对点的问题，因为如果两个点都只连接出站，他们将如何建立连接？答案是所有对等点都连接到一个信令服务器。当开始呼叫时，对等点向服务器发出信号，表明它想呼叫另一个对等点。服务器然后可以让其他对等方知道有来电。
到这里还没有结束，仍然没有联系，但至少双方都知道会有一个。两个同行现在将开始产生 ICE 候选人。通过 ICE，对等点找到建立连接的路由。有时您现在可以点对点连接，但通常至少涉及 1 个防火墙（大多数时候更多）。在那种情况下，协议会尝试一个 STUN 服务器，它在防火墙中 'punches a hole'（基本上，它以安全的方式打开一个端口）。这涵盖了所有点对点连接的 90%，但仍有一些情况下点对点连接是不可能的。这就是 TURN 的用武之地，它是一个中继服务器，您的对等方可以使用它来将数据中继到其他对等方。这种连接不是点对点的。