WebRTC如何工作？
我对浏览器中的对等连接感兴趣。 由于这似乎是可能的WebRTC，我想知道它是如何工作的exaclty。
我已经阅读了一些解释并看到了关于它的图表，现在很明显，连接build立在服务器上。 服务器似乎在愿意互相连接的客户端之间交换一些数据，以便他们可以启动一个独立于服务器的直接连接。
但那是我不明白的。 到目前为止，我认为创build连接的唯一方法是在计算机A上监听端口，并从计算机B连接到该端口。但在WebRTC中似乎并不是这种情况。 我认为没有一个客户开始听港口。 不知何故，他们可以创build一个连接，而不需要监听端口和接受连接。 客户端A和客户端B都不作为服务器。
但是，如何？ 通过WebRTC服务器交换什么数据，客户端可以使用哪些数据互相连接？
感谢您的解释:)
编辑
我发现这篇文章。 这与WebRTC无关，但我认为它回答了我的问题的一部分。 我不确定，强硬。 如果有人能向我解释，并给我一些额外的链接，它仍然会很酷。
WebRTC将SDP Offer提供给客户端JS应用程序以发送（但是JS应用程序想要的）给另一个设备，该设备使用它来生成SDP Answer。
诀窍是，SDP包括ICE候选人（有效地“试图在这个IP地址和这个端口与我交谈”）。 ICE可以打开防火墙中的开放端口。 但是如果双方都是对称的NAT，一般是不可能的，并且可以使用替代的候选（在TURN服务器上）。
一旦他们直接交谈（或通过TURN，这实际上是一个数据包镜像），他们可以打开一个DTLS连接并使用它来键入SRTP-DTLS媒体stream，并通过DTLS发送DataChannel。
编辑：首字母缩写词： http : //blog.1click.io/10-jargons-abbreviations-for-webrtc-fans/剩下的就是Google。 其中大部分是由IETF（ http://ietf.org/ ）定义的，
编辑2：火狐浏览器和Chrome浏览器（以及规范）已经开始使用ICE候选者的“窍门”了，所以ICE候选人通常会被添加到PeerConnection，并独立于最初的SDP进行交换（尽pipe您可以等到最初的候选人在发送要约之前已经准备好了，并将它们捆绑在一起）。 请参阅https://webrtcglossary.com/trickle-ice/和https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/
在这本书中可以find一个非常好的解释http://chimera.labs.oreilly.com/books/1230000000545/ch03.html#STUN_TURN_ICE ，它提供了WebRTC如何使用ICE技术的基础知识。
特别是假设STUN服务器的IP地址是已知的，WebRTC应用首先向STUN服务器发送一个绑定请求。 STUN服务器回复一个响应，其中包含从公共networking上看到的客户端的公共IP地址和端口。
现在，应用程序发现它的公共IP和端口元组，它可以通过SDP发送给另一个对端。 （注意，SDP通过外部信令通道发送，通过web服务build立fi websocket）
有了这个机制，无论何时两个对等方想要通过UDP进行对话，他们就可以使用build立的公共IP和端口元组来交换数据。
不幸的是，在某些情况下，UDP可能被防火墙阻止。 为了解决这个问题，每当STUN失败时，我们可以使用围绕NAT（TURN）协议的遍历（Traversal Using Relays）作为后备（fallback），它可以通过UDP运行并且在所有其他操作失败的情况下切换到TCP。
build立一个p2p WebRTC连接有三个步骤（概述10.000英尺）：
-
步骤1： 信令 ：两个对端连接到一个信令服务器（使用80/443以上的websocket，comet，SIP等），并交换信息（关于它们的媒体能力，公共IP：端口对，等等）
-
步骤2： 发现 ：连接到局域网或移动networking的设备不知道他们的公共IP（和端口）在哪里可以到达，因此他们使用位于公共互联网上的STUN / TURN服务器来发现他们的IP端口对（ICE候选人）。 在这个过程中，他们通过步骤3中使用的NAT /路由器打洞：
-
步骤3： P2P连接 ：一旦ICE候选者通过初始信令信道交换，每个对等方知道彼此的ip：端口（并且已经在NAT /路由器中打孔），从而build立点对点UDP连接。
上面的scheme解释了连接到本地networking的2个设备的过程。 这是我写的一篇文章的一部分，涉及到解决连接问题，但是它很好地解释了WebRTC的工作原理。
