turn协议 数据交换过程

WebRTC（Web Real-Time Communication）。Real-Time Communication，实时通讯。

WebRTC能让web应用和站点之间选择性地分享音视频流。在不安装其它应用和插件的情况下，完成点对点通信。

WebRTC背后的技术被实现为一个开放的Web标准，并在所有主要浏览器中均以常规JavaScript API的形式提供。对于客户端（例如Android和iOS），可以使用提供相同功能的库。 WebRTC是个 开源项目 ，得到Google，Apple，Microsoft和Mozilla等等公司的支持。2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。

WebRTC包括一系列API和相互关联的协议来实现通信。

Voice over Internet Protocol，在网络上传输声音消息的技术。

例如网络音频通话。或者叫做IP电话，宽带电话。使用VoIP技术的一大原因是费用低。

Network address translation，网络地址转换。

NAT能给你的设备一个公共IP地址。一个路由器（router）有一个公共IP地址，每个连接到路由的设备有一个私有的IP地址。

设备发送请求时，会从一个特定端口，通过私有IP发送到路由的公共IP。这样每个设备在网上不需要都有一个公共IP地址，但也能被其它设备发现。

参考 IP Network Address Translator (NAT) Terminology and Considerations

Interactive Connectivity Establishment，互动式连接建立（交互式连通性建立）。

ICE是一套能让web浏览器之间互相连接的框架。通常来说，节点A到B是很难直接相连的。防火墙会阻止连接，设备没有公共IP地址，路由不允许直接连接其他节点。

ICE使用STUN或者TURN服务（或者同时使用两者）来建立连接。

参考 ICE | rfc8445

Session Traversal Utilities for NAT (STUN) ，NAT会话传输工具。

STUN协议能发现客户端（节点）的公共地址。客户端发送一个请求给网上的STUN服务器，服务器返回客户端的公共地址。不管客户端在路由器的NAT后能否可达。

STUN为请求者提供了可公开访问的IP地址，它就不再参与对话了。

有些路由器会限制设备与外面其它设备的连接。这意味着即使STUN服务器知道了路由的公共IP地址，也没法建立连接。

这种情况下我们需要使用 TURN 。

Traversal Using Relays around NAT，使用中继绕过NAT传输。

一些路由器使用一种叫“Symmetric NAT”（对称型NAT）的限制。这意味着路由器仅允许之前连接过的节点（peer）来建立连接。

STUN 提供了一个能让应用（终端，节点）穿过NAT的方法。STUN允许客户端获得一个传输地址（一个IP和端口）来获取其它节点的数据。

然而STUN获取到的地址不一定能被所有节点使用。这些地址是否可用取决于网络拓扑的情况。所以，单独STUN无法提供完整的穿越NAT的方案。

TURN协议允许两个处于NAT环境的主机利用中继进行通讯。客户端能够在TURN服务器上分配资源，与其它客户端（peer）进行通讯。

客户端关联一个TURN服务器的地址（relayed server address）来作为中继。

客户端发送报文给TURN服务，TURN服务使用relayed server address作为源地址向其他客户端中继转发报文。

穿越NAT，这个过程就像是“打洞”。也有人称TURN服务器为“打洞服务器”。

这么看，TURN服务器需要有大的带宽。因此，ICE会优先考虑直接通讯，无法直接通讯情况下会使用TURN。

参考 TURN rfc8656

Session Description Protocol，会话描述协议。

描述多媒体连接内容的协议。例如分辨率，格式，编码，加密算法等等。

实际上，SDP不是个真正的协议。它也是用来描述设备之间连接与传输多媒体的数据格式。

参考 SDP: Session Description Protocol | rfc8866

一些缩写

更多请参考 WebRTC概念简介

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地址就可以了，具体的转发原理请看下一小节。

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

如上图所示：因为客户端A位于NAT后，所以其他客户端无法和A建立直接的通信。但是客户端A在STUN服务器上申请了一个端口(上图中：A的relay端口)，其他客户端想要和A通信，那么只需要将信息发送到“A的relay端口”，STUN服务器会将从relay端口接收到的信息通过STUN Port发送给A。

A应答其他客户端发来的消息的时候，是通过原路返回的。

思考

1STUN服务器为什么不直接从A的relay端口把数据转发给A呢（如下图所示）？而非要从STUN端口发送？

STUN服务器给客户端A分配的relay地址都具有一定的有效时长，可能是30秒或者1分钟或者几十分钟。客户端如果需要STUN服务器一直为它开启这个端口，就需要定时的向STUN服务器发送请求，该请求用刷新relay端口的剩余时间。

在标准的TURN（RFC 5766）协议中，客户端A向STUN服务器发送Allocate请求，STUN服务器在响应消息中添加了一个“LifeTime”的属性，该属性表示relay的存活时间。 客户端需要在relay的存活时间内周期性的调用REFRESH请求，服务端接收到REFRESH请求后，刷新剩余时间；当REFRESH请求中的lifetime属性为0时，说明是客户端主动要求关闭relay地址。

由于与STUN服务器通信使用的是UDP，所以为了保持一个长连接，需要客户端周期性的向STUN服务器的STUN Port发送心跳包。

周期性心跳包的目的就是，使得NAT设备对客户端A的反射地址(Server Reflexive Address)一直有效。使得从STUN Port发送的数据能通过A的反射地址到达A。此处不理解的可以查阅“NAT 类型的分类以及NAT的作用”。

此处解释了，7223中的第一个问题，因为客户端A没有和relay Port保活，又由于NAT的特性，数据直接通过relay port转发给A时，NAT直接就丢弃了，所以A是收不到的。所以数据必须经过STUN服务器的STUN Port发送。

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

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

序号6、7、8、9、10为A的回应，原路返回（绿色箭头方向）。

注意：在“Hello”发送的过程中，1、2阶段时，发送的数据为裸的UDP数据。在4、5过程中，是被STUN协议包装过的“Hello”，称之为Data indication。

同样在“Hi”发送的过程中，6、7阶段为被STUN协议包装过的“Hi”，称之为Send indication，9、10是裸的UDP数据。

在4、5阶段，由于数据是从STUN Port转发下来的，为了能够让客户端A知道这个包是哪个客户端发来的，所以，STUN 协议对“Hello”进行了重新的包装，最主要的就是添加了一个XOR-PEER-ADDRESS属性，由裸数据包装成STUN协议的过程，我们称之为添加了STUN头。XOR-PEER-ADDRESS的内容就是客户端B的反射地址（Server Reflexive Address）。

在6、7阶段，A的响应原路返回，为了能够让A的relay port知道最终发往哪个客户端，因此也为“Hi”添加了STUN头，也是添加了XOR-PEER-ADDRESS属性，内容就是客户端B的反射地址（Server Reflexive Address）。这样A的relay port就知道“Hi”的目的地址。

第3阶段是：从A的relay端口收到数据，添加STUN头后，最后从STUN Port 发出的过程。

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

客户端B主动发送信息给A的交互流程如上图所示，那么客户端A主动发送信息给客户端B的交互流程是怎样的呢，你能画出来吗？

要知道客户端A主动发消息给客户端B，应该将消息发往客户端B的relay port哦。。

先简单介绍一下代理的分类:

代理分：Level 1~Level 5 五个等级；

或者也可以分为3类：·

A 全匿名代理　不改变你的Request

Fields，使服务器端看来就像有个真正的客户浏览器在访问它。当然，你的真实IP是隐藏起来的。服务器的网管不会认为你使用了代理。

B· 普通匿名代理　能隐藏你的真实IP，但会更改你的Request

Fields，有可能会被认为使用了代理，但仅仅是可能，一般说来是没问题的。不过不要受它的名字的误导，其安全性可能比全匿名代理更高，有的代理会剥离你的部分信息（就好比防火墙的Stealth

Mode），使服务器端探测不到你的操作系统版本和浏览器版本。

C· 透明代理（简单代理）　改编你的Request Fields，并会传送真实IP。

你访问的网站会把你看的一清二楚，知道你用了代理，知道代理的IP，也知道你的真实IP。

一般Level3-Level5属于 透明代理； Level 1-Level3 属于匿名代理！ 全匿名代理有时也称为超级代理！

不想让网管(国内代理服务器}或者ISP(国外代理服务器)知道我想去哪去过哪,那把你的连接请求用SSL加密就行了

有了匿名功能再加上加密的连接,隐身术终于练成!

制作和使用这个代理需要的软件是CCPROXY 62,STUNNEL,OPENSSL,SOCKSCAP都是免费软件,CC3个用户就够了

假设你已经有了一台远程机器A做代理服务器,你自己的机器为B

在A机上,我们要开一个SOCKS5的本地代理端口,并且用SSL加密他的传输首先,在CCPROXY里启用SOCKS5的代理服务,假设端口是 1080,创建一个用户,验证方式为用户名/密码/IP混合,假设用户名密码都是123,IP为127001,记得顺便把"禁止局域网外用户访问" 勾上,因为远程的B机不会直接访问这个服务,免得老人人来扫密码下面是关键,打开CCPROXYINI文件,修改并确认下面2个参数:

EnableProxyConnection=0

EnableReferer=0

这样别人就不知道你使用了代理,也不知道你从哪儿来好像CC60也支持这两个参数,不过官方是63才在FAQ里面写出来

然后配置STUNEELCONF文件,内容如下:

cert=stunnelpem

key = stunnelpem

taskbar=no #这个参数可以隐藏STUNELL的图标,如果做坏事就用$%#%#

client=no

[socks2ssl]

accept = 80 #在80端口监听,准备接受外部连接

connect = 127001:1080 #连接CCPROXY开的SOCKS5服务端口

把监听端口设为80的原因是极端的假设B机前面的防火墙只允许B机访问80端口,如果没这个限制,随便设一个

代理服务器做好了,我们要配置一下B机这个客户端

首先是客户端的STUNNELCONF

client = yes

[ssl2SOCKS]

accept = 127001:8282 #在本地启用8282端口的SOCKS5代理服务

connect = AAAAAAAAAAAA:80 #连接到你的代理服务器A,地址或者域名+端口

然后设置SOCKSCAP,设置代理类型SOCKS5,地址127001,端口8282,用户密码验证(启动SOCKSCAP会让你输入,就是前面设置的123了),DNS解析选先本地再远程

最后,把你的浏览器,例如IE,拉入SOCKSCAP,可以去 http://proxyjudgeorg/

验证你的匿名度了!通常就是下面这样的结果

REMOTE_HOST=AAAAAAAAAAAA

REMOTE_ADDR=AAAAAAAAAAAA

HTTP_ACCEPT=/

HTTP_ACCEPT_ENCODING=gzip, deflate

HTTP_ACCEPT_LANGUAGE=zh-cn

HTTP_CONNECTION=Keep-Alive

HTTP_HOST=proxyjudgenet

HTTP_REFERER=http://proxyjudgeorg/

HTTP_USER_AGENT=Mozilla/40 (compatible; MSIE 60; Windows NT 51;

Maxthon; SV1)

--------------------------------------------------------------------------------

REMOTE_HOST

Result

IP Addr

Comment

I have no idea because DNS lookup failure

HTTP Env value

Result

NoProxy!

Comment

Like no proxy server

AnonyLevel : 1

REMOTE_HOST that is IP addr is precious

或者B机上面装个个人防火墙例如ZONEALARM,启用它的隐私保护,那么

HTTP_ACCEPT_LANGUAGE

HTTP_USER_AGENT

这些本机信息也都会被隐藏

后记:最初只是通过CCPROXY+STUNNEL建一个HTTP的SSL服务器通道,然后本机也是直接用STUNNEL连接出来的HTTP代理,但是验证匿名度的时候始终是Level2,3,让人很不爽知道后来看了一些关于CCPROXY和SOCKS5的资料,试着转换角度弄一下,终于成功了其实用SOCKSCAP还有一个好处,他可以过滤某些数字开头的IP

跳过代理直接连接,如果你的代理服务器驾在国外,你只要把国内主要的一些IP数字开头例如:20296 61141等等加到那个过滤列表里面,就可以解决国外代理访问国内网站很慢的问题了