Allocate请求
客户端通过发送Allocate请求给STUN服务器,从而让STUN服务器为A用户开启一个relay端口。
摘要
如果一台主机处于NAT后面,那么在一定条件下两台主机无法之间进行通讯。在这种条件下,那么使用中继服务提供通讯是有必要的。
这个规范定义了一个名为TURN(使用中继穿越NAT)的协议,它允许一台主机使用中继服务与对端进行报文传输。TURN不同于其它中继协议在于它
允许客户机使用一个中继地址与多个对端同时进行通讯。
TURN协议也是ICE(交互式连接建立)协议的组成部分,也可以单独使用。
在现实Internet网络环境中,大多数计算机主机都位于防火墙或NAT之后,只有少部分主机能够直接接入Internet。很多时候,我们希望网络中的两台主机能够直接进行通信,即所谓的P2P通信,而不需要其他公共服务器的中转。由于主机可能位于防火墙或NAT之后,在进行P2P通信之前,我们需要进行检测以确认它们之间能否进行P2P通信以及如何通信。这种技术通常称为NAT穿透(NAT Traversal)。最常见的NAT穿透是基于UDP的技术,如RFC3489中定义的STUN协议。
STUN,首先在RFC3489中定义,作为一个完整的NAT穿透解决方案,英文全称是Simple Traversal of UDP Through NATs,即简单的用UDP穿透NAT。
在新的RFC5389修订中把STUN协议定位于为穿透NAT提供工具,而不是一个完整的解决方案,英文全称是Session Traversal Utilities for NAT,即NAT会话穿透效用。RFC5389与RFC3489除了名称变化外,最大的区别是支持TCP穿透。
TURN,首先在RFC5766中定义,英文全称是Traversal Using Relays around NAT:Relay Extensions to Session Traversal Utilities for NAT,即使用中继穿透NAT:STUN的扩展。简单的说,TURN与STURN的共同点都是通过修改应用层中的私网地址达到NAT穿透的效果,异同点是TURN是通过两方通讯的“中间人”方式实现穿透。
RFC3489的劣势:一、NAT穿透有时会失败,但没有失败补救措施;二、NAT分类算法不适用于现代的很多NAT类型;三、安全弱点。
与RFC3489不同,该文档不再把STUN描述为解决NAT穿透的完整解决方案,而是将STUN作为一种工具集成到其他更完备的解决方案中去,例如本协议的扩展可用于ICE的两个端点之间的连接检测、用于TURN的的两个端点之间的包中转、用于SIP的客户端初始化连接。
该文档描述的STUN可运行在UDP、TLS/TCP、TCP上。
Stun协议的格式,定义在https://www.ietf.org/rfc/rfc3489.txt
11.1 Message Header All STUN messages consist of a 20 byte header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | STUN Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Transaction ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
STUN的探测过程需要有一个公网IP的STUN server,在NAT后面的UAC必须和此server配合,互相之间发送若干个UDP数据包。UDP包中包含有UAC需要了解的信息,比如NAT外网IP,PORT等等。UAC通过是否得到这个UDP包和包中的数据判断自己的NAT类型。
假设有如下UAC(B),NAT(A),SERVER(C),UAC的IP为IPB,NAT的IP为 IPA ,SERVER的 IP为IPC1 、IPC2。请注意,服务器C有两个IP,后面你会理解为什么需要两个IP。
Restund is a modular and flexible STUN and TURN Server, with IPv4 and IPv6 support.
1) Requirements
In order to compile TurnServer, you need the followings packages :
本人最早接触WebRTC是在2011年底,
那时Google已经在Android源码中加入了webrtc源码,放在/external/webrtc/,
但是Android并没有用到它,更没有被浏览器使用。
当时试图在Android 2.3(Gingerbread)高通平台的手机上
用H.264 硬件codec替换掉WebRTC缺省使用的VP8软codec,费了不少劲勉强换掉后效果很差只得放弃。
最近得知Google最新版的Chrome for Android已经支持WebRTC,
应老板的要求搭一个手机浏览器上视频通信的demo,
为此在网上搜集各种资料,发现经过一年多的发展,
国内外研究和使用WebRTC的人明显多起来,可用的demo也很多。
在此做一个笔记,留作日后参考。
目前基于WebRTC的开发其实有两个方向,
一个是基于浏览器的WebRTC应用开发,编程语言主要是JavaScript、HTML等,
这也是WebRTC作为HTML5标准的组成部分原本的目的;
前段时间上手了NAT打洞类库ice4j(ICE框架),当时使用了numb.viagenie.ca的公共STUN服务器。最近又编译了rfc5766-turn-server,于是今天将两者结合起来,一个作为服务端,一个作为Peer端的协议,试验广域网穿透多级路由即时点对点通讯,并取得了成功。
rfc5766-turn-server是谷歌推荐的turn开源项目,经常作WebRTC的服务器端使用。关于rfc5766-turn-server在Windows或Ubuntu(Linux)下的编译,请参考 http://www.hankcs.com/program/network/compile-rfc5766-turn-server-to-build-turn-server.html 。这里假定你已经编译完成,输入
得到如下结果说明编译成功: