张鹏:腾讯云直播PCDN加速方案(附视频回放)

6月29日,音视频及融合通信技术技术沙龙圆满落幕。本期沙龙特邀请腾讯云技术专家分享关于最新的低延迟技术、全新的商业直播方案等话题,针对腾讯云音视频及融合通信产品的技术全面剖析,为大家带来纯干货的技术分享。下面是张鹏老师关于腾讯云X-P2P的分享,为大家揭开P2P神秘的面纱。

讲师介绍:

张鹏,腾讯云高级工程师,现任X-P2P直播加速技术负责人,毕业于华中科技大学,技术涉猎广泛,曾在创新工场旗下做过游戏开发,在一亩田负责运营系统开发,在月光石网络科技担任技术负责人,2014年开始研发视频P2P技术,在过去的几年里,一直深耕P2P技术,攻克P2P技术难题。

点击观看视频回顾

大家下午好,今天由我给大家带来腾讯云X-P2P的技术分享,我是张鹏,现在是腾讯高级工程师,从2014年至今一直研究P2P技术,相信在座的各位很多对P2P还比较陌生,今天就由我来给大家揭开P2P这个神秘而又神奇的技术的面纱。

P2P简单而言,就是你有我有大家都有的东西,我们可以通过网络相互连接来分享之。P2P架构体现了互联网架构的核心技术,因此这种概念被描述在RFC 1里面,可谓由来已久,是早期互联网建设者心中最梦寐以求的架构。至于为啥现在一直是中心化的服务模式呢?主要还是它的一些历史原因和技术原因没有解决,但是我们也能在近30年互联网技术飞速发展的时期里,依然能看到P2P的产物,比如netsper,PPLive,bt,还有06~08年国内P2P学术圈的黄金时期,如香港科技大学的CoolStreaming,华中科技大学的AnySee,清华大学的GridMedia,代表着当时的流式P2P的最高境界了。而后,P2P陷入被封杀的一片低潮期,QQ旋风、迅雷下载也慢慢被移动互联网淹没在历史洪流中,可能只剩下一些视频团队在私下里继续做着,直到2014年直播兴起,腾讯云X-P2P也随之再次兴起。

接下来P2P从2014年到现在经历了5年的打磨完善,产品也非常的稳健成熟,覆盖Android、IOS、H5、PC等各种平台,它有更多的节点进行加速,延迟也是等同于CDN甚至优于CDN的起播速度,在S8赛事期间峰值达到8T,经历了大规模的直播活动的检验,同时也见证了flash由盛转衰的过程。

为什么要做P2P

P2P更多集中在视频这个行业里,主要是带宽成本居高不下,带宽的需求速度大于带宽成本下降速度。现在大家通过网络看视频、直播,都要求卡顿更低,时延更低。在这样的情况下传统的P2P是满足不了的,而腾讯云X-P2P完美地解决了这些问题。

P2P能达到60%的分享率,在一些人比较多的房间里面甚至可以达到80%的分享率,它的卡顿率是低于CDN的卡顿率的,他们的延迟跟CDN是一样的。

P2P技术是怎么做

首先所有的节点都要有数据一致性,比如说我向你要这些数据,你给我的数据肯定要和我认为的数据是一致的。

对于点播而言,点播是固定的文件没有不断更新的数据,每个人可以按照Offset去分,比如说第1~1000字节是一片,1001~2000字节是一片,我向你请求的第二片肯定是我想要的。直播就不一样了,直播不能按照Offset去做,比如说我在第一秒看到视频,第1~1000字节是我的第一片,你第二秒看到的视频起始位置不一样,向你请求第1~1000字节肯定是不行的。

直播可以按照dts去切片,这个到后面会涉及到各种各样的问题。传统的P2P就是搞个中心切片服务,把直播先切成片,比如说HLS和DASH,每一个数据都是一个文件,这样可以达到数据一致性。

针对FLv和FMP4,传统的中心切片服务器把它切片保存下来。现在我们则突破了在原始直播流上无法进行切片的限制,且对直播流无任何损害,完全不修改它里面的mux信息和codec信息。因为,Flv和FMP4,无论是tag格式还是box封装格式,天然就带有某种意义上的严格的边界,我们只要发现从哪个边界开始,跟其他的peer约定好开始信息,就可以在它的原始直播流身上实现分片去做P2P。

我们这种方式跟直播流(Flv或者FMP4)合成一体,P2P的数据可以直接交给播放器,且不影响播放器的行为,也就是对视频内容的侵入性上可以做的非常完美。

国外流行HLS、DASH,是天然的原生切片式视频格式,它最大的优势是为自适应码率降低卡顿而生,那FLv和FMP4怎么实现自适应码率呢?自适应码率无非就是码率变了,把新的解码参数交给播放器,播放器的接下来的下一个(I桢)给它续上,这就是自适码率了。如果说我带宽只有6兆,我非要看8兆超清的视频,把它降下去来就能达到流畅观看的效果,显著降低卡顿率。

如果我们实现了(Flv或者FMP4的)直播流的自适应码率,那会怎么样?我之前还觉得HLS、Dash有自己那么大的优点,国内为什么不用它是因为国内比较落后;然而现在,我改变了我之前的看法,在Flv和FMP4直播流上使用自适应码率其实是比HLS和Dash更好的,因为它是在单TCP连接实现的,而单连接明显是比多连接要好的。大家不妨想想,HTTP 2跟HTTP 1.1相比,它最大的改进其实是能在一个TCP上复用多个Http请求/响应出来,因为单一TCP连接的拥塞控制和顺序到达,肯定比多TCP连接的拥塞竞争要好的。但是HLS、Dash却反而把一个视频播放流请求变成很多个连接的文件请求,这其实是一个历史性倒退,如果在Flv或者FMP4直播流上做到自适应码率,那其实是比HLS、Dash还要领先的技术。

P2P的客户端侧第一部分任务就是穿透,穿透这个技术很有意思,可能大家没做过P2P,这是最有意思的。说穿透我们必须要说一下当前的互联网有NAT(网络地址转换)。我们的公网地址不够,所以我们在局域网上用内网地址。我们在发送请求的时候,我们用内网地址加一个端口标识这个请求;而请求数据来到因特网,则被NAT映射成一个公网地址和端口。这带来的一个问题是我知道B的地址,但是无法去连接,因为我向B发数据的时候,数据包直接被B的NAT阻止掉,因为B的NAT不认识我。大家也可以想一下,你绝无可能凭空主动连接到别人家内网里指定的某台机器,就算它在监听某个端口也不行,别人家内网里的主机、地址分布对你而言是个彻底的黑箱。

那在P2P之前我们要建立其跟其他Peer的连接,具体怎么做呢?它需要一个公网服务器S的帮助,A先连接S会告诉A公网地址,B也一样;第二步是A知道B的通信地址之后,A先主动连接B,这个请求连接的数据包则被B的NAT干掉,因为B还不认识A。A再通过S由它代A转给B一封信息包,这个包一定能够到达,然后B预先已经和S建立过连接,是认识S的。B收到这个信息包之后,就知道在外面敲门是A,然后给A也回一个握手包;A曾经主动连接过B,是认识B的,那B的握手包就被A收到了,那么他们之间的连接就建立了起来。

P2P之NAT类型,大概有七种:

第一种是公网型的,直接部署在公网上。

第二种带有防火墙,防火墙比如说安全软件为了安全,直接阻止了UDP协议,所有的UDP连接都是直接拒绝。

第三种是Symmetric Firewall对称型防火墙。

第四种是FullCone NAT完全锥型。

第五种是限制圆锥形,你想跟我通信,连接我,我必须得先认识你的IP。

第六种是加了端口的端口限制圆锥形,通信时要同时验证对方的IP、PORT。

第七种是对称型,换目标的话也会换地址,这是最与众不同的,也是最麻烦的。

P2P之STUN协议,除了STUN,其他协议对P2P是没有任何意义的。譬如TURN是经过中转服务器,中转服务器转发给B,B通过中转服务器转发给A,其实是脱离P2P原来的意思。UPnP是微软需要安装自己的硬件来支持它这个协议,全网并不是所有的设备都这样,对于P2P也没有意思。能够带来大范围对等网络P2P的唯有STUN协议,关于STUN协议怎么工作的,详细可以看PPT,在此不做赘述。

我们知道了NAT类型,知道了STUN协议之后,那对于网络上的大部分节点,我们就能随心所欲互相建立起连接了吗?

其实还是不能的,为什么呢?因为现在网络上最多的是对称型NAT的,对称型的是最难应付的。我举一个例子,假设这是对称型的NAT,这是限制型的NAT,来演示它非常难穿透。

腾讯依赖QQ、微信和QQ旋风多年的技术积累,突破了对称型NAT的限制,让他们大都能够相互穿透,对我们X-P2P而言其实已不成问题,由于时间关系就不细讲了。

P2P网络拓扑结构

网状模型:每个节点有6个peer,每个节点以百分之二十的概率下载切片,6个节点的节点,就是36个节点,他们都没有这片数据的概率是0.8的36次方,然后用1一减就是99.96%的概率总有至少一个peer有这片数据的概率,这是P2P的一种方式,这种网络模型可以达到很高的分享率。但它也有缺点,它延迟不行,它完整拿到数据需要一段时间。另外一个是它获取数据需要频繁的信息交换跟频繁的请求包,对网络造成额外的负载。

树状模型:由顶层节点获取数据源,一带二、二带四地层层分享给子节点,然后P2P层数越高,分享率也就越高。它有极大的弊端,一是一半以上的叶子节点不贡献数据;二是随着层次的增加,那些层次比较深的节点延迟比较高;还有树状结构很危险,一旦某个子树根节点挂掉了,那整个子树都需要重新建立,代价很大,这对视频播放是很严峻的挑战。

平均分流模型:我对PEER进行分组,这种模型比较好的是把数据分成5分,每个数据平均负责一份,我这一份分享给其他4个节点,他负责的那个也分享给其他四个节点,这个均摊效果非常好,因为每个peer都可以拿数据。

XNTP的传输能力

先问两个问题:我们做P2P的时候是否要探测可用带宽?我们的答案是不应该探测带宽,探测带宽你会发很多的包,这对带宽本来就是一种浪费,应该做的是要不停探测,要在使用中自然探测。这个P2P要不要抢占TCP带宽?多友商做P2P的时候,他们把传输协议搞得很牛,TCP带宽都没有了只有P2P带宽。你在用P2P看直播网页都打开不了,这样并不妥。我们要使用P2P,就要使用TCP剩下的,至少P2P也要跟TCP公平竞争。

TCP是互联网这二三十年来的基础,它非常成功,但这里我想说一下TCP的一些薄弱环节:

第一、启动慢。TCP有一个慢启动,每次是倍增的速度去启动,它从一个很低的初始速度上升到理想的速度,需要很多回合的RTT。那大家知道倍增指数函数的曲线,它刚开始增速确实很慢,甚至不如一个固定较大斜率的直线增速快,大家不妨想一想,为啥是2倍增速而不是4倍增、8倍的增?(4倍地增、8倍地增)这样就解决问题了吗?其实也没有。

第二、拥塞控制差。加性增乘性减,导致带宽不均,最高使用率是75%,TCP最多使用了75%的带宽。

第三、抗抖动、抗丢包率差。丢包率超20%,基本就废了。比如说丢包率是30%,也就是一个包连续丢三次的概率是2.7%,这是什么概念?这相当于30个包就会三次丢包,当加性增发数据到累积发了30个包后,发生一次连续3次重复ACK,速度再次降一半。每次都这样,TCP的网速再也起不来了!

第四、重传歧义。TCP重传歧义很差劲,他3次丢包之后,会把整个发送windows的包都重传过去。这在TCP早期刚刚诞生的时候是可以解释的,因为这个包丢了是因为路由器缓冲区满了,那这个包后面的包肯定也因路由器缓冲满被丢弃了。即使做了快速重传依然很差,虽然重传包少了,但它更大的阻碍碍于,阻止了发送窗口按速前进。

而XNTP是快速启动,一个RTT之内就能几乎检测出理想带宽,这对首屏和低延迟是相当有帮助的。比如说,以后4K来了,要200M带宽才能支持,从几K增加到200兆的速度需要消耗的回合时间,累积起来讲超过1秒的时间,这是不能忍受的。

速率控制,我们使用基于公式的速率控制,构建了合理的数学模型,它拥有比TCP更好更科学的拥塞控制。

借鉴quic的双序号包索引,完美地解决重传歧义问题,即便丢包率30%,也能充分利用剩下的70%。

丢包率,是表征平均发多少个包会丢包的一个指标,然后采用了加权的方式,最近的丢包权值比较高,越远丢包权值比较低,以此算出一个加权丢包的概率。

Pacing发送我理解就是均匀的发送,在早期的TCP的发送方式,可能一刻间交给网络去传输该RTT内要发送的所有包,然后RTT会越来越大,因为它会有排队, RTT一变更大,这样会发送更多,最终会导致路由器排队撑不过来,就会导致丢包,网速抖动。

更好的传输方式是均匀的发,一个RTT是40毫秒,我发40个包,这里每一毫秒发一个包,然后一毫秒之后再发另外一个包,这样对路由器非常均匀,就可以不会哪样频繁地丢包,把网络利用上去。

接下来是一个对比图,我之前用的是TFRC,它适用于包大小不变的传输速度,它是一个比较标准的,对比图是这样的,它的网络速度非常稳定,不像TCP这样一上一下。TFRC比TCP好一些,我们后来发现TFRC也有它的缺点,他的数据模型本身是以薄弱的TCP来建模的。后来我们基于TFRC对它进行了很多优化,又借鉴了现代的传输手法,所以我们现在的传输能力比TFRC更厉害,称之为XNTP。

P2P到今天已经不再是2006、2008年一门单纯的技术了,而是涵盖编解码、网络结构、传输优化,更是融合了现代的分布式计算,以云计算作为支撑,能够轻易完成数千万级别并发服务的技术集。P2P不要觉得它字面上意思很简单,如果要做好的话就会发现里面的技术细节确实非常多。

P2P应用场景

对于P2P的应用场景,无论是直播、点播、文件都是适用的,文件适合大文件的分发。对于4K视频加速,有P2P的助力,4K体验会更胜一筹。尤其对于大型直播活动比如说赛事、春节联欢晚会,是非常适合P2P来提高质量节省带宽的。对于短视频、常规视频,更是P2P加速的强项。对于大规模、大文件的分发也可以用P2P,其原理类似点播视频的P2P。

P2P接入也非常简单,先是注册腾讯云在云官网开通,通过腾讯云的官网下载SDK并接入,虽然不似某些云厂商吹嘘的一行就接入,但是花个10行,还是能够完美接入的,然后测试上线然后运维,非常简单,还会有专人对接。

P2P的未来与展望

最后,我们对XP2P的未来进行展望。腾讯云X-P2P某种意义上实现了多播协议,即优化了网络质量,又降低了网络的负载;而456(4K、5G、IPv6)的到来,将会使X-P2P进一步发挥能力和得到更广泛的应用;区块链的底层所使用的P2P技术和腾讯云X-P2P有异曲同工之妙,然而libp2p除了搞了一堆不必要的概念,还没有看到怎么接触到穿透的核心技术;边缘计算也将依赖稳健、安全、高效的P2P技术底层;XNTP传输协议如果再优化一下,甚至将可以和quic相提并论;最终,X-P2P可能回归最初的梦想,在互联网上产生出彻底去中心化的服务模式。

Q:您好,因为我们做P2P用户终端的CPU和带宽会有一个比较大的量的提升,发热或者带宽占用率比较高,是怎么解决这个问题呢?

A:CPU热肯定是程序没有写好。P2P技术是网络的IO,有网络的时候使用,没有网络的时候就不用它,那对CPU的消耗是不高的。带宽的消耗,我们目的是使用闲置的带宽为其他用户带来利益。

Q:P2P前面关于您说的在FLv,FMP4上可以实现自适应码率,这方面是否可以多讲一下?

A:自适应码率需要你在客户端实现点东西,比如何时要切换?在服务器实现点东西,如怎么对齐视频内容,从哪个数据点开始切换?我们其实是根据PTS去对齐数据内容,把转换码率后的I帧数据紧接着转换前码率的流,然后把音频编码参数、视频编码参数都重新插入在前面,促使让播放器再重新初始化解码器,接着播放器正常解后面的桢就OK了。

----------END----------

在看,让更多人看到!

原文发布于微信公众号 - 腾讯云视频(txvideocloud)

原文发表时间:2019-07-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券