可以节约CDN带宽流量的流媒体P2P(Flash/Android/IOS)

2016-8-3 fredzeng cdn

很多朋友关心SRS是否有计划支持RTMFP,是否计划支持P2P,这篇文章详细介绍了SRS和P2P的关系。

Summary

我们所指的P2P,并非传统客户端P2P的方式,譬如ed2k那种协议。我们特指三种P2P:

  1. FlashP2P:Adobe开发的P2P,Flash播放器之间可以互相P2P,分享视频。

  2. AndroidP2P:特指Android的App的P2P方式,Android上HTML5不可能做P2P。

  3. IOSP2P:特指IOS的App的P2P方式,IOS上HTML5不可能做P2P。

这三种P2P都有几个共同点:

  1. 只讨论流媒体范畴的P2P,普通文件和数据的P2P不考虑。

  2. 流媒体传输使用通用协议,譬如flv、mp4或hls,配合CDN完成P2P原始资源的传输,而并非所有的数据都是P2P网络用私有协议传输。

  3. 尽量避免安装额外插件。譬如FlashP2P就在flash播放器上跑(别纠结flash本身就是个插件),只需要集成AS的SDK,不需要额外安装ActiveX浏览器插件。而Android和IOS的P2P,需要集成P2P系统的SDK,只需要安装商家的App,而不需要再安装专门用来做P2P的App。

综上所述,我们可以将Flash/Android/IOS P2P,简称为P2P。下面讲P2P一种可能的结构,以及SRS和P2P的关系。

Structure

一个P2P系统,可以包含下面几个结构:

  1. 客户端SDK:P2P系统必须提供客户端SDK,集成在播放器或者App中。譬如FlashP2P提供的是AS的库,Android提供的是java的库,IOS提供oc的库。

  2. API调度集群:P2P系统必须支持API调度,弥补DNS的不足,以及提供P2P系统需要的额外数据。API调度就是SDK交互的第一个后端,完成认证、其他服务器资源的分配、流信息、实时调度。

  3. RTMFP集群:或者称为基础协议集群,由API调度返回给SDK可用的服务器,客户端使用RTMFP服务器完成NAT打洞,以及必要的数据传输。

  4. Tracker集群:或者称为伙伴发现协议集群,由API调度返回给SDK可用的服务器,客户端向Tracker请求可用的伙伴节点。

  5. Pingback集群:或者称为实时数据集群,由API调度返回给SDK可用的服务器,并提供给API调度集群调度的实时数据依据,SDK向Pingback集群汇报实时数据。

  6. 流媒体源站集群:或者称为流媒体源,主要负责流媒体数据的生成,和CDN对接,由API调度返回给SDK可用的CDN边缘地址。

可以在SRS基础上完成的结构是:流媒体源站集群、RTMFP集群。其他大多是HTTP协议,主要是P2P系统内部的算法和逻辑处理,适合使用Python或者GO实现。

另外,Pingback集群需要提供10秒级别的系统数据,使用GO或者Spark都可以,数据量小时用GO实现也可以,数据量很大时可以用Spark。

下面详细分析SRS在WebP2P中的位置和状态。

SRS for P2P

回过头来说,SRS现在已经支持P2P中的流媒体源站集群和RTMFP集群了吗?SRS支持了流媒体源站集群,但是RTMFP集群不支持。

所谓SRS支持了流媒体源站集群,指的是SRS能输出一种HLS,能符合一种P2P系统的要求。这种P2P系统就是观止创想的P2P系统,具体参考BravoP2P。也就是说,若使用SRS作为您的流媒体服务器,是可以直接对接到观止的P2P系统的,可以给现有的HLS流加上P2P功能。

SRS为何不支持RTMFP集群呢,有几个原因:

  1. RTMFP目前不开源。

  2. RTMFP和SRS的差异太大,就算支持了RTMFP集群,还只是P2P系统的六分之一,没法用起来。

  3. SRS的目标是提供通用方案,SRS3的Dragon技术,SRS4对接Spark,目前还没有支持P2P系统的计划,P2P系统里面很多是私有方案。

因此,在现在的路线图,例如SRS3(预计2016年发布)和SRS4(预计2017年发布)的路线图中,都没有RTMFP的影子。

也就是说,在P2P系统中,SRS只计划支持流媒体源站功能。下面分开看看各种P2P系统。

FlashP2P

FlashP2P是由Adobe研发的P2P协议,包括握手、NAT打洞、数据传输,Adobe收购了一家做P2P的公司,将这个RTMFP协议集成到了Flash中。

FlashP2P在PC上的很成熟了,稳定性也可以达到商用的要求。从2013年开始,支持FlashP2P的公司也开始粗现,现在除了我们观止创想,还有云某动、快播解散后的一个团队等等。

AndroidP2P

Android手机、盒子和Pad上面支持P2P,这个目前还在发展中。

IOSP2P

IOS手机和Pad上面支持P2P,这个难度比AndroidP2P还大,目前没有消息。

Challenge

上面讲了各种P2P的情况,P2P的挑战有以下几点:

  1. 转换思维对接CDN:CDN最惧怕的就是P2P公司,不是要分他流量那么简单,而是对接起来灰常痛苦。据说有的FlashP2P系统,得在CDN每个边缘节点部署服务器,因为流媒体切片不通用,这不是要CDN的命么?因此首先最大的挑战就是转换为互联网思维,尽量使用通用方案,让CDN爽了P2P系统才能爽。

  2. 保证流畅度:传统P2P可以暂停缓冲个几个小时,而WebP2P直播正在进行时,缓冲个几次用户就刷新页面,这个P2P节点就相当于牺牲了。因此保证流畅度才能保证分享率,如何保证流畅度呢,这个就各显神通了。

  3. 实时调度:P2P的变化非常快,有的用户刷新页面啦,有的系统拖动啦,有的还暂停,有的就喜欢乱点。因此整个P2P的节点信息都是变化很快的,这对实时分析系统有非常大的挑战。

  4. 负载均衡和热备:P2P的集群也需要负载均衡,譬如RTMFP协议就支持Redirect方式,可以实现负载均衡和热备。传统P2P系统挂掉后节点就没法看视频,而一个P2P系统挂掉后依然能看,因为有CDN在那里呢,但是带宽就开始飙升了。而P2P系统的恢复需要较长时间,因此必须使用热备,在出现问题时切换到正常的系统。

这些挑战都是我们曾经遇到的,还包括没有遇到的。

标签: P2P FlashP2P CD WebP2P


版权所有:《DNS服务器IP地址,域名注册,CDN加速技术,linux,web服务器》 => 《可以节约CDN带宽流量的流媒体P2P(Flash/Android/IOS)
本文地址:http://www.dnsdizhi.com/post-227.html
除非注明,文章均为 《DNS服务器IP地址,域名注册,CDN加速技术,linux,web服务器》 原创,欢迎转载!转载请注明本文地址,谢谢。

发表评论:

Powered by emlog sitemap