【WebRTC】NAT机制和传输机制

1.NAT机制

WebRTC对内网上的主机建立连接需要NAT，即网络地址转换。

WebRTC直接采用了Libjingle中关于传输部分的组件。

Libjingle是Google公司开发的实现P2P传输的C++开源库，Google Talk就是基于这个库开发的。通过Libjingle可以建立一个直通的网络连接，可以无需关心中间的NAT，防火墙，中继服务器和代理, 会话建立的细节，直接进行数据的交换。

Libjingle中采用的是ICE这种综合性的NAT穿越框架。ICE综合运用基于UDP的STUN和基于TCP的TURN协议来实现。使用ICE的应用程序需要一个ICE代理来负责ICE，STUN，TURN以及其他模块的交互，发现本地设备的网络的拓扑结构的信息，找到一条路径或者通过该路径通信。每个代理都有一些可以用于与远端主机代理通信的候选传输地址(candidate)。在网络中，每个代理可有自己的STUN服务器，也可公用一个。本地计算机收集到所有的候选传输地址，将它们按优先级高低进行排序，然后通过信令通道发送给远端计算机。这些候选传输地址作为SDP请求的属性被传输。当远端计算机收到请求后进行相同的收集过程，并且把自己的候选传输地址作为响应消息发送给请求者。这样，每个代理都有一个完整的包含了双方候选传输地址的列表，即可进行后续数据传输。

WebRTC中这一过程由浏览器底层实现，每个PeerConnection API生成一个ICE代理，当一个新的ICE候选连接可用时，ICE代理将通过一个回调函数通知应用程序。当所有的候选地址搜集齐之后，回调函数也会通过触发来通知应用程序已经完成搜集工作。

STUN需要一个公网IP的STUN服务器，使防火墙后的客户端找出自己的公网地址，这可以完成92%的穿越。大约8%的概率无法通过上述方式成功建立连接时就需要采用中继服务器，即采用TURN协议。

2.传输机制

WebRTC的传输模块重用了LibJingle的部分组件，WebRTC技术在浏览器内部集成了一系列的网络传输及会话控制相关协议。传输及会话控制的实现重用了Libjingle项目的部分代码。RTP栈是RTP实时传输协议，该协议为实时媒体应用提供了一个传输音频和视频数据的方案。