WebRTC开发者社区为开发者提供最新最全的WebRTC资料
目录
  • 首页
  • WebRTC概念与基础
  • WebRTC项目与应用
  • WebRTC教程资料
  • WebRTC开发资源
  • WebRTC源码分析
  • WebRTC服务端开发
  • WebRTC网络与通信
  • WebRTC编码与解码
  • WebRTC问题与缺陷
  • WebRTC-Androd端开发
  • WebRTC-RFC文档

WebRTC TURN协议初识及turnserver实践

2019-11-28 09:59:04

WebRTC协议栈

图一 WebRTC stack

TURN的全称为Traversal Using Relays around NAT,是STUN/RFC5389的一个拓展,主要添加了Relay功能。如图一所示,TURN协议是建立在UDP协议之上的一个应用层协议。如果一台主机处于NAT后面,那么在一定条件下(NAT穿透失败)两台主机无法之间进行通讯。在这种条件下,那么使用中继服务提供通讯是有必要的。TURN协议允许一台主机使用中继服务与对端进行报文传输。TURN协议也是ICE(交互式连接建立)协议的组成部分,也可以单独使用。如果TURN使用于ICE协议中,relay地址会作为一个候选,由ICE在多个候选中进行评估,选取最合适的通讯地址。一般来说中继的优先级都是最低的。

TURN和其他中继协议的不同之处在于,它允许客户端使用同一个中继地址(relay address)与多个不同的peer进行通信。如图二所示。

图二 同一个中继地址和多个peer通信


Turn协议工作原理

Turn协议的工作原理主要有三个阶段,也称三大机制。分配(Allocation),转发(Relay)和信道(Channel)。

1.分配机制:

客户端想要使用中继功能,需要在中继服务器上申请一个中继地址。客户端发送分配请求(Allocate request)到服务器,服务器为用户开启一个relay端口然后返回分配成功响应,并包含了分配的地址。

图三 Allocation Mechanism

a) 客户端A向STUN Port发送Allocate请求(图中绿色部分)。

b) STUN服务器接收到客户端A的Allocate请求,服务器一看是Allocate请求,则根据relay端口分配策略为A分配一个端口。

c) 服务器发送response成功响应。在该response中包含XOR-RELAYED-ADDRESS属性。该属性值就是A的relay端口。

d) 客户端接收到response后,就知道了自己的relay地址。该relay地址是个公网地址,可以看作是客户端A在公网上的一个代理,任何想要联系A的客户端,只要将数据发送到A的relay地址就可以了。

2.转发机制:

任何想要联系客户端A的人,只要知道客户端A的relay地址就可以了。

client和peer之间有两种方法通过中继服务器交换数据。第一种是使用relay,第二种使用channel。两种方法都通过某种方式告知服务器哪个peer应该接收数据,以及服务器告知client数据来自哪个peer。

Relay Mechanism使用了Send和Data指令(Indication)。其中Send指令用来把数据从client发送到server,而Data指令用来把数据从server发送到client。

图四 Relay Mechanism

如上图所示是B主动给A发消息:“Hello”,A回应“Hi”的过程。

a) 序号1、2、3、4、5为B的发送请求(蓝色箭头方向);

b) 序号6、7、8、9、10为A的回应,原路返回(绿色箭头方向)。

c) 1、2阶段时,发送的是裸的UDP数据。

d) 第3阶段是:从A的relay端口收到数据,添加STUN头后,最后从STUN Port 发出的过程

e) 在4、5过程中,是被STUN协议包装过的“Hello”,称之为Data indication。为了能够让客户端A知道这个包是哪个客户端发来的,所以,STUN 协议对“Hello”进行了重新的包装,最主要的就是添加了一个XOR-PEER-ADDRESS属性。

f) 6、7阶段为被STUN协议包装过的“Hi”,称之为Send indication。为了能够让A的relay port知道最终发往哪个客户端,因此也为“Hi”添加了STUN头,也是添加了XOR-PEER-ADDRESS属性。

g) 第8阶段是:从STUN Port 接收到带STUN 头的数据,去掉STUN头,最后从A的relay端口发出的过程。

h) 9、10是裸的UDP数据。

3.信道机制:

对于一些应用程序,比如VOIP,在Send/Data Indication中多加的36字节格式信息会加重客户端和服务端之间的带宽压力。为改善这种情况,TURN提供了第二种方法来让client和peer交互数据.该方法使用另一种数据包格式,即ChannelData message,信道数据报文。

ChannelData message不使用STUN头部,而使用一个4字节的头部,包含了一个称之为信道号的值(channel number),每一个使用中的信道号都与一个特定的peer绑定,即作为对等端地址的一个记号。

要将一个信道与对等端绑定,客户端首先发送一个信道绑定请求(ChannelBind Request)到服务器,并且指定一个未绑定的信道号以及对等端的地址信息。

图五 Channel Mechanism


如图五所示,中继服务器将数据封装成channel message发送给peer。对比图四,其实就是讲4/5/6/7的indication换成channel message。

在音视频的传输应用中,使用信道机制会大大减少包头长度,节省带宽占用,提高传输效率。

Turnserer实践

部分政府、企业客户会部署有防火墙将办公环境与外网隔离开来,而且其防火墙通常会有很严格的ip和port限制,所以点对点传输基本无法进行。此时,Turn协议就是一个很好的选择。Turnserver具有固定的公网ip,固定的端口,只需在防火墙上开通其白名单,就可以搭建通信信道。

Agora在Web端提供了很好的解决方案:WebProxy。

图六 WebProxy

如图六所示,WebProxy包含信令和数据两个中继服务器,Turnserver主要负责音视频数据的传输。Turnserver为用户开放一个TCP和一个UDP的端口,用户通过这两个端口创建中继地址,后端服务通过中继地址和内网的用户进行数据传输。

后记

TURN协议在实时音视频中是一个比较重要的协议,能很好的保证实时音视频传输中连接的可用性,稳定性和高效性。但是TURN协议对服务器有很高的依赖,服务器在带宽和集群上有很大的压力,所以TURN协议通常是当作ICE协议中的一部分来使用。

By:rasp | WebRTC概念与基础 |

  • 分类目录

    • WebRTC概念与基础 (225)
    • WebRTC项目与应用 (33)
    • WebRTC教程资料 (38)
    • WebRTC开发资源 (13)
    • WebRTC源码分析 (12)
    • WebRTC服务端开发 (23)
    • WebRTC网络与通信 (26)
    • WebRTC编码与解码 (15)
    • WebRTC问题与缺陷 (2)
    • WebRTC-Androd端开发 (2)
    • WebRTC-RFC文档 (1)
  • 最新文章

    • 音视频相关的书籍,多媒体技术
    • SFU级联解决方案——Jitsi
    • SFU级联解决方案——Licode
    • Janus源码分析(6)——Streaming分析
    • janus Streaming插件推流指南
    • 流媒体服务器 
    • WebRTC+libwebsockets+Janus的秒开实践
    • 基于WebRTC的直播CDN
    • 不需要SFU实现WebRTC联播实践  
    • webrtc 开启Simulcast功能
    • Migrating your native/mobile application to Unified Plan/WebRTC 1.0 API
    • WebRTC源码分析rfc4588 RTP重传有效载荷格式
    • WebRTC网关服务器搭建:开源技术 vs 自行研发
    • WebRTC网关服务器搭建:开源技术 vs 自行研发
    • 自研WebRTC网关服务器架构的实践之路
    • WEBRTC三种类型(Mesh、MCU 和 SFU)的多方通信架构  
    • janus的videoroom插件
    • WebRTC+libwebsockets+Janus的秒开实践
    • Janus源码分析(7)——videoroom分析
    • Janus源码分析(5)——echotest分析
    • Janus源码分析(4)——信令交互过程
    • WebRTC+libwebsockets+Janus的秒开实践
    • 前向纠错码(FEC)的RTP荷载格式
    • WebRTC 开发实践:从一对一通话到多人会议
    • Distord如何使用WebRTC处理250万用户同时进行的音频交流
    • 了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化
    • 基于WebRTC技术的多人音视频解决方案
    • 谁是最好的WebRTC SFU?
    • WebRTC媒体服务器
    • 使用Janus作为对讲服务器的后台框架和业务流程
  • 链接

    • WebRTC官网
    • xSky 实验室
    • 树莓派技术圈
    • 声网 Agora
    • WebRTC中文网
    • web性能权威指南
    • WebRTC官网
    • webrtc在线源码
    • webrtc在线源码
    • webrtc
    • webrtc示例
    • LiveVideoStack
    • 雷霄骅(leixiaohua1020)的专栏
  • 开源项目


Powered By xblog Copyright 0xsky.com All Rights Reserved.

Copyright WebRTC.ren All Rights Reserved.