wap网站 劣势,企业网站模板 优帮云,珠海网站制作推广,企业网站开发时间RTC
RTC 是 Real-Time Communication 的简写#xff0c;正如其中文名称 “即时通讯” 的意思一样#xff0c;RTC 协议被广泛用于各种即时通讯领域#xff0c;诸如#xff1a;
在线教育#xff1b;直播中的主播连麦 PK#xff1b;日常生活的音视频电话#xff1b;.....…RTC
RTC 是 Real-Time Communication 的简写正如其中文名称 “即时通讯” 的意思一样RTC 协议被广泛用于各种即时通讯领域诸如
在线教育直播中的主播连麦 PK日常生活的音视频电话......
WebRTC 则是 Google 基于 RTC 协议实现的一个开源项目为 Web 页面提供了实时音视频传输所需的能力前端部分
RTC 有一个非常重要的特性它是一个支持点对点直接传输的 P2P 协议
P2P
P2P 是 “Peer to Peer” 的简写在金融领域大家应该都听过这个名词P2P 暴雷金融中 P2P 可以指代 “个人对个人的网络放贷”在互联网中也有着类似的意思表示数据 “点对点传输” 指数据可以在两个互联网用户之间直接传输无需服务器在中间进行转发
举个例子IM 聊天软件中有 A、B 两个正在聊天的用户聊天过程中用户 A 的文字信息是没办法直接通过网络发送给用户 B 的而是需要一个服务器 S 在中间做转发“A - S - B”但采用 RTC 协议的视频电话就不一样了电话的音视频数据可以通过网络直接在两个用户之间传输无需中间服务器进行转发“A - B”
采用 RTC 协议能带来两个非常大的优势
大幅度降低服务端的负载减少成本用户间直接进行数据传输延迟上能带来不小的提升
NAT “墙”
从上文知道RTC 是一个 P2P 协议数据可以直接在用户之间传输但现实往往比理论来的复杂实际用户的网络环境并没有那么简单如果不做一些特殊处理数据很大概率无法在两个用户之间传输之所以无法直接传输为了大家更好的理解需要从头说起
随着互联网的用户逐年增多接入互联网的设备也越来越多公网 IPv4 的地址池慢慢见底新接入互联网的设备很难再分配到单独公网的 IPv4 地址为了解决这个问题引入了一个叫 NATNetwork address translation的协议新接入的设备不再直接分配公网的 IPv4 地址而是躲在 NAT 设备路由器等之后NAT 会给后面的每一个设备都分配一个单独的内网地址NAT 内部将维护一个内外网的地址映射表格举个例子 NAT 设备会修改发出去和收到的数据包比如把上面 “192.168.0.1:8088” 发出去的包改成 “220.181.38.149:1111” 这样外部的设备就会以为自己是在跟 “220.181.38.149:1111” 通信接收到响应包之后NAT 会把目标地址 “220.181.38.149:1111” 修改为 “192.168.0.1:8088”随后转发到内网这样就实现了一个公网的 IPv4 地址给多个设备共同使用的效果
NAT 在实现上述功能之后为了内网设备不被攻击还使用了两个安全策略
NAT 超时NAT 维护的内外网地址映射表存在超时时间一段时间内没有数据传输对应的映射就会被取消造成连接链路中断NAT 墙NAT 还实现了类似防火墙的能力外部主动发送给内部设备的数据包到了 NAT 之后可能会被丢弃
根据 NAT 墙策略的不同最常见的 NAT 可以分为四种
Full Cone NAT完全锥形表示映射表中所有的地址外网设备都可以直接访问到是最宽松的策略了Restricted Cone NATIP 限制锥形没被访问过的外网地址发的数据包都会被丢弃用上面的例子来解释假如 “192.168.0.1:8088” 访问过外网 “103.15.99.89:80” 这个地址那外网 “103.15.99.89” 这个 IP 的所有端口都将可以访问通内网但其他外网地址的访问会被阻止Port Restricted Cone NAT端口限制锥形类似 2不过除了限制外网的 IP 地址外还会限制端口Symmetric NAT对称形这种 NAT 的丢包策略和 3 一样只要外网的 IP 和端口有一个没被访问过数据包就会被丢弃但是该类型的 NAT 内外网地址映射的策略不一样对称型 NAT 不会直接给一个内网设备分配固定的 IP 和端口而是根据访问的外网地址分配不同的 IP 和端口举个例子假设内网设备 A 访问外网 B 时的映射为 “192.168.0.1:8088 -- 220.181.38.149:1111”那么内网 A 访问外网 C 时的映射可能会变成 “192.168.0.1:8088 -- 220.181.38.149:2222” 为什么要叫锥形和对称形
所谓锥形是指本地端访问所有外网单元时都使用同样的公网IP和端口例如
本端 220.181.38.149:2222 -------- 抖音
本端 220.181.38.149:2222 -------- 王者荣耀
本端 220.181.38.149:2222 -------- 小红书
而对称形是指本地端访问不同外网单元时使用不同的公网IP和端口例如
本端 220.181.38.149:1111 -------- 抖音
本端 220.181.38.149:2222 -------- 王者荣耀
本端 220.181.38.149:3333 -------- 小红书
ICE -- NAT “打洞”
知道 NAT 的存在之后再举一个例子 用户 A 知道用户 B 的网络地址并且 A 和 B 在不同的 NAT 之后某一时刻 A 想主动联系 B然后 A 经过自己 NAT 发一个请求给 B请求到达 B 的 NAT 时因为 B 没联系过 A所以 B 的 NAT 便会将 A 的请求丢弃 上面简单的例子就可以看出虽然 RTC 是一个 P2P 的协议但因为 NAT 墙的存在就算通讯的双方知道对方的网络地址也没办法直接沟通......
所以需要引入一个机制对这个沟通过程进行协调帮助通讯双方能够越过 NAT 并成功建立连接这套机制就是 ICEInteractive Connectivity EstablishmentICE 是一个框架协议可以让互联网中两个设备进行点对点的连接ICE 框架包含的两个主要工具协议
STUNTURN
STUN
STUNSession Traversal Utilities for NAT是一个工具协议这个协议的主要目的是协调帮助两个在 NAT 之后的设备建立 UDP 也可以是 TCP传输既然 STUN 是一个协议那我们就可以采用任意技术栈来开发实现一个 STUN 服务及 STUN 客户端实现的 STUN 主要有两个作用
帮助获取客户端的公网地址并通过复杂的策略探测出客户端所处的 NAT 类型STUN 还可以帮助两个客户端之间进行 NAT “打洞”或者协调 TURN 在两个客户端中间充当中继服务 NAT 探测
服务端可以非常轻松的在数据包中获取请求的来源 IP 和端口但是并没有办法知道对应的请求是客户端直发还是 NAT 转发的更没办法知道是哪种类型的 NAT客户端也一样无法知道自己的 NAT 情况但只要 STUN 客户端及 STUN 服务齐心协力就可以一步步探测出 NAT 情况
STUN 服务和 STUN 客户端会按照下面的逻辑进行配合一步步探测客户端所处的 NAT 情况
ps一个 STUN 服务需要拥有两个 IP 通过两个 IP 的服务互相配合来探测 NAT 的情况 第一步判断是否存在 NAT客户端主动发一个请求到 STUN 服务的 “IP1 端口 1” 上STUN 服务把收到的请求的 IP 和端口直接返回给客户端客户端会将 STUN 服务返回的 IP 和端口跟自己的 IP 和端口进行比较 如果一致则表明客户端处在公网中或者说客户端没有在 NAT 之后可建立host类型连接如果不一致则表明客户端处在 NAT 之后需要往下走继续探测 NAT 类型第二步判断 NAT 是不是 Full Cone NAT完全锥形客户端发送请求到 STUN 服务的 “IP1 端口 1”STUN 服务收到请求之后用 “IP2 端口 2” 主动往客户端发送一个请求 如果客户端能够收到 STUN 服务 IP2 的请求则表明 NAT 策略非常宽松来者不拒是完全锥形可建立srflx类型的连接如果客户端没办法收到 STUN 服务 IP2 的请求则数据包被 NAT 丢弃了NAT 不是完全锥形需要往下走继续探测 NAT 类型第三步判断 NAT 是不是 Symmetric NAT对称形客户端主动往 STUN 服务的 “IP2 端口 2” 发送请求STUN 服务收到请求之后把请求的来源 IP 和端口直接返回给客户端客户端用收到的 IP 和端口跟 “第一步” 中的 IP 和端口进行比较 如果两次收到的端口不一致则表明 NAT 是对称形的如果一致则表明 NAT 不是对称形的需要进一步探测 NAT 类型第四步判断 NAT 对端口的限制客户端主动往 STUN 服务的 “IP2 端口 2” 发请求要求 STUN 服务用 “IP2 端口 3” 往客户端发请求 如果客户端收到了 “IP2 端口 3” 的请求则表明 NAT 没有对端口进行限制是 Restricted Cone NATIP 限制锥形可建立prflx类型连接如果没收到请求则表明 NAT 限制了端口是 Port Restricted Cone NAT端口限制锥形
NAT “打洞”
经过上面四个步骤之后便知道了客户端的公网地址以及所在的 NAT 情况光知道 NAT 情况还没用NAT 依旧会对请求进行拦截STUN 还需要协调两个客户端对各自的 NAT 进行打洞客户端才能穿越 NAT 完成连接建立下面从简单到复杂举几个例子来说明 NAT 的打洞流程
只有一方在 NAT 后 假设客户端 A 和客户端 B 需要建立 P2P 连接客户端 A 直接拥有一个公网 IP而客户端 B 在 NAT 之后
这种情况下如果客户端 A 直接与客户端 B 通信通信将会失败客户端 A 发送的数据包会被客户端 B 的 NAT 丢弃此时STUN 服务端便会进行协调让客户端 B 主动先往客户端 A 发送数据包客户端 B 的 NAT 便记录了客户端 A 的通信记录客户端 A 后续便可以与客户端 B 进行通信了 客户端 B 主动连接客户端 A ”这个过程就被形象的称为 “给客户端 B 的 NAT 打洞”
双方都在非对称形 NAT 后 假设客户端 A 和客户端 B 需要建立 P2P 连接客户端 A 和客户端 B 在不同的 NAT 之后
这种情况下客户端 A 和客户端 B 往对方发送的数据都会被 NAT 丢弃STUN 服务便会协调两个客户端让它们先主动都往对方发送数据在自己的 NAT 上留下对方的 “洞”后续两个客户端便可以完成连接的建立了 双方在对称形 NAT 后
假设客户端 A 和 B 的 NAT 均为 Symmetric NAT对称形
这种情况下先说结论STUN 服务将无法协调客户端 B 的 NAT 打洞 由于对称形 NAT 的特性STUN 服务端看到的客户端 A “ip 、 端口”将会和客户端 B 看到的客户端 A 的 “ip、 端口” 不一样此时如果 STUN 服务强行协调客户端 B 给 NAT 进行打洞打的洞客户端 A 并没办法使用 所以这种情况下是没有办法建立 P2P 连接的也因为这种情况的存在才引入了 TURN 中继协议
TURN
TURN 全称 “Traversal Using Relays around NATTURNRelay Extensions to Session Traversal Utilities for NATSTUN” 从全称就可以看出TURN 是 STUN 的一个补充协议当 STUN 无法完成两个客户端的 P2P 直连时TURN 便会充当一个 “中继服务器”的角色对两个客户端之间的信息进行转发 如何快速判断是否能打洞
给 NAT 类型进行一个排序从宽松到严格的顺序如下
Full Cone NAT完全锥形Restricted Cone NATIP 限制锥形Port Restricted Cone NAT端口限制锥形Symmetric NAT对称形
如果两个客户端的 NAT 类型的序号相加大于等于 7 则无法打洞成功需要引入 TURN 服务举个例子如果两个客户端分别是 “4. Symmetric NAT对称形” 和 “2. Restricted Cone NATIP 限制锥形”则这两个客户端能打洞成功因为他们的序号相加为 6 小于 7 webRTC ICE
WebRTC建立网络连接的过程主要包括收集candidate、交换candidate和按优先级尝试连接该过程被称为ICEInteractive Connectivity Establishment交互式连接建立。其中每个 candidate 都包含IP地址、端口、传输协议、类型等信息。
根据 RFC5245 协议 WebRTC将 candidate分为了四个类型host、srflx、prflx、relay它们的优先级依次降低。
hostHost Candidate根据主机的网卡数量决定一般一个网卡对应一个ip地址然后给每个ip随机分配一个端口生成这种类型的连接里使用的是本机物理网卡的IP和端口。
srflxServer Reflexive Candidate根据STUN服务器获得的ip和端口生成这种类型的连接里使用的是STUN服务器映射的IP和端口
prflxPeer Reflexive Candidate根据对端的ip和端口生成这种类型的连接里使用的是NAT上分配的IP和端口
relayRelayed Candidate根据TURN服务器获得的ip和端口生成这种类型的连接里使用的是TURN服务器中继的IP和端口
