张鹏：腾讯云直播 PCDN 加速方案（下）

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 了。

作者介绍：

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

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

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