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

创作场景

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