张鹏:腾讯云直播 PCDN 加速方案(下)

阅读数:243 2019 年 10 月 31 日 23:56

张鹏:腾讯云直播PCDN加速方案(下)

P2P 网络拓扑结构

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

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

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

张鹏:腾讯云直播PCDN加速方案(下)

XNTP 的传输能力

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

张鹏:腾讯云直播PCDN加速方案(下)

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 早期刚刚诞生的时候是可以解释的,因为这个包丢了是因为路由器缓冲区满了,那这个包后面的包肯定也因路由器缓冲满被丢弃了。即使做了快速重传依然很差,虽然重传包少了,但它更大的阻碍碍于,阻止了发送窗口按速前进。

张鹏:腾讯云直播PCDN加速方案(下)

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

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

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

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

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

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

张鹏:腾讯云直播PCDN加速方案(下)

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

张鹏:腾讯云直播PCDN加速方案(下)

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

P2P 应用场景

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

张鹏:腾讯云直播PCDN加速方案(下)

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

P2P 的未来与展望

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

张鹏:腾讯云直播PCDN加速方案(下)

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

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

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

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

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

本文转载自公众号云加社区(ID:QcloudCommunity)。

原文链接:

https://mp.weixin.qq.com/s/PI03ESgaP6JqHa4CDaE3Ww

评论

发布