WebrRTC(2) STUN/TURN协议

最新推荐文章于 2023-05-12 00:19:48 发布
最新推荐文章于 2023-05-12 00:19:48 发布
阅读量1k 收藏 3
点赞数
分类专栏： webrtc 文章标签： 网络 网络协议 webrtc
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_39077451/article/details/106839185
版权

STUN

简介

  • STUN（Session Traversal Utilities for NAT),其主要作用就是进行NAT穿越
  • B/S模式

RFC5389/STUN

协议结构

  • 20B的header
  • 消息体中可以有若干个属性
SUTN header
字段大小
Message Type 类型2B
Message Length 消息长度,不算header2B
Magic Cookie 魔数4B
Transaction ID 事务ID12B
Message Type
0                1
0 1  2  3  4 5 6 7 8 9 0 1 2 3 4 5
+--++--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
0 0 |M |M |M|M|M|C|M|M|M|C|M|M|M|M|
    |11|10|9|8|7|1|6|5|4|0|3|2|1|0|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1. 最低两位一定是00,主要是为了不同协议复用同一个端口时，用于标志这是STUN协议
  2. C0和C1用于区别分类
    • 00 : 请求
    • 10 : 成功的响应
    • 11 : 失败的响应
  3. M 占的12bit,用于不同请求的定义

4bit为一组进行划分:

0 0 0 0 | 0 0 0 0 | 0 0 0 0 | 0 0 0 1  => 绑定的请求消息
0 0 0 0 | 0 0 0 1 | 0 0 0 0 | 0 0 0 1  =>  成功响应消息
0 0 0 0 | 0 0 0 1 | 0 0 0 1 | 0 0 0 1  =>  错误的绑定
Magic Cookie

固定为0x2112a442，可以判断客户端是否支持特定的属性

Transaction ID

用于标志同一个事务的请求和响应。
当客户端发送多个请求的时候，可以将请求和响应联系起来

SUTN Body

里面有若干个属性,并且每个属性使用的是TLV编码(Type-Length-Value)

    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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Type                  |            Length             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Value (variable)                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

属性列表:略

TURN

简介

  1. 解决 对称NAT 穿越失败的问题
  2. 客户端如果无法正常穿越建立p2p的时候，将数据先传输给该TURN服务器，然后TURN服务器当做中转的节点，传输给另外一个客户端
  3. 使用的消息格式和STUN一致

使用的传输协议

client -> turn server
  1. UDP
  2. TCP
  3. TLS over TCP

使用流程

  1. 绑定STUN
  2. 发起方进行对TURN 进行 Allocation request
  3. 发起方通过信令服务器发送SDP offer
  4. 对端进行对TURN 进行 Allocation request
  5. 对端接收到发起方的offer后，通过信令服务器响应一个SDP answer
  6. 互相交换candidate IP 端口
  7. 通过ICE框架检测是否能进行P2P连接
  8. 如果无法使用P2P，则需要通过中继服务来进行数据的交换
turn server -> peer

UDP

工作原理

建立连接
A TURN server B Allocate Request 为A分配relay端口 x Allocate Response(分配的端口 x ) 数据发送至端口x 将B的数据转发给A Refresh request Refresh response A TURN server B TURN服务
  1. 此时，其它客户端想和A通信时，只需将数据传输到TURN的x端口就可以了，该x端口会进行消息的转发，传输给A。
  2. 通过Refresh request进行保活操作，类似心跳包，如果超时没有接收到刷新请求，那么这个服务就算失效了
数据传输机制

Send + Data

A TURN server B Allocate Request Allocate Response Send (B) data data Data (B) A TURN server B Send + Data
  1. 和TURN server建立连接
  2. A向TURN server发送数据
  3. TURN server收到数据以后，将TURN协议头去掉，拿到里面的原始UDP数据,直接通过分配的端口 ，发送给A的对端B
  4. 如果B要给A发送数据，则B直接给TURN server分配的端口发送UDP数据
  5. 当TURN server收到B发送的数据时，先将该数据添加上TURN协议消息头,再通过 Data 消息转发给A

Channel
建立管道，每次就可以不用传输头部信息

A TURN server B chennel bind request channel bind response data data data data A TURN server B Channel

此时Send + Data可以和Channel一起使用

抓包

在https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/中进行candidate获取和查看

使用wireshark进行stun/turn抓包
在这里插入图片描述
由图可知:

Binding Request

尝试进行stun绑定

Session Traversal Utilities for NAT
    [Response In: 25]
    Message Type: 0x0001 (Binding Request)
    Message Length: 0
    Message Cookie: 2112a442
    Message Transaction ID: 7650576551702f45515a6f43

和上述协议结构一致，有消息类型、属性长度、魔数，以及事务ID

Allocate Request
Session Traversal Utilities for NAT
    [Response In: 26]
    Message Type: 0x0003 (Allocate Request)
    Message Length: 8
    Message Cookie: 2112a442
    Message Transaction ID: 77593259697564687a5a4758
    Attributes
        REQUESTED-TRANSPORT: UDP

分配地址端口请求,请求一个能进行UDP通信的转发端口

Binding Success Response
Session Traversal Utilities for NAT
    [Request In: 23]
    [Time: 0.052215000 seconds]
    Message Type: 0x0101 (Binding Success Response)
    Message Length: 68
    Message Cookie: 2112a442
    Message Transaction ID: 7650576551702f45515a6f43
    Attributes
        XOR-MAPPED-ADDRESS: 42.49.169.5:3612
        MAPPED-ADDRESS: 42.49.169.5:3612
        RESPONSE-ORIGIN: 139.199.19.250:3478
        SOFTWARE

绑定成功响应,返回了出NAT映射后的公网ip和端口，可发现该Transaction ID和之前进行绑定请求的数据包中字段一致，所以这两个是相关联的。

Allocate Error
Session Traversal Utilities for NAT
    [Request In: 24]
    [Time: 0.040645000 seconds]
    Message Type: 0x0113 (Allocate Error Response)
    Message Length: 92
    Message Cookie: 2112a442
    Message Transaction ID: 77593259697564687a5a4758
    Attributes
        ERROR-CODE 401 (Unauthorized): Unauthorized
        NONCE: ebdeedc2c1e79f7d
        REALM: 139.199.19.250
        SOFTWARE

第一次尝试请求分配中转端口的时候，没有带上验证信息，导致验证失败，当前的Transaction ID和上面Allocate Request的是相同的。

Allocate Request With username & password

当由于认证问题而请求分配失败时，带上验证信息去请求分配端口

Session Traversal Utilities for NAT
    [Response In: 28]
    Message Type: 0x0003 (Allocate Request)
    Message Length: 80
    Message Cookie: 2112a442
    Message Transaction ID: 4d6d49786134713842376d2f
    Attributes
        REQUESTED-TRANSPORT: UDP
        USERNAME: mao
        REALM: 139.199.19.250
        NONCE: ebdeedc2c1e79f7d
        MESSAGE-INTEGRITY

这时是个新的事务，Transaction ID也是和之前发送的数据包无关

Allocate Success Response

当带上验证信息以后，turn服务器成功的为客户端分配了一个转发端口49974

Session Traversal Utilities for NAT
    [Request In: 27]
    [Time: 0.038153000 seconds]
    Message Type: 0x0103 (Allocate Success Response)
    Message Length: 88
    Message Cookie: 2112a442
    Message Transaction ID: 4d6d49786134713842376d2f
    Attributes
        XOR-RELAYED-ADDRESS: 139.199.19.250:49974
        XOR-MAPPED-ADDRESS: 42.49.169.5:3612
        LIFETIME 600
        SOFTWARE
        MESSAGE-INTEGRITY
保活

之后就是发refresh request包来证明客户端并没有掉线了,服务端也会回复一个refresh response包

Refresh Request

Session Traversal Utilities for NAT
    [Response In: 30]
    Message Type: 0x0004 (Refresh Request)
    Message Length: 80
    Message Cookie: 2112a442
    Message Transaction ID: 41527766432f386d67685a6b
    Attributes
        LIFETIME 0
        USERNAME: mao
        REALM: 139.199.19.250
        NONCE: ebdeedc2c1e79f7d
        MESSAGE-INTEGRITY

Refresh Response

Session Traversal Utilities for NAT
    [Request In: 29]
    [Time: 0.032752000 seconds]
    Message Type: 0x0104 (Refresh Success Response)
    Message Length: 64
    Message Cookie: 2112a442
    Message Transaction ID: 41527766432f386d67685a6b
    Attributes
        LIFETIME 0
        SOFTWARE
        MESSAGE-INTEGRITY

debian下安装coturn

安装步骤

1.下载源码

# github上下载
git clone https://github.com/coturn/coturn 

# 进入源码文件夹中
cd coturn

2.安装必要依赖

apt install g++
apt install libevent-dev
apt install libssl-dev
apt install make

2.配置安装目录，检查依赖

./configure --prefix=/usr/local/coturn

3.开始编译安装

# 编译
make -j 2
# 安装
make install

配置/运行

此时/usr/local/coturn/就是coturn的安装路径:

bin  etc  include  lib	man  share  var

进入配置文件夹中

# 进入文件夹中
cd /usr/local/coturn/etc
# 拷贝一份样本然后编辑
cp turnserver.conf.default turnserver.conf
vim turnserver.conf

配置主要的参数:

参数名例子说明
listening-port3478监听端口
listening-ip10.104.250.191内网ip
external-ip139.199.19.250外网ip
usermao:111111账号密码验证
realm139.199.19.250外网域名
cli-password111111必须设置这个参数，否则会报错

添加环境变量

export PATH=$PATH:/usr/local/coturn/bin

运行coturn

# -c 后面是使用的配置文件路径
hohup coturn -c /usr/local/coturn/etc/turnserver.conf &

检测是否正常的部署了服务

进入网站
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

开始测试
填写好服务信息以后，点击Add Server,然后点击Gather candidate,就可以
在下面的表格中会出现每个candidate的详细信息
在这里插入图片描述

一轮满月
关注
  • 0
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
STUN 协议实现源码
04-13
按照rfc3489实现STUN协议的客户端和服务端源码，可以做为研究NAT穿透的很好的资料哦！
STUN/TURN协议
流媒体巅峰之路
07-15 1315
STUN和TURN协议解析 在现实Internet网络环境中，大多数计算机主机都位于防火墙或NAT之后，只有少部分主机能够直接接入Internet。很多时候，我们希望网络中的两台主机能够直接进行通信，即所谓的P2P通信，而不需要其他公共服务器的中转。由于主机可能位于防火墙或NAT之后，在进行P2P通信之前，我们需要进行检测以确认它们之间能否进行P2P通信以及如何通信。这种技术通常称为NAT穿透（NAT Traversal）。最常见的NAT穿透是基于UDP的技术，如RFC3489中定义的STUN协议。
stun协议笔记二（webrtc之turn流程简介）
CrystalShaw的博客
12-12 7109
一、turn典型应用场景 这张图描述的是TURN Client、PeerA、PeerB三方会议之间，网络报文互相通讯的场景。其中： 1、TURN Client客户端、PeerA分别连接到两个内网中，并且通过一个或者多个NAT到达公网。 2、TURN服务器架设在公网中，不同的客户端以TURN服务器为中继和其他peer进行通信。如上图所示：TURN Client客户端通过中继和其他peer进行通...
真正好用的nat穿透源代码，附送STUN检测代码
01-16
网上的原理很多，代码很少，好用的更少，多数都有问题，这个代码是我根据网上的代码修改的，保证好用。还有一些代码是我整理的stun资料。
STUN和TURN技术浅析
02-06
STUN和TURN技术浅析
stun/turn 客户端测试
05-11
标题“stun/turn 客户端测试”指的是一个用于测试COTURN服务器配置是否完成的C#应用程序。COTURN是一个开源的STUN和TURN服务器实现，它允许内置于NAT的客户端通过服务器进行中继通信，以确保在复杂的网络环境中数据...
jfSTUN:STUN/TURN 服务器-开源
05-31
STUN/TURN 服务器。 足以支持 jfPhone 等 VoIP 电话。
stun/turn/ice NAT穿越
06-15
非常好的学习stun/turn/ice NAT穿越资料
STUN和TURN简介
06-21
4 STUN/TURN/ICE协议的关系： STUN（Session Traversal Utilities for NAT，NAT会话穿越工具）是一种简单的协议，用于帮助内网设备发现其公网IP地址和端口。它通过向STUN服务器发送请求，然后接收包含NAT映射信息的...
freeice:为您的WebRTC应用程序获取免费的随机STUN和TURN服务器
04-13
freeice模块是为WebRTC应用程序获取随机STUN或TURN服务器的一种简单方法。 服务器列表（在此阶段只是STUN）就是从这个。 使用范例 以下内容演示了如何将freeice与： var freeice = require ( 'freeice' ) ; var ...
coturn整个流程
heidas的专栏
11-23 3865
1、通过4个协议交互 Allocate 带上用户名和密码在coturn注册上该用户信息，创建客户端发送护具的udp端口。 CreatePermission 在coturn上创建需要透传的ip+port信息。 Send Indication 客户端发数据到coturn，coturn在内存中查找是否有createPermission的ip+port，找到则直接转发到对端的udp ip+port。...
webrtc入门：8.coturn流程
haleycat的博客
05-13 4615
对于局域网中的webrtc是不需要coturn，因为他们自己进行视频流的传输，但通常的应用场景，在同一个局域网下概率是比较低的，因此我们需要把流推到服务器上，另外一端在从服务器把流拉下来。coturn做为turnserver做的是这一部分的工作。当然coturn也可以作为 stun服务器，这篇文章先不讲，只讲turnserver这部分的内容。 turnserver的原理是根据webrtc的协议而定的，最主要的功能就是转发webrtc上的数据流，在转发数据流中，最关键的是两样，一个是创建流端口连接，一个是匹配
coturn穿透服务器搭建
qq_27623521的博客
01-16 1680
穿越NAT和防火墙的服务器 NAT主要负责维护内部ip地址和端口号与外部ip地址和端口号之间的映射表 STUN服务器：用来取外网地址的 TURN服务器：在P2P失败时进行转发的 ICE：即交互式连通建立方式。并非一种新的协议，它通过综合利用现有NAT穿透协议，以一种更有效的方式来组织会话建立过程，使之在不增加任何延迟同时比STUN等单一协议更具有健壮性、灵活性。 github 上开源的穿透服务器有...
7-webrtc传输基本知识
LIJIWEI0611的博客
01-05 1139
WebRTC传输基本知识 WebRTC首先要解决的是两个浏览器之间如何实现音视频的实时互动，对于底层来说就是如何实现两个端点之间高效的网络传输，为了解决这个问题WebRTC引入了很多的传输协议 NAT (Network Address Translator) 下面我们以传统的邮件作为例子，给大家说明NAT是什么？比如A和B两个人要发信，那B告诉A它在某个楼的某层时，这个时候A 可以给B发消息或者信件吗？这肯定不行，因为它并不知道一个具体的地址是多少？你必须告诉它具体哪个省哪个市哪个区哪个小区哪号楼哪层
coturn 401 Unauthorized问题排查
Andy Tools
10-11 5995
文章目录1 背景2 stun与turn 服务测试3 ICE 收集测试[](https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/)4 标准文档中的流程5 结论 1 背景 今天在调试webrtc C++设备join webapp 建立的房间时，在交换ICE信息后，开始进行ICE打洞。发现C++ 收到401 ...
http报错之return error code:401 unauthorized
wanhui2010的博客
11-15 9999
 http报错之return error code:401 unauthorized 根据HTTP返回码所表示的意思应该是未授权，没有输入账号和密码，因此解决方法就直接在HTTP包里面携带密码。 先利用shell产生user and password 的base64编码 将账号为admin，密码为admin的信息经base64编码为YWRtaW46YWRtaW4=。 $ echo
STUN协议详解
Jarvis的博客
01-06 6553
1.概述 STUN(session traversal utilities for NAT),一种处理NAT传输的协议，主要作为工具来服务其他协议。它允许位于NAT（或多重NAT后的客户端找出自己的公网地址，查出自己位于那种类型的NAT之后以及NAT为某一个本地端口所绑定的internet端口），这些信息被用来两个同时处于NAT路由器之后的主机之间建立UDP通信。目的就是找到外界连接内部地址所需的信息。 2.STUN协议架构 1.请求/响应（request/response）类型，由客户端给服务器
P2P通信之TURN协议
clark的专栏
12-01 629
一、前言 上一篇P2P通信标准协议(一)介绍了在NAT上进行端口绑定的通用规则，应用程序可以根据这个协议来设计网络以外的通信。但是，STUN/RFC5389协议里能处理的也只有市面上大多数的Cone NAT（关于NAT类型可以参照P2P通信原理与实现），对于Symmetric NAT，传统的P2P打洞方法是不适用的。因此为了保证通信能够建立，我们可以在没办法的情况下用保证成功的中继方法（Relaying），虽然使用中继会对服务器负担加重，而且也算不上P2P，但是至少保证了最坏情况下信道的通畅，从而不至于受
WebRTC中的STUN服务和TRUN服务
最新发布
weixin_46983030的博客
05-12 2668
STUN（Session Traversal Utilities for NAT）和TURN（Traversal Using Relays around NAT）是两种用于解决NAT（Network Address Translation）问题的协议。NAT是一种网络技术，用于连接私有网络到公共网络。然而，NAT会影响网络连接的可靠性和速度，尤其是在实时通信场景下，如视频会议、实时语音、游戏、直播等。STUN是一种协议，用于检测NAT类型和IP地址。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值