在哪些条件下,Webrtc PeerConnection如何在没有TURN服务器的情况下工作？

Question

阅读有关Webrtc的信息我感觉"它会大大降低服务器带宽使用率",除了"一些角落企业防火墙案例",其中一个需要TURN服务器来传递对等体之间的整个流量.

例如,altough没有的WebRTC相关,但这个想法是相似的,对维基百科文章的chatroulette声明:本网站使用的Adobe Flash显示视频和访问用户的摄像头.Flash的点对点网络功能(通过RTMFP)允许几乎所有视频和音频流直接在用户计算机之间传输,而无需使用服务器带宽.但是,某些路由器组合不允许UDP流量在它们之间流动,然后有必要回退到RTMP.

Webrtc上的类似文章也集中在"是的,防火墙可能存在问题,所以你需要一个TURN服务器,但忽略这一点,看看我真棒的PeerConnection javascript代码".

我不明白的是:

两个对等体之间的连接需要打开服务器套接字,以便对等体可以连接到它.甚至UDP也需要udp服务器套接字的概念.由于几乎所有非服务器互联网连接的对等设备都支持某种路由器.例如,每个智能手机都使用wifi路由器,台式PC使用服务提供商的路由器,......它不可能连接到智能手机(浏览器webrtc服务器套接字)上托管的服务器套接字或路由器/防火墙的桌面原因.

因此,我的理解实际上没有两个需要通过互联网发送流量的同行能够使用直接的P2P连接,对吧？因此,使用Webrtc的唯一有用的案例是在类似局域网的环境中,对吧？此外,在像基于webrtc的chatroulette的视频聊天服务的情况下,需要使用一堆TURN服务器来中继几乎所有流量.这使得Webrtc在托管我自己的解决方案方面与服务器带宽同样昂贵.

所以我的问题是:我是对的吗？如果不是什么技术细节允许在没有TURN服务器的情况下使用PeerConnection但是由互联网分开的两个节点？如何在第4层建立TCP/UDP传输层的连接？它是否使用UDP和所有wifi路由器允许托管UDP服务器套接字等？这对NAT和安全性没有多大意义.

更新1: 进一步挖掘我发现"对称nat"意味着什么以及它与企业有什么关系:在大多数企业中,似乎连接到互联网的设备具有对称的nat实现.这意味着将内部"internal-ip:internal-port"元组映射到"internet-ip:internet-port"的路由表也存储"destination-ip:destination-port".所以这样的路由/ nat为每个(tcp？)连接存储一个表,其中包含6列"internal-ip:internal-port:internet-ip:internet-port:destination-ip:destination-port".这意味着没有其他人,但目的地被允许与internal-ip:internal-port通信.而非企业路由器似乎只存储"internal-ip:internal-port:internet-ip:internet-port"组合.这也意味着"在防火墙上挖洞".

Answer 1

你不对.所有对等方都有IP地址以便进行通信,并且只要防火墙允许,就可以在相同的地址上访问.

NAT往往仅针对客户端启动的客户端 - 服务器流量进行优化.这通常意味着它们最初仅允许出站流量,并且仅在出站流量发生后允许同一线路上的入站流量.适合服务器.有关问题的介绍,请参阅此WebRTCHacks文章.

这是ICE从内部(客户端)尝试在防火墙中挖洞的地方,以便在两个对等体之间直接建立通信线路,而无需任何"服务器"套接字,无论这意味着什么.

ICE如何工作非常复杂,并在RFC中详细解释.

但从广义上讲,它可以通过以下几个步骤进行:

1. 每个对等体(例如浏览器)都有一个收集候选者的"ICE代理".候选者是可以到达该对等体的地址(IP:端口号),包括:
   1. 主持人候选人:例如机器的直接LAN/wifi/VPN IP.
   2. 服务器自反候选者:机器的公共(外部NAT)地址,通过在互联网上反弹镜像(STUN)服务器的请求获得.
   3. 中继候选者:共享TURN服务器的地址,以便在所有其他方法都失败时转发数据.
2. 一旦被发现,候选者就被插入到本地SDP中,并通过信令信道流入另一个对等体,在那里它们被插入到远程描述中,其他代理看到它们.
3. 一旦ICE代理同时拥有本地和远程候选者,它就会开始配对本地和远程候选者,并通过发送STUN请求来检查它们的连接性(有效地尝试到达对等体).
4. 成功的对是ICE代理已经得到回复的对象(如果你愿意,可以进行4次握手).
5. 如果有多个成功的对,则按一些指标进行排序,并选择最佳对.
6. 然后使用所选对发送媒体.每个(视频或音频)媒体轨道需要一对.
7. 如果稍后找到更好的对,则所选对可能会发生变化,从而影响发送的地址媒体.

只有在两个客户端都在对称 NAT 后面或者UDP流量完全被阻止的情况下才需要TURN .