webrtc - WebRTC 是如何工作的?

标签 webrtc stun turn

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

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

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

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

感谢您对此的解释:)

编辑

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

最佳答案

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/

关于webrtc - WebRTC 是如何工作的?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/12708252/

相关文章:

javascript - 用 Pubnub 替换 Socket io (WebRTC)

android - 具有 H264 解码功能的 WebRTC 视频 Android 和 iOS 客户端

javascript - WebRTC DataChannel:在Firefox中工作,但在Chrome中不工作

java - 如何在不丢失数据包的情况下通过打洞 (STUN) UDP 发送大文件?

javascript - 即使我们确切知道连接的路由,缓存 ICE 候选者和 sdp 是否也不起作用?

javascript - WebRTC 通过 Web Audio API 在 google Chrome 上保持静音

webrtc - NAT 后面的 coTurn 服务器

firefox - WebRTC:Firefox 中缺少中继候选者

ssl - TURN 服务器使用 https 连接进行管理 session

linux - OpenSIPs stun 模块需要两个 IP 地址