低延时的P2P HLS直播技术实践

本文根据4月21日OSC源创会·武汉站的现场分享为蓝本，重新整理。 以下是演讲内容：

近几年，随着直播、短视频等视频领域对带宽要求的提升以及CDN行业竞争的加剧，很多CDN公司开始往P2P-CDN方向发展。P2P-CDN在降低成本和加速视频业务方面一直是非常优秀的解决方案。

今天就以HLS协议做一个切入点，讲解一下又拍云的P2P-CDN项目——PrismCDN。

直播P2P-CDN通常用于传输FLV协议的视频，又拍云为什么研发支持HLS传输协议的P2P-CDN呢？因为有客户使用了Web播放器，他们不想用FLV协议。为了满足客户的需求，又拍云PrismCDN对P2P-CDN做了HLS适配，让其能够支持HLS协议。

首先看一下HLS和HLS+。虽然HLS已经被广泛使用，但是它平均延时在10秒-30秒，存在延时高的缺点。HLS+技术通过在CDN边缘节点对视频进行切片、转封装，使延迟降低到4秒。目前，又拍云PrismCDN已经全面支持HLS+服务。

P2P-CDN支持HLS实现原理

以PrismCDN为例，目前的做法是P2P-CDN需要做一个P2P下载器的SDK，再通过P2P协议下载数据，同时借助CDN服务器补充数据下载，得到中间结果—FLV数据流。接着在SDK本地做转封装，转成M3U8和TS数据流，最后在local IP地址127.0.0.1上面提供HTTP服务，最终使播放器可以访问HLS数据流。

PrismCDN支持HLS协议的方式与HLS+降低延时的方式相似，HLS+是在CDN边缘节点切片，而PrismCDN则是在客户端本地完成切片以及传输FLV数据流。

P2P HLS的思路和HLS+是一样的，把每个TS片断切的很小，TARGETDURATION制成1秒，做到端对端延时4秒。

高效低价，独特直播架构下的秘密

上面主要讲解了HLS协议本地转封装，相较于P2P-CDN而言，最关键的数据流的传输方式。

首先主播通过RTMP协议将直播流推送到CDN服务器上，CDN服务器会即时推送数据流的二十分之一到光猫、路由器、机顶盒等雾节点。再由雾节点将数据转发到SDK的下载器里。下载器再向CDN服务器补数据，最终拼成FLV流。

PrismCDN数据传输关键点在于依靠光猫、路由器等雾节点的上行能力来提供CDN带宽，从而减少CDN服务器补数据流。将大部分数据通过雾节点转发，最终达到节约成本的目的。

独特直播模型造就低延时

与其他P2P产品相比，又拍云PrismCDN最大的特点是低延时。

P2P直播已有多年历史。早在2004年时，在网络电视直播应用中就已经使用P2P技术，把部分电视台信号放到互联网上面来直播。但是受限于技术，那时的P2P直播延时相当大。

为什么2004年的P2P直播延迟会相当大呢？

这是因为当时的直播格式数据流从最顶层的播放节点和CDN下载数据，再逐层下发到各个下层节点。这种直播树结构将数据一路下灌，造成了非常大的延时。

又拍云PrismCDN不需要构建一棵直播树，只需一层直播模型，就可以达到P2P占量比较高的效果。在一层模型中做到端到端延时在3秒内。在这样的延时下，目前市面上直播的业务，如游戏直播、秀场直播，都可以用PrismCDN来实现。

总结一下，PrismCDN低延时技术主要是在数据传输模型上进行了简化。

90%分享率成就低延时、低成本特性

PrismCDN节点分享比例在90%以上，提升分享比例的关键是在于引进了第三方设备来供应数据。相比传统直播树，PrismCDN不存在“是播放者，才是供应者”的局限。比如有一万个并发播放者的话，传统直播树的结构是无法支持在播放的同时，分享带宽给其它用户，尤其是在数据压力比较高的时候。而PrismCDN增加了大量的第三方设备数量，提高上行带宽供应量，降低CDN节点压力，从而提高节点分享比例。

PrismCDN能够提升流畅度的关键在UDP协议。UDP协议与TCP协议相比，优化空间更大。实测中，我们让一部分节点用TCP来运行，另外一部分节点用UDP来运行。相较于TCP，UDP可以提升5%的流畅度。

在雾节点选择方面，借助智能调度系统，就近选择节点，解决运营商之间的互联互通问题，避免跨运营商的情况发生。

多种测试确定最合适参数

又拍云PrismCDN中低延时、高分享率以及流畅性这些指标非常重要。但是这些指标中好几个是互相矛盾的，比如说分享率和流畅性，如何在提高分享率的同时提升流畅性？我们在开发的过程当中就在调整这些参数，通过线上系统大规模AB测试不断寻找合适的参数，找到合适的时间点补数据，用多少节点传输数据，用多少冗余节点等。

未来发展

除了P2PHLS之外，又拍云还在研发WebP2P，这里面会用到WebRTC、DataChannel、MSE、Webassembly等技术。我们去销售P2P产品的时候，市场上确实会有一些阻力，因为客户可能会不大信任SDK的P2P产品，包括它的升级和分发渠道，以及出了问题以后如何回滚。但是用WebP2P来做，客户会比较放心了，万一P2P系统有问题，可以快速回滚到老版本去。