我对浏览器中的Peer-to-Peer连接感兴趣 . 由于这似乎可以通过WebRTC实现，我想知道它是如何工作的 .
我已经阅读了一些解释并看到了关于它的图表，现在我很清楚，连接 Build 在服务器上工作 . 服务器似乎在愿意相互连接的客户端之间交换一些数据，以便它们可以启动直接连接，这与服务器无关 .
但这是我不明白的特别之处 . 到目前为止，我认为创建连接的唯一方法是侦听计算机A上的端口并从计算机B连接到该端口 . 但在WebRTC中似乎并非如此 . 我认为没有一个客户端开始监听端口 . 不知何故，他们可以在不监听端口和接受连接的情况下创建连接 . 客户端A和客户端B都不会充当服务器 .
但是怎么样？通过WebRTC服务器交换哪些数据，客户端可以使用它们相互连接？
谢谢你的解释:)
Edit
我找到了this文章 . 它's not related to WebRTC, but I think it answers a part of my question. I'我不确定，很难 . 如果有人可以向我解释并给我一些额外的链接，它仍然会很酷 .
4 回答
WebRTC向客户端JS app提供SDP Offer以发送（但JS应用程序想要的）到另一个设备，该设备使用它来生成SDP应答 .
诀窍在于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（以及规范）已经转向使用"trickle"用于ICE候选者，因此ICE候选者通常被添加到PeerConnection后面并且独立于初始SDP进行交换（尽管您可以等到最初的SDP）候选人在发送报价之前已做好准备，并将它们捆绑在一起） . 见https://webrtcglossary.com/trickle-ice/和https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/
在本书_820893中可以找到一个非常好的解释，它提供了WebRTC如何使用ICE技术的基础知识 .
特别是假设已知STUN服务器的IP地址，WebRTC应用程序首先向STUN服务器发送绑定请求 . STUN服务器回复一个响应，该响应包含从公共网络看到的客户端的公共IP地址和端口 .
现在，应用程序发现它的公共IP和端口元组，它们可以通过SDP发送给另一个对等体 . （请注意，SDP是通过外部信令通道发送的，通过Web服务 Build 的f.i. websocket）
有了这个机制，每当两个对等体想要通过UDP相互通信时，他们就可以使用已 Build 的公共IP和端口元组来交换数据 .
不幸的是，在某些情况下，UDP可能会被防火墙阻止 . 为了解决这个问题，每当STUN失败时，我们都可以使用NAT（TURN）协议的遍历使用中继作为回退，它可以在UDP上运行并在所有其他方法都失败时切换到TCP .
Build p2p WebRTC连接有3个步骤（10.000英尺概述）：
步骤1： Signaling ：两个对等体连接到信令服务器（使用超过80/443，彗星，SIP等的网页框）并交换信息（关于它们的媒体功能，公共IP：端口对，当它们可用时等等） . ）
步骤2： Discovery ：连接到LAN或移动网络的设备不知道他们可以到达的公共IP（和端口），因此他们使用位于公共Internet上的STUN / TURN服务器来发现他们的ip：端口对（ ICE候选人） . 在这个过程中，他们在步骤3中使用的NAT /路由器上打了一个洞：
步骤3： P2P connection ：一旦通过初始信令信道交换ICE候选者，每个对等体都知道彼此的ip：端口（并且在NAT /路由器中已经打孔），因此可以 Build 对等UDP连接 .
上述方案解释了连接到本地网络的2个设备的过程 . 这是我撰写的一篇文章的一部分，该文章涉及troubleshooting connection issues，但它很好地解释了WebRTC的工作原理 .
WebRTC的工作原理
本文档提供了WebRTC的快速和抽象的介绍 . 要获得有关WebRTC的更多信息，请查看本文档末尾的“进一步阅读”部分 .
WebRTC
WebRTC（Web实时通信）是一组为浏览器之间的对等双工实时通信而开发的技术 . 正如它的名字所提到的那样，它与Web兼容并且它是一个standard in W3CWebRTC的一个重要特性是它甚至可以在NAT地址之后工作 .
WebRTC使用多种技术在浏览器之间提供实时对等通信 . 这些技术是* SDP (Session Description Protocol) * ICE (Interactivity Connection Establishment) * RTP (Real Time Protocol)
运行WebRTC还需要一个 Signalling Server . 但是，在实现信令服务器方面没有明确的标准 . 每个实现都创建自己的风格 . 本节稍后将提供有关信令服务器的更多信息 .
让我们快速介绍一下上面的技术 .
SDP（会话描述协议）
SDP是一种简单的协议，用于浏览器支持的编解码器 . 例如，假设有两个对等体（客户端A和客户端B）将通过WebRTC连接 . 客户端A和客户端B创建SDP字符串，用于定义它们支持的编解码器 . 例如，客户端A可以支持H264，VP8和VP9编解码器用于视频，Opus和PCM编解码器用于音频 . 客户端B可能仅支持H264用于视频，并且仅支持Opus编解码器用于音频 . 对于这种情况，将在客户端A和客户端B之间使用的编解码器是H264和Opus . 如果对等体之间没有共同的编解码器，则无法 Build 对等通信 .
您可能对如何在彼此之间发送这些SDP字符串有疑问 . 这是信令服务器发生的地方 .
ICE（交互连接 Build ）
即使它们落后于NAT，ICE也是在对等体之间 Build 连接的神奇之处 . 让我们假设客户端A和客户端B将再次连接并查看ICE如何用于此 .
在上图中，有两个服务器 . 其中一个是STUN，其他是TURN服务器 .
STUN服务器用于让客户端A了解其所有地址 . 让我举个例子，我们的计算机通常在192.168.0.0网络中有一个本地地址，当我们连接到www.whatismyip.com时，我们看到第二个地址，这个IP地址实际上是我们的Internet网关的公共IP地址（调制解调器） ，路由器等）所以让我们定义STUN服务器; STUN服务器允许对等方知道它们的公共和本地IP地址 . 顺便说一句，谷歌提供免费的STUN服务器（stun.l.google.com:19302） .
图像中还有一台服务器TURN服务器 . 当在对等体之间无法 Build 对等连接时，使用TURN服务器 . TURN服务器只是在对等体之间中继数据 .
客户端B执行相同操作，从STUN服务器获取本地和公共IP地址，并通过信令服务器将这些地址发送给客户端A.
客户端A接收客户端B的地址并通过发送特殊ping来尝试每个IP地址，以便与客户端B Build 连接 . 如果客户端A从任何IP地址接收响应，它会将该地址放入列表中，并显示其响应时间和其他性能凭据 . 最后，客户A根据其性能选择最佳地址 .
客户端B执行相同操作以连接到客户端A.
RTP（实时协议）
RTP是用于传输实时数据的成熟协议 . 它基于UDP . 音频和视频在WebRTC中通过RTP传输 . 存在RTP的姐妹协议，其名称是RTCP（实时控制协议），其在RTP通信中提供QoS . RTP也用于RTSP（实时流协议）
信令服务器
最后一部分是WebRTC中未定义的信令服务器 . 如上所述，信令服务器用于在客户端A和客户端B之间发送SDP字符串和ICE候选者 . 信令服务器还决定哪些对等体彼此连接 . WebSocket技术通常用于信令服务器进行通信 .
兼容性
在过去的一年中，包括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连接