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

6 月 29 日，音视频及融合通信技术技术沙龙圆满落幕。本期沙龙特邀请腾讯云技术专家分享关于最新的低延迟技术、全新的商业直播方案等话题，针对腾讯云音视频及融合通信产品的技术全面剖析，为大家带来纯干货的技术分享。下面是张鹏老师关于腾讯云 X-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 而言其实已不成问题，由于时间关系就不细讲了。