腾讯云直播解决方案_张鹏：腾讯云直播PCDN加速方案（附视频回放）

6月29日，音视频及综合通信技术技术沙龙圆满结束。本期沙龙特邀腾讯云技术专家分享最新低时延技术、新型商业直播解决方案等话题，全面剖析腾讯云音视频和融合通信产品的技术，带来纯粹的技术分享分享给大家。下面张鹏老师分享了腾讯云X-P2P，为大家揭开P2P的神秘面纱。

讲师简介：

张鹏，腾讯云高级工程师，现任X-P2P直播加速技术负责人。毕业于华中科技大学，技术广泛。曾在创新工场从事游戏开发工作，在一牧天负责操作系统开发。网络科技担任技术总监，2014年开始研发视频P2P技术，这几年深度涉足P2P技术，攻克P2P技术难题。

点击观看视频评论

大家下午好，今天给大家分享的是腾讯云的技术，今天我给大家揭秘P2P技术的神秘与神奇。

简单来说，P2P就是你有大家都有的东西，我们可以通过互联网互相连接来共享。 P2P架构体现了互联网架构的核心技术，因此RFC 1中描述了这个概念。它有着悠久的历史，是早期互联网建设者心目中最令人向往的架构。至于为什么一直是中心化的服务模式？主要原因是它的一些历史和技术原因没有得到解决，但是我们仍然可以看到近30年互联网技术快速发展过程中P2P的产物，比如bt，以及2006年到2007年国内的P2P。 2008年，香港科技大学、华中科技大学、清华大学等学术界的黄金时代，代表了当时流媒体P2P的最高水平。此后，P2P因被封杀而陷入低潮期。 QQ旋风和迅雷下载被移动互联网慢慢淹没在历史的洪流中。也许只剩下一些视频团队继续私下做，直到2014年直播兴起，腾讯云X-P2P也再次出现。

接下来，P2P从2014年到现在已经经历了五年的打磨和完善，产品也非常稳定和成熟，覆盖了iOS、H5、PC等各种平台，加速的节点较多，延迟也比较多。相当于CDN甚至启动速度优于CDN，S8活动期间峰值达到8T。经历了大型直播活动的考验，也见证了闪存从盛到衰的过程。

为什么要做P2P？

P2P比较集中在视频行业，主要是因为带宽成本居高不下，而且带宽需求的速度快于带宽成本下降的速度。如今，每个人都希望在网络上观看视频和直播时具有更低的延迟和更低的延迟。在这种情况下，传统的P2P无法满足，而腾讯云X-P2P完美解决了这些问题。

P2P可以达到60%的共享率，在一些多人的房间，甚至可以达到80%的共享率。它的滞后率比CDN低，并且它们的延迟与CDN相同。

P2P技术如何运作？

首先，所有节点必须具有数据一致性。比如我向你要这些数据，你给我的数据必须和我认为的数据一致。

对于点播来说，点播是一个固定的文件，没有不断更新的数据。大家可以按照顺序来分。例如，第1到1000字节为一块，第1001到2000字节为一块。我向你请求第二件。绝对是我想要的。直播则不同。直播不能遵循同样的规则。例如，如果我在第一秒看到视频，则第一个到 1000 字节是我的第一个视频。你在第二秒看到的视频的起始位置是不同的。向你请求第 1 到第 1000 个字节肯定是行不通的。

直播可以根据dts进行切片，后面会涉及到各种问题。传统的P2P是建立一个中心切片服务，将直播切成切片，例如HLS、DASH。每个数据都是一个文件，这样就可以实现数据的一致性。

对于FLv和FMP4，传统的中央切片服务器对其进行切片并保存。现在我们已经突破了无法对原始直播流进行切片的限制，并且不会对直播流造成任何损坏，并且完全不修改直播流中的mux信息和编解码器信息。因为Flv和FMP4无论是标签格式还是盒子封装格式，在某种意义上自然有着严格的界限。只要找到从哪个边界开始，并与其他peer商定起始信息，我们就可以将原始直播流进行碎片化，做P2P。

我们的方法与直播流（Flv 或 FMP4）集成。 P2P数据可以直接交给玩家，不影响玩家的行为。也就是说，视频内容的侵入是可以完美完成的。

国外流行的HLS和DASH是天然的原生切片视频格式。它们最大的优势在于，它们旨在通过自适应比特率来减少延迟。那么FLv和FMP4是如何实现自适应码率的呢？自适应码率无非就是改变码率。新的解码参数被提供给播放器，播放器继续下一个（I 帧）。这就是自适应比特率。如果我的带宽只有6MB，而我坚持观看8MB的超高清视频，降低它可以达到流畅的观看效果，并显着降低延迟率。

如果我们为实时流媒体（Flv 或 FMP4）实现自适应比特率，会发生什么？我以前认为HLS和Dash都有自己很大的优势，为什么在中国没有使用它们是因为国家比较落后；然而，现在，我改变了以前的看法。在 Flv 和 FMP4 直播流上使用自适应比特率实际上比 HLS 和 Dash 更好，因为它是在单个 TCP 连接上实现的，并且单个连接明显优于多个连接。您不妨考虑一下。与 HTTP 1.1 相比，HTTP 2 最大的改进其实是能够在一个 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代表A通过S向B转发一个信息包。这个包一定会到达。那么B就已经提前和S建立了连接，并且认识S。B收到这个信息包后，就知道是A在外面敲门，然后给A返回一个握手包； A之前主动连接过B，并且认识B，那么B的握手包被A收到，那么他们之间的连接就建立了。

P2P NAT 大约有七种类型：

第一种是公网类型，直接部署在公网上。

第二种类型有防火墙。防火墙等安全软件为了安全起见，直接屏蔽UDP协议，所有UDP连接都被直接拒绝。

第三种是对称防火墙。

第四种是NAT完全锥型。

第五种是受限锥体。如果你想和我交流、连接到我，我必须首先知道你的IP。

第六种类型是带有附加端口的端口限制锥体。通信时，必须同时验证对方的IP和PORT。

第七种是对称型。如果更改目标，地址也会更改。这是最有特色的，也是最麻烦的。

P2P的STUN协议，除了STUN之外，其他协议对P2P没有任何意义。例如TURN经过中继服务器，中继服务器转发给B，B通过中继服务器转发给A。这实际上脱离了P2P的本来含义。 UPnP 要求微软安装自己的硬件来支持该协议。并不是整个网络上的所有设备都是这样，对于P2P来说就没意思了。只有STUN协议才能带来大规模的点对点网络P2P。关于STUN协议是如何工作的，详细可以看PPT，这里不再赘述。

既然我们知道了NAT类型和STUN协议，那么我们是否可以为网络上的大多数节点随意建立彼此的连接呢？

事实上，仍然做不到。为什么？因为现在的网络大部分都是对称NAT，而对称NAT是最难处理的。我举个例子，假设这是一个对称的NAT，这是一个受限的NAT，以证明它很难渗透。

腾讯凭借QQ、微信、QQ旋风多年的技术积累，突破了对称NAT的限制，使得大部分都可以互相渗透。这对于我们X-P2P来说实际上不是问题。由于时间关系，我们就不详细说了。

P2P网络拓扑

Mesh模型：每个节点有6个peer，每个节点以20%的概率下载切片。 6节点节点为36个节点。他们都没有这条数据的概率是 0.8 36 倍。平方，然后用1减去它，就是99.96%的概率至少有一个peer拥有这条数据。这是一种P2P方法。这种网络模型可以达到非常高的共享率。但它也有缺点。它的延迟很差，需要一段时间才能完全获取数据。二是需要频繁的信息交互，需要频繁的请求数据包来获取数据，这给网络带来了额外的负载。

树模型：顶层节点获取数据源，第一、二、四层与子节点共享。 P2P层数越多，共享率越高。它有很大的缺点。首先，超过一半的叶子节点不贡献数据；其次，随着层级的增加，层级越深的节点延迟越高；而且树形结构是非常危险的。一旦一个子树根节点崩溃了，就需要重新建立整个子树，这是非常昂贵的。这对于视频播放来说是一个严峻的挑战。

平均分布模型：I组PEER。该模型的一个更好的模型是将数据分为5个点。每个数据负责平均份额。我把这个份额分享给其他4个节点，他负责的也分享给其他人。在四个节点的情况下，这种均衡效果非常好，因为每个节点都可以获取数据。

XNTP传输能力

先问两个问题：做P2P的时候需要检测可用带宽吗？我们的答案是您不应该检测带宽。如果检测带宽，就会发送很多数据包，浪费带宽。你应该做的就是在使用过程中不断地检测、自然地检测。这个P2P需要抢占TCP带宽吗？很多朋友在做P2P的时候，把传​​输协议搞得太好了，导致TCP带宽没了，只剩下P2P带宽了。使用P2P时甚至无法打开实时网页，这是不合适的。如果我们想使用P2P，我们必须使用TCP的其余部分。至少P2P必须与TCP公平竞争。

过去 20 到 30 年来，TCP 一直是互联网的基础。已经很成功了，但是这里我想谈谈TCP的一些薄弱环节：

首先，它开始缓慢。 TCP 启动缓慢。每启动一次，速度就会加倍。从很低的初始速度上升到理想的速度，需要很多轮的RTT。好吧，每个人都知道倍指数函数的曲线。它的增长速度一开始确实很慢，甚至不如固定大斜率的直线快。大家不妨想一想，为什么增长率是2倍而不是4倍呢？ 8 翻倍？ （增加4倍，增加8倍）这样能解决问题吗？并不真地。

二是拥塞控制不力。加法增加和乘法减少会导致带宽不均匀。最高使用率为75%，TCP使用高达75%的带宽。

三是抗抖动和抗丢包率较差。如果丢包率超过20%，就基本没用了。例如，丢包率为30%，即连续丢包3次的概率为2.7%。这是什么概念？这相当于 30 个数据包丢失了 3 个数据包。当附加数据发送到累计30个包时，出现连续3次重复ACK，速度又减半。每次都会发生这种情况，并且 TCP 网络速度再也不会增加！

第四，重传歧义。 TCP重传歧义是非常糟糕的。丢失三个数据包后，将重传整个已发送的数据包。这可以解释，早期TCP刚诞生的时候，因为这个数据包是因为路由器缓冲区满了而丢失的，那么这个数据包后面的数据包一定是因为路由器缓冲区满了而被丢弃的。即使做到了快速重传，效果仍然很差。虽然重传包较少，但其更大的障碍是阻碍了发送窗口的速度前进。

XNTP启动速度快，几乎可以在一个RTT内检测到理想的带宽，这对于首屏和低延迟非常有帮助。比如未来4K​​到来，就需要200M带宽来支持。将速度从几K提升到200M所需的回合时间累计会超过1秒，这是无法忍受的。

对于速率控制，我们采用基于公式的速率控制，建立合理的数学模型，比TCP具有更好、更科学的拥塞控制。

借鉴了quic的双序列号包索引，完美解决了重传歧义问题。即使丢包率为30%，剩余的70%也可以充分利用。

丢包率是平均丢失多少数据包的指标。然后使用加权方法。最近的丢包权重比较高，距离越远丢包权重越低。这用于计算加权数据包丢失。可能性。

我的理解是发送就是发送。早期的TCP发送方式中，可能会留给网络在瞬间传输完RTT内所有要发送的数据包，然后RTT就会变得越来越大，因为会有队列。一旦RTT变大，就会发送更多的数据，最终会导致路由器撑不住队列，导致丢包、网速抖动。

更好的传输方法是均匀发送。 1 个 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的未来充满期待。腾讯云得到更广泛的应用；区块链底层使用的P2P技术类似于腾讯云X-P2P。然而，除了一堆不必要的概念之外，我们还没有看到如何访问渗透的核心技术。 ;边缘计算也将依赖于P2P技术稳健、安全、高效的底层；如果XNTP传输协议进一步优化，甚至可以与quic相媲美；最终，X-P2P可能会回归最初的梦想，产生完全去中心化的面向互联网的服务模式。

问：您好，因为我们P2P用户终端的CPU和带宽会得到很大的提升，所以发热量或者带宽占用会比较高。如何解决这个问题呢？

A：CPU发热肯定是程序写得不好造成的。 P2P技术就是网络的IO。有网络时使用。无网络时不使用。 CPU消耗不高。带宽消耗，我们的目的就是利用闲置带宽给其他用户带来好处。

问：关于P2P，您之前提到FLv和FMP4可以实现自适应比特率。您能告诉我们更多关于这方面的信息吗？

A：自适应码率需要你在客户端实现一些东西，比如什么时候切换？在服务器上实现一些东西，例如如何对齐视频内容以及从哪个数据点开始切换？我们实际上是根据PTS对齐数据内容，将码率转换后的I帧数据放在码率转换前的码流旁边，然后在前面重新插入音频编码参数和视频编码参数，提示播放器重新初始化解码器，然后播放器正常解码后续帧就OK了。