WebRTC网络基础九、第五节 TURN协议

深碍√TFBOYSˉ_ 2023-02-26 07:30 17阅读 0赞

今天我们来介绍一下TURN协议，那么TURN协议出现的目的是什么呢？

### 其目的是解决对称NAT无法穿越的问题 ###

在之前我们介绍过，NAT的四种类型(完全锥型NAT (Full Cone NAT)、地址限制锥型NAT(Address  Restricted Cone NAT)、端口限制锥型NAT (Port Restricted Cone NAT)、对称型NAT (Symmetric NAT))。

当我们检测到一端是[端口受限锥型一端是对称型或者两端都是对称型，那肯定是无法穿越的][Link 1]；在NAT无法穿越的时候，我们如何才能保证业务的运行呢？那这个时候就要引入TURN协议，TURN协议实际上就是在服务端架设一个TURN服务，客户端在发送数据的 时候无法NAT穿越的时候将这个媒体流数据首先传给TURN服务，通过TURN的中介然后转给其他的接收者，或者其他接收者也可以发送数据给这个TURN服务，TURN在转给client端。这就是TURN 出现的目的。

### 其建立在STUN之上，消息格式使用STUN格式消息 ###

上次我们说了STUN协议的头和body是什么样子的，那TURN协议就是建立在STUN协议之上的，它的协议头和body几乎是一样的，只是里面的一些属性和内容不一样，外壳形式什么的都是一样的，所以很多服务器都是将STUN协议和TURN协议放在一起形成了一个服务器，就是既提供STUN的功能又提供TURN的功能 。

### TURN Client要求服务端分配一个公共IP和Port用于接收或发送数据 ###

实际上在进行TURN协议的时候我们应该将它分成两类，一类是TURN Client一类是服务端，这与我们之前介绍的STUN是一样的，就是客户端服务器模式，那如何在这个TURN服务器上提供这种中继服务呢？那首先要TURN Client向TURN 服务端发送一个请求，发送了请求之后就就在服务端根据这个请求建立一个公共的IP地址和端口用户接收和发送数据 。那么对端（TURN client想要通讯的 对端）其实是不需要是一个TURN Client端的，它只需要正常的发送UDP包就可以了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h5cGhm_size_16_color_FFFFFF_t_70][]

下面我们讲个具体的例子，上图是讲述整个TURN  Client端去请求服务，服务端创建相应的公网IP地址和端口提供服务，以及与各个Peer终端进行交互的一个图，由上图我们可以看的有个TURN client端和一个TURN Server端以及两个Peer对端 ，首先我们来看看他们是怎么通讯的；首先一个TURN Client端是在一个NAT之后的，这个时候TURN Client端它要发送一个请求给这个TURN Server，那么TURN Server是在另外一个网络地址，端口是3487，TURN Client在向TURN Server发送请求的时候会形成一组映射地址(出口)地址. 此时TURN Client发送一个Arrow的请求到TURN 服务端，TURN Server收到请求之后就会另外开通一个服务地址 192.0.2.15的地址端口是50000来提供这种UDP中转的这种服务，所以STURN对同一个 Client端来说有两个端口，一个是与TURN Client端连接的端口，另外一个是提供中转的端口50000，如果它现在与Peer B进行通讯，Peer B与TURN Server是在同一个网段，地址是192.0.2.210端口是49191，这个时候它就可以向中转的TURN Server中转的去发数据了。同样的他们建立连接之后 ，TURN  Server也可以给这个Peer B发送数据，那这个时候Peer B如果发送数据到 50000这个端口，在TURN server的内部就会转到3478然后最终中继给这个TURN Client端；同样的如果TURN Client端想给Peer B发送消息的时候，它是先发到3478端口，然后经过内部的中转转成UDP然后再给Peer B，这就是它的一个逻辑。

那同样的在一个 NAT 之后的一个 Peer A也是可以通讯的，那么在通讯之前它首先要穿越NAT，在NAT上形成一个映射的IP地址也就是192.0.2.150端口是32102，所以对TURN Server来说它可以识别这个IP地址和端口就是这个地址，那如果与Peer B 进行通讯的时候，它就通过50000这个端口向这个32102端口发送消息，那么Peer A就收到了。相反的如果Peer A要给这个TURN Client端发送数据的时候，它就是往192.0.2.15:50000这个端口发数据，从这个端口又转到3478这个端口，最终传给TURN Client端。

这就是整个TURN中转的基本的例子。通过这个例子大家就很清楚它是怎么工作的。

# TURN使用的传输协议 #

![20200714210536635.png][]

TURN Client 到TURN server使用的UDP、TCP包括加密后的TCP都是可以的，而对于TURN Server到Peer端，使用的都是UDP，所以这块大家一定要清楚；

# TURN Allocate  #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h5cGhm_size_16_color_FFFFFF_t_70 1][]

那各个端如何让TURN Server提供通讯服务呢？它就要发送一个Allocate请求，在客户端首先发送一个Allocate请求到Server端，在Server首先是要做一些鉴权的处理，如果发现请求没有相应的权限，就返回一个401，就是无权限未授权的 ，整个底层用的都是STUN的消息格式，TURN Client收到这个未授权的消息之后它会重新再发一个请求这次会把鉴权信息也带过来给Server端，Server端这时候鉴权就通过了，然后返回一个成功应答 ，就是我给你提供的IP地址和端口是多少？这个时候Client就能和Peer  A和Peer B进行通讯了，那在这之前通过Peer A和Peer B它要通过一个信令服务器那要拿到他们相应的地址，否则的话还是没法通信的；在这个前提之下如果中继服务已经开通了，TURN Client就可以源源不断的向TURN Server发送数据，然后TURN Server通过50000这个 端口给Peer A和Peer  B进行转发；相反的如果Peer A 和Peer B给50000这个端口发数据，它就会被传给这个TURN 端；除此之外这个TURN Client端还要发送一个Refresh请求，实际上就是保活用的相当于心跳。在TURN Client端要求这个TURN Server分配 一个服务之后它是有一定的超时时间的，有可能是10分钟有可能是20分钟或者你设置为1个小时，那这个在这个设置时间段之内它是活着的，超过十分钟如果没有这个Refresh request刷新请求的话，那这个服务就算是失效了。那如果在失效之前它收到这个心跳,它就返回了一个成功，继续演示上面设置的一段时间，这就是它整体的一个分配和保活的一个逻辑。

# TURN 发送机制 #

**Send和Data**

整个服务开通之后就涉及到对数据的发送了，那TURN有两种发送数据的机制，第一种就是Send和Data。

首先我们看Send和Data，要求服务端开启这个服务之后呢，紧接着就可以发送数据了，那在发送数据之前首先要鉴权，检查是否有发送的权限，这个完成之后它就来发数据，那么首先客户端向服务端发送数据，信令是Send，发送到服务端，服务端收到数据之后需要将TURN协议头给去掉，拿到里面的数据 ，里面的数据就是原始的UDP数据，拿到这个数据之后直接通过刚才的 5000端口转给你想转发的对端Peer A，那么数据就到Peer A，Peer A如果想给这个TURN Client发送数据，那它发的是UDP数据，那到了中继服务之后，中继服务STUN首先给它加一个消息头，加了消息头之后再通过这个TURN Client转给这个TURN Client端，所以这个Send和Data一个是表示上行一个是表示下型行。这就是TURN 的Send和Data的含义。

**Channel**

第二种是Channel。相比Channel的一个缺点就是在每次发送消息的时候都要带一个30多个字节的头，这个对于一般的情况下其实是不受影响的，但是因为我们传输的是流媒体数据，它的数据量非常大 ，如果每个数据包都带一个30多个的字节头那对整个带宽是有很大影响的。那如何去解决这个问题呢？

有了另外一种数据传输方式就是Channel，Channel方式就是大家规定一个Channel  Id，我们都相当于加入了这个管道中，有了这个 管道我们就不用每次都带着这个头消息告诉你这是什么？一些基本信息在这里我们一开始就创建好了，我们都在管道里，我们现在只要发送数据就好了

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h5cGhm_size_16_color_FFFFFF_t_70 2][]

在Channel模式下，首先客户端要发送一个ChannelBind绑定请求，服务端收到这个请求之后给它一个响应，绑定这个ChannelId就是这个16进制的0x4001,就是随便一个数它都能随机产生的，当然不能重复，那当整个Channel创建成功之后，Client端就可以发送数据给Server那这个Server就可以转发数据给这个Peer A，同样的如果Peer A如果想转发数据给这个TURN Server，那TURN Server再中继通过channel就转给这个Client端了。

那在这个时候另外一种方式，就是Send和Data这种方式其实是可以继续发送的，也就是说Send、Data和Channel这两种方式是可以并存的，可以混着发的，这就是Channel。

# TURN的使用 #

TURN的使用，尤其是在WEBRTC中我们怎么使用，首先是发送一个绑定，要进行这个打通，就是客户端到服务端要打通要拿到它的映射IP地址 ，之后发起方Caller要调用allocation，就是让TURN Server开辟一个服务接收我发送数据的IP地址和端口，就是一个中继的IP地址和端口，那整个服务开通之后，这个Caller获取了基本的信息，然后通过信令将这个SDP也就是说一些媒体信息还有网络信息通过这个 SDP的offer发送该这个被调用者；对方收到这个信息之后也要给这个TURN服务发送一个allocation，也要创建一个这样的服务，用来接收对方的数据，那这个创建成功之后，因为这个Caller给它发了一个Offer然后它要回一个answer，这样他们整个数据交换就交换完了，在交换的过程中实际就是将这个candidate，我们说SE的时候回说到这个candidate,它是一个候选者，相当于我每一个IP地址和端口都是一个候选者，就是有可能进行网络传输的一个地址，所以把它叫做candidate，就是将这个 candidate的这个地址进行交换，那它这个信息就交换了，那交换完成之后通过这个ICE这个框架，首先检查P2P能否成功，因为最高的传输效率还是端对端之间，它不经过第三方的服务也不受第三方的服务带宽的影响，只要双方的带宽够就好了，这个是最基本的，所以它是最高效的，所以首先检查 P2P是否能够打通NAT，如果打不通的话，这个时候就要通过中继，向对方所开通的端口去发送数据，这样另一方就能收到，同样的，另一方想要发送数据也给对方的中继服务发送数据就好了，那么以上就是整个TURN相关的一些基本的知识。

[Link 1]: https://blog.csdn.net/xyphf/article/details/107297616
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h5cGhm_size_16_color_FFFFFF_t_70]: /images/20230209/10fd272ccdc74e9b9714329b0fb493e9.png
[20200714210536635.png]: /images/20230209/8cea3e28b65645a3a106a80eb3db1a1e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h5cGhm_size_16_color_FFFFFF_t_70 1]: /images/20230209/7a1ee36b56684f6ea56b78b4cf78500c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h5cGhm_size_16_color_FFFFFF_t_70 2]: /images/20230209/b0be4bdb521e43fbbff33e327c9b9279.png