WebRTC和STUN、TURN、ICE是怎么实现浏览器视频通话的

让分别处于两个家庭路由器后面的浏览器直接对话,远比听起来复杂——WebRTC、STUN、TURN、ICE正是让这件事得以实现的几块拼图。

WebRTC让浏览器无需插件就能建立点对点连接

WebRTC(网页实时通信)是一项浏览器标准,能让两台设备之间直接建立音频、视频和数据连接,不需要安装浏览器扩展或单独的应用程序,是大多数浏览器内视频通话的底层技术。

家用路由器和NAT是直接连接的最大障碍

大多数设备都处于执行NAT(网络地址转换)的路由器背后,外部世界看不到它们真正的网络地址。因此,处于不同家庭网络中的两台设备,如果不先解决地址问题,是没办法简单地直接建立连接的。

STUN负责探测自己在外部看来的公网地址

STUN(NAT会话穿越应用程序)服务器会告诉设备,从外部看它的公网IP地址和端口是什么,这是把连接方式告诉通话对方之前必须先掌握的信息。

TURN在无法直连时负责中继转发

当NAT或防火墙的限制过于严格、无法建立直接的点对点连接时,TURN(通过中继穿越NAT)服务器会居中转发双方的通信流量,代价是比直接连接多出一些延迟。

ICE收集并测试所有候选路径,挑出最优的一条

ICE(交互式连接建立)会收集通过STUN、TURN等方式得到的候选连接路径,逐一测试并选出实际可用的最佳路径,只有在所有直连路径都失败时,才会退回到TURN中继。

信令是WebRTC本身没有规定的独立环节

在STUN、TURN、ICE发挥作用之前,双方需要先有一种交换连接信息的初始手段,也就是信令。WebRTC刻意没有规定这一部分该怎么实现,通常由应用程序自己通过普通的WebSocket或服务器连接来完成。

为什么直接视频通话没有看上去那么简单

两个分别处于不同家庭网络、各自被NAT路由器隔开的人,不能直接用对方的局域网IP地址来连接,因为那个地址一旦离开各自的家庭网络就没有意义。STUN、TURN、ICE这一整套机制,正是为了解决这种地址和可达性的问题,好让WebRTC能够尽可能地尝试建立直接连接。

为什么大多数通话更倾向于直连而不是走TURN中继

通过STUN发现、再经ICE确认的直接点对点连接,延迟更低,也不依赖第三方中继服务器一直保持可用和高速。TURN的存在纯粹是为了应对那些确实无法建立直连路径的情况,比如限制较严的企业网络或移动网络环境。

常见问题

为什么有些视频通话会突然需要用到TURN服务器?

当双方所在的网络都有严格的防火墙或NAT设置,阻止了直接的点对点连接时,ICE就找不到可用的直连路径,只能退而求其次,把所有流量都通过TURN服务器中继,这可能会带来明显的延迟。

WebRTC是不是一定是完全的点对点通信?

不一定。只有在找到直连路径时,通话才是真正的点对点。三人以上的群组通话,以及退回TURN中继的通话,即便使用的是WebRTC标准,严格来说也不算点对点。