首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >腾讯云PCDN:从P2P到万物互联服务框架

腾讯云PCDN:从P2P到万物互联服务框架

作者头像
LiveVideoStack
发布2019-09-12 09:36:47
2.9K0
发布2019-09-12 09:36:47
举报
文章被收录于专栏:音视频技术音视频技术

回顾XP2P的发展历程,由为近几年兴起的直播业务节省带宽成本为出发点,经过日益发展完善,XP2P已经在底层借助STUN、端口预测、生日攻击、UPnP构建了完善的互联直连基础,并且在直连的UDP连接的基础上拥有了高效、可靠传输协议XNTP,借此再高屋建瓴,在之上实现了广泛应用的HTTP协议,至此万物互联的服务框架已经基本搭建完成,具备网络负载小、传输性能高、稳定的特点。本文来自于腾讯云高级工程师张鹏在LiveVideoStackCon2019北京站上的精彩分享。

文 / 张鹏

整理 / LiveVideoStack

大家好,我是腾讯云张鹏,从2014年开始一直深耕P2P技术,攻克P2P技术难题。在过去几年中,腾讯云XP2P技术已在多个产品线落地并经受了大流量阅兵直播、赛事直播等考验,今天我将为大家着重讲解腾讯云P2P技术在网络穿透、网络传输以及网络拓扑组建等方面内容。

1. 什么是XP2P?

P2P架构体现了互联网架构的核心技术,简而言之就是“你有、我有、大家都有的东西,大家相互联接共享之”,因此这种概念被描述在RFC 1里面,可谓由来已久,是最早互联网建设者心中最梦寐以求的架构。那为什么到现在一直仍是中心化的服务模式呢?主要还是它的一些历史原因和技术原因没有解决。但是我们依旧能在近30年互联网技术飞速发展中看到P2P的产物,比如netsper、PPlive、bt,此外06-08年是国内P2P学术圈的黄金时期,国内高校有着非常高的产出,如清华大学的GridMedia、中国香港科技大学的CoolStreaming、华中科技大学的AnySee等等,代表着当时流式P2P的最高境界了。2008年之后,由于P2P流量给网络带来了很大的负载,经历了运营商的打压陷入一段低潮期,直到2014年直播兴起,腾讯云XP2P也再次重新进入云服务市场。

2. XP2P产品功能

2.1 穿透篇

2.1.1 P2P的NAT穿透

说到P2P就肯定要讲到它的起点——如何建立起互联的关系。我们知道IPv4地址已经日益衰竭,现在家庭带宽中“猫”的路由器的出网IP已经不是公网IP了,而NAT(网络地址转换)可以解决这个问题,当然NAT也是一把双刃剑。比如当我们在发送请求的时候,我们用内网地址加一个端口标识这个请求,当请求数据来到因特网,则被NAT映射成一个公网地址和端口。但这时就会带来一个问题,虽然我们知道对方的地址,但却无法连接,这是因为我们在发送数据时,由于对方NAT并不认识我而被阻止,因此我们需要首先把Peer之间建立起连接的过程打通。下图描述了通过中间转发服务器把两个Peer打通的过程。

2.1.2 NAT类型

最新的STUN协议对NAT类型分为7种:Open Internet、UDP Blocked、Symmetric Firewall、Full Cone、Restricted Cone、Port Restricted Cone、Symmetric。关于它们的介绍,在此请看下PPT,不做过多介绍了,只简单说一下,对称型是最难办的,对称型在连接不同外部Peer时会拥有随机的不同映射地址,因此它也有了端口限制型的特点,难以穿透。

2.1.3 STUN协议

STUN协议就是探测前面提到的7种NAT类型的协议,它的包格式如下图左侧显示,右侧为其流程图,这张图中有几点需要特别注意:首先是Test II,它是请求原来的STUN服务器地址,然而是换一个IP给我回包看是否可以收到。第二点是Test III,它是请求原来的STUN服务器地址,然而是换一个端口给我响应看是否可以收到。这两点尤其需要特别关注。

目前大多数P2P应用都是基于STUN协议做穿透建立直连通道,但STUN协议并未完全解决问题,它无法建立起对称型和端口限制型、对称型的连接。下图是一个对称型连接端口限制型的案例:对称型和端口限制型都会连接一个外网的打洞服务器,它们彼此知晓地址,当对称型向端口限制型发包时,由于目标地址变了,因此也换了一个新的映射地址,建立的一个新的“洞”;然而通过打洞服务器中转给端口限制型的信息里面,仍然是对称型之前与打洞服务器建立的旧“洞”,导致此时端口限制型可以回包,但是返回的是给旧“洞”,与对称型计划与该限制型通信的新“洞”不同,因此通信被拒绝,打洞失败。更加雪上加霜的是,伴随安全等级的提升,对称型和端口限制型越来越多,而STUN对此却无能为力,非常遗憾。

2.1.4 攻破对称型NAT穿透:端口预测

如何攻破对称型NAT的穿透成为了P2P技术的关键之一。此前一篇论文提出一个方式,通过端口预测的方式来解决对称型NAT的穿透:首先Client到外网探测自身端口变化规律,相当于端口预测;Sever也同样探索自身端口变化规律;最后通过穿透服务器中转知晓彼此信息并预测对方下一次端口,朝其发包,从而实现成功打洞。这个放在当年是可行的,因为当年95%的设备都是端口递增的;然而如今NAT端口变化大部分却是随机的,因此也很遗憾。那我们到此就束手无策了吗?依然还剩下大部分随机端口对称型连端口限制型、对称型的case悬而未决!

2.1.5 攻破随机端口对称型NAT的穿透:生日攻击

我们知道端口限制型的地址是不会变的,而随机端口对称型的映射地址是随着目标地址变化而随机变化的,那他们两个怎么打洞建立起直连通道呢?受端口预测方式的启发,其实还是能够以较小代价打通的。这里采用的方案是生日攻击法,也即是随机碰撞的原理来实现穿透。生日攻击来自于生日悖论,讲的是一个会议室坐着23个人,一年有365天,他们中任何一个人的生日可能在任何一天,然而他们中至少有一对是同一天生日的概率为50%。更直白点,是利用了远小于样本集(生日共有365种可能)的尝试次数(23个人),便能很大概率收获到一对相同采样碰撞(同一天生日)的结果。那么,假如样本集是65535个端口,要想两方随机打洞多少个端口,才能让两方刚好碰撞成功一次的概率达到80%呢?

它具体是这样做的:

1. 随机型NAT通过新建socket,朝端口限制型的外网地址发包,这些包在出NAT时,会被随机映射成不同的“洞”

2. 端口限制型,随机地向对方不同端口地址发包。然后看,是否有一个目标端口恰好发送给第1步里面随机型NAT映射的外网端口“洞”上,如果碰对,即可成功建立起连接

双方通过向对方各自发400个包,即可让穿透成功率达到80%以上,而400个包的代价,每个包只包含IP头部、UDP头部、连接ID,再加上一个以太网帧头部,顶多50字节,400个包总共也就20KB,以此换取优质节点的连接成功,还是完全可以接受的。

生日攻击的手法,大大提高了两方成功建立起连接的可能性。但是仅仅如此还是不够,生日攻击只能应付对称型与端口限制型的穿透,然而随机端口对称型与对称型的连接依旧无法建立!

2.1.6 UPnP:变Symmetric NAT为Full Cone

UPnP协议(通用即插即拔服务)是一个旨在让家庭设备与互联网其他设备无缝建立起连接,并简化网络过程的协议。它其实更像是一个物联网协议,包罗万象。我们发现其中包含两个服务WANIPConnection和WANPPPConnection,它们可以从内网主动添加到外网的Full Cone型端口映射,因此对于对称型难以穿透的情况,我们就可以使用这种协议将它转变为Full Cone型,从而进一步提升穿透成功率。

到此为止,我们已经几乎实现了最优的peer to peer的穿透方案,比WebRTC更优,比libp2p更优,并会达到一个很好的连接建立成功率,这将是我们P2P的核心基础。

2.2 传输篇

2.2.1 TCP协议的弊端

提到传输协议就不得不说TCP,它是互联网这二、三十年来的基础,但它同样存在一些薄弱环节:首先就是启动慢,TCP有一个慢启动——每次是以倍增的速度去尝试直到一个阈值,它从一个很低的初始速度上升到理想速度,中间需要很多回合的RTT,所以称之为“慢”启动。在初始阶段,它的增速甚至不如一个固定的较大斜率的直线增速快。第二点是拥塞控制差,TCP每个回合会增加一个包(发送窗口),一旦超过网络最大限制,就会直接减少一半,从而就使得它的平均发送速率只能达到网络的75%。第三点是TCP的抗抖动、抗丢包差,大家可能都听过一句话“TCP丢包率超过20%,基本就废了“,这里给大家举一个例子:假定我们的丢包率是30%,也就是说一个包连续丢三次的概率就是2.7%,这意味着当加性增发数据到累计发了40个包后,就会发生一次连续3次重复ACK,从而导致速度降为一半,循环往复TCP的速度也就再也起不来了。最后是重传歧义,当发生丢包之后,在下一个回合接收到这个包,然而我却无法确认接收到的是原本的包,还是重新发送的包。

2.2.2 XNTP之Pacing

针对TCP的问题,我们的协议做了很多优化。首先是Pacing发送,Pacing发送我理解就是均匀的发送,在早期的TCP的发送方式,可能一刻间交给网络去传输该RTT内要发送的所有包,然后RTT会越来越大,因此它会有排队, RTT进而变得更大,这样会发送更多,最终会导致路由器排队撑不过来,就会导致丢包,网速抖动。更好的传输方式是均匀的发,一个RTT是40毫秒,我发40个包,这里每一毫秒发一个包,然后一毫秒之后再发另外一个包,这样对路由器非常均匀,就可以不会哪样频繁地丢包,把网络利用上去。

Pacing-Race本身并无稀奇,它仅是我们传输协议的基础,后续的很多优化其实都依赖它。

2.2.3 XNTP之抗抖动

我们对于抗抖动的策略是来源于QUIC的灵感,QUIC每包有两个序号:包序号和内容序号,我们认为,它才是解决网络传输抗抖动的关键,达到了发生拥塞时,滑动窗口不停滞的效果。假设正常发包,滑动窗口是11,接收方在接到第11个包之后发送ACK表示第2个包丢了,TCP会把滑动窗口滑到[2,13],然后重传2和11包,效率底下;而QUIC遇到丢包时则会以新的包序号重传,而该包的内容序号不变,效果则是相较于TCP类似于滑动窗口直接滑到[12, 23],丢的包以新的序号12、13进行传输,滑动窗口不影响。这样就使得即便在20%丢包率的情况下,依旧可以使用剩余的80%网络传输数据。

2.2.4 XNTP之“快启动”

我们首先了解下Google的BBR,它有两个关键因子:探测到的最小RTT和最大带宽,从而确定最优发送法:本次发送量=最小RTT * 最大带宽。这个思路同样可以借鉴到“快启动”中吗?我们之前提到过Pacing虽然解决了TCP发送队列缓存延迟问题,但是在初始速度方面仍存在自身劣势,那突发就一无是处吗?突发的意义在于让发送方的发送速度达到了瞬间无限大,我们的解决思路便是依赖于此!我们认为首包的RTT就是最小RTT,并且在前面少量几个包采用突发的方式,比如第一回合发送的10个包中前4个包采用突发,突发的方式也意味着发送速率无限大,因此接收方可以通过统计这4个包的接收速度得到一个我们认为近似的最大带宽,从而1-RTT后拿到ACK的时候,最小RTT、最大带宽都拿到了,使用BBR的方式,便可以得到一个“最优发送法”,结束慢启动,进入拥塞控制。

像快启动这样的网络传输创新,我们还有很多其他对传输协议的系统性的认知,在经过多方验证数据后,我们也会努力开放给学术界、工业界的朋友,由于时间原因,暂时不先过多介绍了。

2.3 应用篇

有了XNTP提供的这种可靠传输,相当于有了“TCP”,我们也顺势在XNTP上构建了HTTP语义,这里不仅实现了HTTP的基本语义,还实现了HTTP 2的多路复用——在同一个链路上复用多个流,除此之外我们也实现了HTTP Client和HTTP Server。也就是在P2P很高的连接成功率和XNTP很好传输性能的基础上,在HTTP协议上可以构建HTTP服务。我们知道Unix的简单哲学之一体现在“一切皆文件”,而我们这套框架也可以简单理解为“一切皆服务”,以后也会一直奉行这个简单的思路,而XP2P/PCDN自然而然也就成为这套框架的第一个应用服务。

2.4 P2P技术怎么做?

2.4.1 必要条件 — 切片

对于P2P技术实现,首先所有节点都要有全网数据一致性,也就是你的某一片数据和我的这一片数据一定是相同的,否则就没意义。

对于点播而言,文件长度和播放时长都是确定的,因此数据一致性的实现算法非常简单,易于实现。但是对于直播来说,直播内容稍纵即逝,并且每个观众观看直播的时间点也不相同,因此无法像点播一样按照Offset分片。

2.4.2 P2P针对直播的切片

针对直播的切片,传统方式包括按照dts制定,或者使用中心服务器将直播流切片为小文件来约定数据一致性,比如HLS和DASH。而我们目前采用的方式是直接在原始直播流上做切片,FLV和FMP4在格式中天生带有明显边界信息——FLV的tag或FMP4的box,因此我们只需要和其他Peer约定好起始节点和边界信息,就可以突破在原始直播流上实现P2P的限制。

2.4.3 P2P的自适应码率

在直播中流畅的观看体验是非常重要的,而HLS和DASH天生是为自适应码率而生的,它们会在网络条件较差的时候自动切换到较低的码率,我们知道HLS和DASH是对直播流做了切片,而FLV和FMP4则不需要,只要在一个HTTP链接,把新的解码参数给到客户端(播放器)就可以实现自适应码率。那相比于HLS和DASH有什么优势呢?大家都知道,HTTP 2相比于HTTP 1.1最大的改善是把多个HTTP请求用一个TCP连接传输,因为单一TCP连接的拥塞控制和顺序到达是要比多个TCP连接的拥塞竞争要好的,然而HLS和DASH却反而把直播流请求变成多个连接的文件请求,这其实是一个倒退。而我们直接在一道流式直播上实现自适应码率,我们认为是比HLS、DASH还要领先的技术。

2.4.4 P2P网络拓扑结构

下面是三种比较常见的网络拓扑结构:网状模型、树状模型、平均分流模型。各有各的优点和缺点。但你要问我们腾讯云用了哪种模型,答案是我们那种都没用!目前腾讯云使用的是网状模型和树状模型的混合模型,在结合两者优点的同时,相对减少了树状结构的层数,从而平衡树状模型所带来的弊端,这也是腾讯云P2P和分享率做的很好的原因。

3. XP2P应用场景

提到P2P应用场景,首先会想到流量分发加速,比如直播、点播和文件下载场景的应用,其实P2P发展到今天,已经不怎么会引起网络高负载,而是更友好地提升网络能力。我们认为P2P其实是实现了某种程度上的多播协议,起到了优化带宽传输,降低网络负载的功能:比如同一小区有两个人观看同一个视频,其实只有一个人需要从远程服务器拉取数据,另一个人可以通过内部网络分享获取,这样就减少了数据包在网络上流转,从而降低网络负载。特别值得一提的是,我们实现了很高成功率的P2P穿透,实现了可靠的网络传输和HTTP,我认为再结合边缘计算、雾计算是很有可能打破现在的中心化部署服务的限制,有可能将简单服务器部署在真正的分布式网络中。

4. XP2P的未来与展望

最后,我们对XP2P的未来进行展望。腾讯云X-P2P某种意义上实现了多播协议,即优化了网络质量,又降低了网络的负载;而456(4K、5G、IPv6)的到来,将会使X-P2P进一步发挥能力和得到更广泛的应用;区块链的底层所使用的P2P技术和腾讯云X-P2P有异曲同工之妙,然而libp2p除了搞了一堆不必要的概念,还没有看到怎么接触到穿透的核心技术;边缘计算也将依赖稳健、安全、高效的P2P技术底层;XNTP传输协议会继续优化,未来甚至将可以和quic相提并论;特别值得一提的是,雾计算绝不止流量分享这样的应用那么简单,它还需要一股风真正把它重定义,就像当年AWS重新定义云计算那样伟大。而这套万物互联的服务框架,将遵循一切皆互联服务的简单思路继续发展,可能就是重新定义雾计算的钥匙,这才是更令人兴奋的!

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-09-10,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 LiveVideoStack 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云直播
云直播(Cloud Streaming Services,CSS)为您提供极速、稳定、专业的云端直播处理服务,根据业务的不同直播场景需求,云直播提供了标准直播、快直播、云导播台三种服务,分别针对大规模实时观看、超低延时直播、便捷云端导播的场景,配合腾讯云视立方·直播 SDK,为您提供一站式的音视频直播解决方案。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档