WebRTC之STUN与TURN以及ICE

在现实Internet网络环境中,大多数计算机主机都位于防火墙或NAT之后,只有少部分主机能够直接接入Internet。
很多时候,我们希望处于不同内部网络中的两台主机能够直接进行通信,即所谓的P2P通信,避免通过其他公共服务器的中转的方式来降低实时通信的延迟。
由于主机可能位于防火墙或NAT之后,在进行P2P通信之前,我们需要进行检测以确认它们之间能否进行P2P通信以及如何通信。
这种技术通常称为NAT穿透(NAT Traversal),而更多关于NAT的介绍我们在《WebRTC之NAT穿墙》已经做了简单的介绍。

如果对NAT穿透还不了解的话建议先温习一下。

而今天的主角是STUN、TURN和ICE,它们是实现NAT穿透的不同技术方案。

image

STUN

STUN,首先在RFC3489中定义,作为一个完整的NAT穿透解决方案,英文全称是Simple Traversal of UDP Through NATs,即简单的用UDP穿透NAT。

在新的RFC5389修订中把STUN协议定位于为穿透NAT提供工具,而不是一个完整的解决方案,英文全称是Session Traversal Utilities for NAT,
即NAT会话穿透。STUN在RFC5389与RFC3489中除了名称变化外,最大的区别是在新的定义中支持TCP穿透。

STUN是典型的客户端/服务器模式,客户端发起请求,服务端进行响应,默认端口是3478。

两种STUN规范:分别是RFC3489RFC5389

RFC3489通过UDP进行穿墙。目前的服务器对于UDP的限制比较多,导致这种模式穿墙的成功率不高。

RFC5389是在RFC3489的升级版,但是含义确是不一样的,一系列的穿墙攻击,纳入了TCP穿墙。

所有的STUN消息都包含20个字节(每个字节占8位,总共是160位)的消息头,其中2个字节(也就是16位)的消息类型,
2个字节的消息长度,这个长度不包含消息头的长度还有16个字节的事务ID,请求与响应事务ID相同。

消息头之后就是是消息体,消息体可以是0或多个属性,每个属性进行TLV编码,包括16位的属性类型、16位的属性长度和变长属性值。

更加具体的消息交互协议笔者目前还不打算深入研究,因为目前我的目的是为了学习并使用WebRTC,还没到达弄清楚WebRTC的每一个细节点的高深境界。

四种主要NAT类型中有三种是可以使用STUN进行穿透:完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT,对称型NAT则不能使用。

那么对称型NAT如何实现P2P通信呢

TURN协议

上面说到对称型NAT无法使用STUN成功进行穿透,这时候就需要TURN出场了。

TURN协议的目的就是为了解决对称型NAT无法穿越的问题。

TURN(Traversal Using Relay NAT,通过Relay方式穿越NAT),是一种数据传输协议。允许通过TCP或UDP方式穿透NAT。
TURN也是一个Client/Server协议,也和STUN使用同样的消息格式。

但实现TURN client的终端必须在通讯开始前与TURN server进行交互,并要求TURN server产生"relay port",也就是中继转发地址。
这时TURN server会建立peer,即远端端点(remote endpoints),开始进行中继(relay)的动作,TURN client利用relay port将数据传送至peer,再由peer转传到另一方的TURN client。

说白了笔者觉得TURN协议更像一个中继转发协议,并不是真正意义上的P2P通信(不知道笔者这样的理解对不对)

ICE

ICE(Interactive Connectivity Establishment,互动式连接建立)。ICE定义了穿越方法而不是协议。

既然我们NAT穿透可以使用STUN也可以使用TURN,那么什么时候使用STUN什么时候使用TURN呢?这就是ICE做的事情。

更通俗地讲ICE更像一个NAT穿透的管理者,使用者只需要告诉ICE我要穿墙即可,至于怎么穿墙那就是ICE的事情了。

ICE整合了STUN与TURN。ICE使得两个NAT后的端点通信更加便捷。ICE使用STUN进行打洞,若失败,则使用TURN进行中转。

下面说说ICE的主要工作:

1、收集候选地址也就是收集Candidate

所谓的Candidate就是一个由IP和端口组成的地址。而Candidate又有三种类型:

主机候选者类型(网卡自己的ip地址和端口)

反射候选者类型(经过NAT之后的ip地址和端口)

中继候选者类型(通过TURN服务开通的转发地址和端口)

2、对Candidate Pair进行排序

ICE收集到了候选者地址后,两个对等端都拥有了若干自己和对方的候选地址,并将其配对,组成Candidate Pair。

每对Candidate Pair都有对应的优先级,ICE需要对每对Candidate Pair进行优先级的排序。

3、对候选地址进行连通性检测

ICE对排序好的Candidate Pair进行发送检测和接收检测,发送和检测是同时进行的,如果发送消息出去之后还能收回和发送出去一样的信息则说明连通性是通的

参考资料

《P2P技术详解(四):P2P技术之STUN、TURN、ICE详解》

关注我,一起进步,人生不止coding!!!

微信公号:思想觉悟

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,902评论 5 468
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,037评论 2 377
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,978评论 0 332
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,867评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,763评论 5 360
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,104评论 1 277
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,565评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,236评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,379评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,313评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,363评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,034评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,637评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,719评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,952评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,371评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,948评论 2 341

推荐阅读更多精彩内容