腾讯云直播PCDN加速方案

1 .云+社区技术沙龙 

2 .腾讯云X-P2P加速方案 Rocalzhang 张鹏 腾讯高级工程师 

3 .SPEAKER Rocalzhang 腾讯XP2P负责⼈人 腾讯云X-P2P是业内领先成熟的P2P产品，其中多个产品线均已 成熟，包括不不同平台、不不同延迟场景下的P2P直播、点播P2P 等，现已推⼴广到⽃斗⻥鱼、企鹅电竞、英雄联盟等直播平台使⽤用，经 受住了了⼤大流量量阅兵活动直播、赛事直播的考验。现在腾讯云视频 P2P技术，在P2P⽹网络传输、P2P技术对视频的侵⼊入性、P2P⽹网 络拓拓扑组建上有了了新的进展，在此分享给⼤大家。 

4 .CONTENTS 01 XP2P简介 peer-to-peer对等⽹网络 02 XP2P产品功能 为企业减负，为观众增收 03 XP2P的应⽤用场景 直播、点播、⼤大⽂文件分发 04 XP2P的思考与展望 ⼤大有可为 

5 . P2P发展历史 1969.4 2000年年早期 2001.4 2007年年 2008 2014 被RFC 1收录 Guntella⽹网络诞⽣生 BT协议发布 P4P发布 GridMedia XP2P问世 Napster发布 PPLive发布 CoolStreaming, DONet AnySee 1999.1 2004年年底 2005 2006 

6 .更省成本、更流畅：业界领先的低延时P2P方案 n Flash n iOS/ANDROID n 平均卡顿率最低至2% n H5 n 秒开时间低至400ms n 短视频 n 平均分享率50%，可节约一半成本 n DASH n 服务带宽超过8T n 直播时延业界最低 n 7家上线客户，包括top3游戏直播 n 涵盖游戏直播、广播电视、体育等 S8赛事最⾼高峰值 

7 .CONTENTS 01 XP2P简介 peer-to-peer对等⽹网络 02 XP2P产品功能 为企业减负，为观众增收 03 XP2P的应⽤用场景 直播、点播、⼤大⽂文件分发 04 XP2P的思考与展望 ⼤大有可为 

8 .行业需求 n 带宽成本居高不下 n 带宽需求增速大于带宽成本下降速度 n 用户体验要求较高，纯CDN方案接近优化极限 n 传统P2P方案无法解决播放体验差、延迟长等问题 1080P由3%上升到32% 主流帧率上升到30FPS 50fps 40fps 2% 1% 60fps 其他 其他 7% 360P 13% 13% 4% 1080P 32% 640P 8% 20fps 29% 30fps 39% 720P 25fps 43% 9% 

9 .P2P的能力—节省带宽，为企业减负；提高体验，增加收视 

10 .P2P的必要条件-切片 Why？ - 全网对等节点，要有统一的数据块一致性， 这是能进行P2P前提需求 点播： - 可以按照offset制定数据块，比如：1MB 一片 - 可以按照播放时长制定，比如：1秒的数 一部电影，长度、时长固定，拆分切片很方便 据一片 直播： - 不能够按照offset制定数据块 - 可以按照dts制定，比如： Piece𝒊 = {𝒅𝒕𝒔 ∈ 𝟏𝟎𝟎𝟎𝒊, 𝟏𝟎𝟎𝟎 𝒊 + 𝟏 , 𝒅𝒕𝒔为解码时间戳} - 将数据变为私有协议格式，插入切片边界信息 - 将直播数据预先切好分片文件，以分片格式去分发，如 HLS、Dash 直播而言，新内容稍纵即逝，全网用户有差别随机位置开始起播 

11 .P2P针对直播的切片 ？问题： HLS、Dash 1 2 p 带宽不均匀 3 p 前进需要节奏 4 p 每次还要客户端去请求 • 天生就是切片segment，不需再切片 5 6 7 8 Flv、FMP4 • 突破在原始直播流上无法进行切片的限制 • 对直播流无任何损害，其mux、codec内容 都不变，就算不使用p2p，直播流也可无缝 送交播放器直接播放 

12 .P2P的自适应码率 HLS、Dash • 为自适应码率而生 Flv、FMP4-怎么办？ • 切换码率，无非就是将解码器等信息重置，再交 给播放器 • P2P SDK感知网络带宽，自适应切换码率，且 内容连续无缝切换 • 配合腾讯云播放器，可以做到无感知、无缝切 换，通过事件告知view层切换到了目标目标 • 而SDK内部还是使用类似长连接单请求来获取数 据 

13 .P2P的NAT穿透 3. Client A先向Client B发送一个包 1a. Client A去连接stun服务器，获取自己的公网地址 4.Client A向stun服务器发送一个包，请求stun服 1b. Client B去连接stun服务器，获取自己的公网地址 务器代为转发给Client B 2.Client A通过种子服务器拿到了Client B的地址，然 5.Client B收到stun服务器转发的包，响应Client 后去请求 A，于是连接建立 

14 .P2P之NAT类型 （4）Full Cone NAT：完全锥型，⾏行行为类似 （1）Open Internet：主机具有 公⽹网IP，任何外部主机就可以直接向NAT后 公⽹网IP，允许主动发起和被动响 的公⽹网地址发起UDP通信。 应两种⽅方式的UDP通信。 （5）Restricted Cone NAT：受限圆锥 （2）UDP Blocked：位于防⽕火 型，验证通信时对⽅方的IP。因此，要想外部 墙之后，并且防⽕火墙阻⽌止了了UDP 主机能够主动向该内部主机发起通信，必须 通信。 先由该内部主机向这个外部发起⼀一次通信。 （3）Symmetric Firewall：主 （6）Port Restricted Cone NAT：端⼝口受 机具有公⽹网IP，但位于防⽕火墙之 限圆锥型，验证通信时对⽅方的IP、PORT。 后，且防⽕火墙阻⽌止了了外部主机的 主动UDP通信。 （7）Symmetrict NAT：对称型。它连接外 部peer1和peer2时拥有随机不不同的ip和端 ⼝口。难以穿透 

15 .P2P之STUN协议 4 bytes 0x2112a442 12 bytes cookie transaction id type length data 2 bytes 2 bytes 

16 .P2P之NAT分布 对称型的NAT占⽐比⼤大，且标准STUN对对称型很难穿透！ 然⽽而，腾讯云XP2P再⼀一次攻破了了这种限制.. 

17 .P2P网络拓扑结构 平均分流模型： 树状模型： 网状模型： 把一道流均分成5份，每个节点平均负责一 由顶层节点获取源数据，一带二，二带四地 每个节点都极少自主请求源数据，按需向周 份，并分享给其他4个peer，其他peer亦然 层层分享给子节点 围节点请求，考虑到子节点的子节点数量是 级数增加的，所有总能从子节点拿到缺少的 数据 各节点带宽平摊效果好，各节点间播放观看 随着层数的增加，虽能达到更高的分享率， 无明显时差 但缺点也很明显： - 此模型经验证能达到很高的分享率，但是 l 有一半的底层叶子节点无法贡献数据，也 要求很高的延迟，故十分适用于高延迟直 就无法均摊带宽，父节点带宽压力大 播 l 上层节点离开产生的影响大 - 此模型需要比较高频的相互信息交换 l 底层节点与顶层节点有明显时差 

18 .XNTP的传输能力 要先探测上行带宽，好控制最大可用上行？ 要强占TCP带宽吗？ 不该探测： 不应该抢占： p动态的带宽变化，根本无法探测 pTCP用的剩下的，才是P2P最多该使用的 p探测浪费带宽 应该： 应该： p要公平竞争 p要不停地探测 p在使用中自然探测 

19 .TCP的薄弱能力 启动慢 从初始速度增加到理理想速度，即便便是倍增也要好⼏几个回合。 拥塞控制差 加性增乘性减，导致带宽不不均，且利利⽤用率最多只达75%。 抗抖动、抗丢包差 丢包率超20%，基本就废了了。 重传歧义 不不能确定重传包是真丢了了传回来，还是之前的包没丢延迟到的 

20 .XNTP的传输能力 快速启动 迅速检测出理理想带宽。 基于公式的速率控制 使⽤用基于数学模型公式的带宽控制，最⼤大化带宽利利⽤用。 以丢包率反馈传输速率 即便便丢包率30%，也能充分利利⽤用那剩下的70%。 双序号包索引 学习quic协议，完美的重传设计 

21 .XNTP的丢包率计算 if n=8, the values of w_0 to w_7 are: [1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2] 𝟖 𝟏 ∑ 𝒊3𝟎 𝑰𝒏𝒕𝒆𝒓𝒗𝒂𝒍𝒊 < 𝑾𝒆𝒊𝒈𝒉𝒕𝒊 = 𝒑 ∑𝟖𝒊3𝟎 𝑾𝒆𝒊𝒈𝒉𝒕𝒊 We calculate the average loss interval I_mean as follows: I_tot0 = 0; I_tot1 = 0; W_tot = 0; for (i = 0 to k-1) { I_tot0 = I_tot0 + (I_i * w_i); W_tot = W_tot + w_i; } for (i = 1 to k) { I_tot1 = I_tot1 + (I_i * w_(i-1)); } I_tot = max(I_tot0, I_tot1); I_mean = I_tot/W_tot; The loss event rate, p is simply: p = 1 / I_mean; 

22 .XNTP的Pacing 问题简化：在一个窗口内，计算出了下一次rtt要发生的数据量，怎么发送？ 比如：假设rtt=40ms，发送速率8Mbps，每包1kB，则需要发送40个包，怎么发？ 方法一：突发式一次性全送交网络发完 方法二：均匀地每隔1ms，送交网络一个包 seq seq 网络队列缓冲延迟变大， 发生丢包，发送量减半 rtt变大 rtt无明显 增大 rtt rtt t t Pacing发送更能真实表达发送速率的意义，更贴近真实网络， 其在消除发送队列缓存延迟方面表现出色，发送更加平稳 

23 .XNTP VS TCP 数据来源：https://people.eecs.berkeley.edu/~istoica/classes/cs268/06/notes/7-BeyondTCPx2.pdf 

24 .CONTENTS 01 XP2P简介 peer-to-peer对等⽹网络 02 XP2P产品功能 为企业减负，为观众增收 03 XP2P的应⽤用场景 直播、点播、⼤大⽂文件分发 04 XP2P的思考与展望 ⼤大有可为 

25 .XP2P应用场景 直播 点播 ⽂文件 尤其适⽤用于⼤大型直播活动。 短中⻓长视频均可。 类似于BT⽂文件下载。 卡顿、⾸首屏均要优于CDN⽹网络加速 节省带宽，不不输于CDN的体验 下载速度更更快，存储成本更更低 

26 . XP2P应用场景 ü 实现了某种程度的多播协议，优化直播带宽传输，即降低网络负 载，又降低带宽成本 ü 4K视频加速：有P2P的助力，4K体验将更胜一筹 ü 大型直播活动，如赛事、春节联欢晚会等场景 ü 短视频、常规视频P2P分发 ü 大规模、大文件分发 

27 .接入简单，优质服务 1 2 3 4 CDN配置 SDK接⼊入 测试上线 运维 云官⽹网控制台启⽤用直播，并配好 接⼊入P2P SDK，包体积⼩小，接⼊入 发布上线，观察数据，反馈效 快速响应需求，稳定运⾏行行，不不出 P2P加速域名。 简单。 果，极致优化体验。 故障。 

28 .CONTENTS 01 XP2P简介 peer-to-peer对等⽹网络 02 XP2P产品功能 为企业减负，为观众增收 03 XP2P的应⽤用场景 直播、点播、⼤大⽂文件分发 04 XP2P的思考与展望 ⼤大有可为 

29 .腾讯云XP2P之未来展望 Ø IPv6 Ø 5G Ø 边缘计算、盒子加速 Ø 区块链 Ø 标准化 最终，可能会回归最初的愿望： 彻底去中心化！