假如你在企业内使用WebRTC,可能会遇到UDP端口被封的情况,这个时候可以强制WebRTC使用TCP转发模式。
要使用TCP转发,得配合一个 turn server,开源的 coturn 实现了 TCP 转发,我在“Ubuntu Server 14.04下配置coturn for WebRTC”一文中介绍了如何安装配置,可以参考。
配置了 coturn 后,在 Chrome 内建立 PeerConnection 对象时,做个配置,就可以实现转发了,类似下面:
假如你在企业内使用WebRTC,可能会遇到UDP端口被封的情况,这个时候可以强制WebRTC使用TCP转发模式。
要使用TCP转发,得配合一个 turn server,开源的 coturn 实现了 TCP 转发,我在“Ubuntu Server 14.04下配置coturn for WebRTC”一文中介绍了如何安装配置,可以参考。
配置了 coturn 后,在 Chrome 内建立 PeerConnection 对象时,做个配置,就可以实现转发了,类似下面:
你在下载的时候,有没有体验过 P2P 下载,能够让你的网速从 10KB 直接提升到 10MB? 你在企业内传输文件的时候,有没有体验过文件秒传? 你在看直播的时候,想不想用别人的流量看直播呢? ...
能做到上面这些场景的技术,叫做 P2P。P2P 技术中,最出名的叫做 WebRTC。WebRTC 是一个含金量非常高的技术。做好的话你可以养活一家公司,做不好,那就只能是一个 demo。
WebRTC 虽然能做很多事,但是并不是所有场景都适合。最大的使用场景是 两个终端在同一个 NAT 内,简单来说,都在一个 wifi 内。这个场景中,最显著的效果就是带宽无限并且高速,你走的就是内部的线路,根本不消耗运营商的流量。
P2P 技术在基于 WebRTC 标准下,可以做很多事情:
近几年网络直播视频、VR/AR、竞技游戏、大数据、4K高清视频的快速增长,正在将毫秒级网络加速技术推向历史发展的潮头。用户的预期越来越高,他们期待“最好”的在线体验,网络延迟会直接影响到应用的转化率。即有多少人可以变成你的客户,现在用户的体验和忠诚度已经不能用“分钟”和“秒”来衡量,而是用“毫秒级”来衡量,每个毫秒都会对用户的转化和体验有影响。
比如说在线教育类用户就希望视频直播的端到端延迟能够严格控制在500毫秒以内,使之具备和视频连麦相同的低延迟体验。那现在的CDN加速技术还能起作用吗?首先数据不能有cache,TCP的延迟累积必须消除,甚至RTMP协议也要切换到WebRTC的技术架构。移动互联网的实时视频应用领域正在快速演变中的一切,我们先姑且称之为网络延迟革命吧。
端到端通信的一个主要问题是,在许多情况下,这些端点并不在公共互联网中,而是位于网络(和端口)地址转换器(NAT)后面的专用地址空间中。随着互联网从DARPA项目发展成为全球范围的网络,很快就会明白IPv4的232地址空间早晚会用尽。
在20世纪90年代,开发了多种策略来延迟IPv4地址耗尽的时间,其中之一就是NAT的设计。NAT将端点的真实IP地址隐藏于世界其他地方,这使得端点之间建立端到端直接连接变得困难。这就是协助框架—包括STUN和TURN(或使用中继NAT穿越)—派上用场的地方。
平均约有30%的P2P会议有一个端点通过TURN服务器连接。如果没有TURN中继服务器的帮助,这些用户将无法进行通信。因此,开发者需要知道TURN服务器是什么,以及为什么它对WebRTC通话的重要性。
ICE和STUN
在讨论TURN之前,我们需要定义两个缩略词。
ICE是交互式连通性建立(Interactive Connectivity Establishment)的缩写,它定义了一种系统化的方式来寻找两个端点(通过NAT和防火墙)之间可能的通信选项,包括必要时使用中继。
STUN是NAT的会话遍历实体(Session Traversal Utilities for NAT)的缩写。STUN向请求端点提供其公共IP地址。STUN是一个相对轻量级的过程,之所以是轻量级是因为一旦STUN为请求者提供了可公开访问的IP地址,它就不再参与对话了。
当一个端点在NAT后面时,它只能看到它的本地IP地址。通话中的其他端点将无法使用此本地IP地址连接到端点,因为它可能是专用地址,或者防火墙不允许进行访问。在这种情况下,该端点可以要求STUN服务器提供其公共IP地址。参与者然后使用ICE过程并尝试使用公共IP地址建立连接,并且如果连接成功建立,则媒体直接在用户之间流动,而没有任何主动中继。处于所有实际的目的,STUN就会退出,然后等待下一次使用。
但是,上述情况只对某些NAT有用。在一些NAT实现中,端口将被转换为其他端口以及它所连接的IP地址。这种情况被称为“对称NAT”。STUN过程的公共IP地址不足以建立连接,因为端口也需要进行IP地址转换。
这就是为什么TURN服务器至关重要的原因。
我遇到的麻烦NAT traversal
和WebRTC
。Videostreaming适用于某些人,但不适用于学生宿舍路由器后面的人。
我认为这应该通过使用TURN服务器来解决。我已经这样做了,它仍然无法正常工作,现在我想知道TURN服务器是否可以工作。因此,我想知道我是否可以或应该设置几台TURN服务器,如果是,如何。
现在我正在设置他们这样
WebRTC enables peer to peer communication.
BUT...
WebRTC still needs servers:
- For clients to exchange metadata to coordinate communication: this is called signaling.
- To cope with network address translators (NATs) and firewalls.
In this article we show you how to build a signaling service, and how to deal with the quirks of real-world connectivity by using STUN and TURN servers. We also explain how WebRTC apps can handle multi-party calls and interact with services such as VoIP and PSTN (aka telephones).
If you're not familiar with the basics of WebRTC, we strongly recommend you take a look at Getting Started With WebRTC before reading this article.
目录:
1 说明
2 打洞和穿越的概念... 1
3 P2P中的打洞和穿越... 2
4 使用STUN系列 协议穿越的特点... 2
5 STUN/ TURN/ICE协议的关系... 3
6 STUN协议(RFC 5389) 3
实现一个WebRTC demo是比较容易的, 但如果要做一个webrtc产品, 则需要在任何网络环境下都能够建立网络连接.
多数联网设备都位于局域网中, 并位于防火墙后面, 设备本身只有一个内网的私有IP, 在与外部通信时, 会经过1个或多个NAT路由器, 最终得到一个最外端的一个外部IP, 然后与远端目标机器通讯. 这一网络结构对于web应用, c/s型应用等来说不是问题, 但对于VoIP/P2P等应用就是一个问题了. 通信双方并不知道自己或对方的outermost的外网IP:Port, 如何建立直连呢?
这时就需要NAT穿透, 目前WebRTC采用的是ICE框架 (ICE+STUN+TURN), ICE也适用于非WebRTC应用, 这是目前业界用于穿透NAT的标准方案.
ICE使用了STUN, TURN等技术, 并扩展了SDP. ICE会同时尝试找出两个机器可行的连接方式, 并选择一个最高效的连接方式来穿透NAT. 参考文档:
首先要掌握WebRTC连接建立过程,需要掌握几个知识点: NAT, ICE, STUN, TURN, DTLS等。如果之前有接触过P2P相关技术的同学可能就会比较容易理解。WebRTC是一个基于浏览器与浏览器之间的实时音视频通话方案,那么有于公网ip地址有限的问题,用户的浏览器常常位于NAT后,那么建立连接就涉及到了打洞技术。
NAT
由于当前使用的IPV4地址的长度限制只有32位,大多数终端都没有一个可以在互联网上可见的唯一IPV4地址。NAT是作为一种解决IPv4地址短缺以避免保留IP地址困难的方案,在IP数据包通过路由器或防火墙时重写来源IP地址或目的IP地址。
STUN
为了进行P2P通信,会话参与双方都需要知道其对等端的IP地址和指定的UDP端口。因此,在WebRTC通信建立之前,需要进行一定数量的信息交换。
每个对等端需要使用一个STUN服务器来探测他们的公共IP地址,这个IP在连接建立的时候会被ICE框架所引用。STUN服务器是通常是可公开访问的,WebRTC应用可以自由访问。
TURN
TURN服务指的是中继型NAT遍历服务器,其地址是一个公共ip地址,用于转发数据包给对端浏览器。当2个对等端因为NAT类型而无法建立连接时(当遇到对称型NAT会导致打洞失败),才需要使用中继服务器。
ICE: 交互式连接建立(Interactive Connectivity Establishment)
ICE是一种标准穿透协议,利用STUN和TURN服务器来帮助端点建立连接。WebRTC当通过信令server交换完sdp, candidate后,之后依靠ICE框架在2端之间建立一个通道。
ICE的过程主要分为5步:
WEBRTC ICE 简介
在这里,我会介绍一下WEBRTC 中, ICE 的机制。主要分为三个部分。
第一部分,为ICE的协议部分介绍。
第二部分,为STUN 的信令连接图。
第二部分,为WEBRTC中代码的实现流程。