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应用场景，无论是直播、点播、文件都是适用的，文件适合大文件的分发。对于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了。
