很多朋友关心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系统的恢复需要较长时间，因此必须使用热备，在出现问题时切换到正常的系统。

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