webrtc - WebRTC 是如何工作的？

Question

我对浏览器中的点对点连接感兴趣。由于这对于 WebRTC 来说似乎是可能的，我想知道它是如何精确工作的。

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

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

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

感谢您对此的解释:)

编辑

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

Answer 1

WebRTC 将 SDP Offer 提供给客户端 JS 应用程序，以将其发送(无论 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/其余的，还有谷歌。其中大部分由 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/