WebRTC 是如何工作的？

Posted 2023-03-14

【中文标题】WebRTC 是如何工作的？

【英文标题】：How does WebRTC work?

【发布时间】：2012-09-24 08:48:13

【问题描述】：

我对浏览器中的点对点连接感兴趣。由于 WebRTC 似乎可以做到这一点，我想知道它是如何工作的。

我已经阅读了一些解释并查看了有关它的图表，现在我很清楚，连接建立在服务器上工作。服务器似乎在愿意相互连接的客户端之间交换一些数据，以便他们可以启动直接连接，即独立于服务器。

但这正是我不明白的。到目前为止，我认为创建连接的唯一方法是侦听计算机 A 上的端口并从计算机 B 连接到该端口。但在 WebRTC 中似乎并非如此。我认为没有一个客户端开始监听端口。不知何故，他们可以在不监听端口和接受连接的情况下创建连接。客户端 A 和客户端 B 都没有开始充当服务器。

但是怎么做呢？通过 WebRTC 服务器交换哪些数据，客户端可以使用这些数据相互连接？

感谢您对此的解释:)

编辑

我找到了this 文章。它与 WebRTC 无关，但我认为它回答了我的部分问题。我不确定，很难。如果有人可以向我解释并给我一些额外的链接，它仍然会很酷。

【问题讨论】：

为了初始化 WebRTC 的基本部分“状态机”，我们必须使用像服务器这样的中间代理通过 ROAP 协议/从 STUN/TURN 服务器的连接获取 ICE 候选者......今天，我们依赖 SIP 服务器，但也有一些其他选项！

RTCWeb / WebRTC 解释——来自 WebRTC 联合编辑 Cullen Jennings 的约 40 分钟视频演示——adf.ly/DHgzv

【参考方案1】：

WebRTC 向客户端 JS 应用程序提供 SDP Offer 以发送（无论 JS 应用程序想要）到另一台设备，后者使用它来生成 SDP Answer。

诀窍在于 SDP 包含 ICE 候选者（实际上是“尝试通过此 IP 地址和此端口与我交谈”）。 ICE 可以在防火墙中打开端口；但如果双方都是对称 NAT，一般情况下是不可能的，可以使用替代候选者（在 TURN 服务器上）。

一旦他们直接交谈（或通过 TURN，这实际上是一个数据包镜像），他们就可以打开一个 DTLS 连接并使用它来加密 SRTP-DTLS 媒体流，并通过 DTLS 发送 DataChannel。

编辑： 这里的首字母缩略词：http://blog.1click.io/10-jargons-abbreviations-for-webrtc-fans/ 其余的是 Google。其中大部分由 IETF (http://ietf.org/) 定义

编辑 2： Firefox 和 Chrome（以及规范）已开始对 ICE 候选者使用“trickle”，因此 ICE 候选者通常在面后添加到 PeerConnection 并独立于初始 SDP 进行交换（尽管您可以等到初始候选者在发送报价之前准备好，并将它们捆绑在一起）。 见https://webrtcglossary.com/trickle-ice/和https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/

【讨论】：

谢谢！这是一个很好的解释:)

我们可以使用 webRTC 制作具有不同设备兼容性的一对多视频应用程序吗？ （iPhone、iPad 和台式机）

iPhone 和 iPad 的浏览器不支持 WebRTC。因此，您需要为 ios safari 浏览器使用额外的 webrtc pugin。基于Flashphoner WebRTC媒体和广播服务器goo.gl/wYEEUq

可以部署一对多的webrtc视频应用

一些建设性的批评：我很难理解这个答案，因为使用了许多首字母缩略词（SDP、ICE、DTLS、SRTP-DTLS）和不精确的语言（例如，在“然而 it 想要，“它是什么代理？”）。

如需更详细地了解 WebRTC，请查看这份免费报告：bloggeek.me/webrtc-business-people；有关首字母缩略词的解释，请查看 WebRTC 词汇表：webrtcglossary.com

【参考方案2】：

WebRTC 的工作原理

本文档对 WebRTC 进行了快速而抽象的介绍。要获取有关 WebRTC 的更多信息，请查看本文档末尾的进一步阅读部分。

WebRTC

WebRTC（Web Real-Time Communication）是为浏览器之间的点对点双工实时通信而开发的一组技术。顾名思义，它与 Web 兼容，它是 standard in W3C WebRTC 的重要特性之一是它甚至可以在 NAT 地址后面工作。

WebRTC 使用多种技术在浏览器之间提供实时对等通信。这些技术是

SDP (Session Description Protocol) ICE (Interactivity Connection Establishment) RTP (Real Time Protocol)

还有一件事是 Signalling Server 是运行 WebRTC 所需要的。但是，在实现信令服务器方面并没有明确的标准。每个实现都创建自己的样式。本节稍后将提供有关 Signaling Server 的更多信息。

让我们快速了解一下上述技术。

SDP（会话描述协议）

SDP 是一个简单的协议，它用于浏览器支持的编解码器。例如，假设有两个对等点（Client A 和 Client B）将通过 WebRTC 连接。 Client A 和 Client B 创建 SDP 字符串，定义它们支持的编解码器。例如，Client A 可能支持视频的 H264、VP8 和 VP9 编解码器，音频的 Opus 和 PCM 编解码器。 客户端 B 可能仅支持视频的 H264 和音频的仅 Opus 编解码器。对于这种情况，Client A 和 Client B 之间将使用的编解码器是 H264 和 Opus。如果对等体之间没有通用编解码器，则无法建立对等通信。

您可能对如何在彼此之间发送这些 SDP 字符串有疑问。这是 Signaling Server 发生的地方。

ICE（交互连接建立）

ICE 是在对等点之间建立连接的魔法，即使它们位于 NAT 之后。让我们再次假设 Client A 和 Client B 将连接起来，看看 ICE 是如何用于此的。

Client A 使用 STUN 服务器找出他们的本地地址和公共 Internet 地址，并通过 Signaling Server 将这些地址发送给 Client B。从 STUN 服务器接收到的每个地址都称为 ICE 候选者

在上图中，有两台服务器。其中一个是 STUN，另一个是 TURN 服务器。

STUN 服务器用于让 Client A 了解其所有地址。举个例子吧，我们的电脑一般在192.168.0.0网络有一个本地地址，连接www.whatismyip.com时看到的还有第二个地址，这个IP地址其实就是我们Internet网关的Public IP地址（调制解调器、路由器等）所以让我们定义 STUN 服务器； STUN 服务器让对等方知道他们的公共和本地 IP 地址。顺便说一句，谷歌提供免费的 STUN 服务器（stun.l.google.com:19302）。

图像中还有一个服务器，TURN 服务器。当对等点之间无法建立对等连接时，使用 TURN Server。 TURN 服务器只是在对等点之间中继数据。

Client B 做同样的事情，从 STUN 服务器获取本地和公共 IP 地址，并通过 Signaling Server 将这些地址发送给 Client A。

客户端 A 接收 客户端 B 的地址并通过发送特殊 ping 来尝试每个 IP 地址，以便创建与 客户端 B 的连接。如果客户端 A 接收到来自任何 IP 地址的响应，它将将该地址连同其响应时间和其他性能凭据一起放入一个列表中。最后Client A根据其性能选择最佳地址。

Client B 为了连接到Client A

做同样的事情

RTP（实时协议）

RTP 是一种成熟的传输实时数据的协议。它基于UDP。音频和视频在 WebRTC 中使用 RTP 传输。 RTP 有一个姊妹协议，名为 RTCP（实时控制协议），它在 RTP 通信中提供 QoS。 RTP也用于RTSP(Real-time Streaming Protocol)

信令服务器

最后一部分是未在 WebRTC 中定义的信令服务器。如上所述，信令服务器用于在 Client A 和 Client B 之间发送 SDP 字符串和 ICE Candidates。信令服务器还决定哪些对等方相互连接。 WebSocket技术一般用于Signaling Servers进行通信。

兼容性

在过去的一年里，包括 Safari、Edge 在内的所有浏览器都发布了支持 WebRTC 的新版本。 Chrome、Firefox 和 Opera 已经支持 WebRTC 有一段时间了。浏览器常用的视频编解码器是 H264。对于音频，Opus 在浏览器中很常见。 PCM 也可用于音频编解码器，但由于许可问题，即使所有浏览器都支持 AAC，也不使用 AAC。 IP 摄像机通常支持 H264 视频编解码器和 PCM 或 AAC 音频编解码器。

进一步阅读和参考

WebRTC Samples ICE Wikipedia SDP RTP RFC Getting Started with WebRTC WebRTC.org STUN Server RTSP Wikipedia

顺便说一句，我是 Ant Media Server 的开发人员，它支持可扩展的一对多 WebRTC 和对等 WebRTC 连接

【讨论】：

这是一个很好的解释，这些片段相互关联，大多数其他资源只是在你脸上扔了很多首字母缩略词。

【参考方案3】：

建立 p2p WebRTC 连接需要 3 个步骤（10.000 英尺概览）：

第 1 步：信令：双方都连接到信令服务器（使用 websockets over 80/443、comet、SIP 等）并交换信息（关于他们的媒体功能、公共 IP：可用时的端口对等）

第 2 步：发现：连接到 LAN 或移动网络的设备不知道可以访问它们的公共 IP（和端口），因此它们使用位于的 STUN/TURN 服务器在公共 Internet 上发现他们的 ip:port 对（ICE 候选）。在此过程中，他们在步骤 3 中使用的 NAT/路由器上打了一个洞：

第 3 步：P2P 连接：一旦通过初始信令通道交换 ICE 候选者，每个对等方都知道彼此的 ip:port（并且在 NAT/路由器中已打孔)，因此可以建立点对点 UDP 连接。

上面的方案解释了两个设备连接到本地网络的过程。这是我写的一篇文章的一部分，涉及troubleshooting connection issues，但它很好地解释了 WebRTC 的工作原理。

【讨论】：

感谢您的回答！这比我觉得太罗嗦的大多数其他解释更有帮助。

【参考方案4】：

可以在本书“高性能浏览器网络（O'Reilly）”中找到很好的解释 http://chimera.labs.oreilly.com/books/1230000000545/ch03.html#STUN_TURN_ICE 它提供了 WebRTC 如何使用 ICE 技术的基础知识。

特别假设 STUN 服务器的 IP 地址已知，WebRTC 应用程序首先向 STUN 服务器发送绑定请求。 STUN 服务器回复一个响应，其中包含从公共网络看到的客户端的公共 IP 地址和端口。

现在应用程序发现了它的公共 IP 和端口元组，这些元组可以通过 SDP 发送给其他对等方。 （请注意，SDP 是通过外部信号通道发送的，例如通过 Web 服务建立的 websocket）

有了这个机制，每当两个对等方想要通过 UDP 相互通信时，他们就可以使用已建立的公共 IP 和端口元组来交换数据。

很遗憾，在某些情况下，UDP 可能会被防火墙阻止。为了解决这个问题，每当 STUN 失败时，我们可以使用 Traversal Using Relays around NAT (TURN) 协议作为备用协议，该协议可以通过 UDP 运行并在其他所有方法都失败时切换到 TCP。

【讨论】：

那本书叫什么名字？

书籍：高性能浏览器网络（oreilly）