标签归档：P2P

安防视频监控P2P穿透原理及解决方案

近年来，随着网络带宽、计算机处理能力，芯片技术水平的提升以及存储容量的迅速提高，以及各种视频智能分析技术的出现，视频监控系统的优势愈发明显，其高度的开放性、集成性和灵活性为视频监控系统和设备的整体性能提升创造了必要的条件，同时为整个安防产业的发展提供了更加广阔的发展空间。然而，目前国内网络环境比较复杂，运营商众多，同时各单位内部网络结构较为复杂、公网静态IP地址有限等因素限制了采用IP直连方式来连接设备功能的实现，外网访问变得困难。同时采用传统动态域名解析(DDNS)方式，配置复杂，成功率低。随着消费类摄像机以及智能手机的普及，如何更好，更方便的远程访问摄像机视频成为行业重要的一个需求。摄像机能否支持远程访问，支持手机访问，P2P穿透的解决方案是其中最重要的一个要素。

P2P访问的工作原理

P2P穿透即点对点穿透(peer to peer)，是指前端设备通过一定的处理方式后，主动与请求客户端直接建立连接发送媒体流。

当前安防视频监控系统中的P2P主要工作原理是在前端设备中移植进一个P2P穿透辅助程序，P2P穿透辅助程序将向服务器注册该设备，服务器也可以由此来识别设备是否在线。同时P2P穿透辅助程序将与服务器进行必要的信息交换来实现网络分析和连接建立功能。

摄像机P2P穿透的工作原理如下所示：

P2P访问的核心是NAT穿越

NAT的穿越并非安防监控领域的技术，是目前VOIP以及即时通信等产品的基础性技术，目前来讲已经比较成熟，且有完整的技术标准RFC，同时也有众多的实现方案，包括许多已经得到广泛应用的开源项目。

简单来讲，实现NAT的穿越是可能的，成功的概率也比较高。UDP的协议进行数据传输穿透NAT的成功率比较高，接近100%，TCP则存在一些情况无法实现穿越，主要受限路由器的端口映射机制。

要实现NAT穿越，需要有穿越控制服务器部署在互联网（有固定的域名或者IP），由该服务器来协助网络摄像机和客户端来实现NAT穿越。有些服务器还能在TCP不能穿越的情况下，实现RELAY(数据中继转发)的功能，以确保二者之间能实现数据通信。

由于NAT穿越控制服务器不同于安防监控系统中的媒体转发服务器，主要进行信令交互，不转发媒体数据，在协助打通数据通道之后，对应的网络摄像机和客户端就不会再占用服务器带宽和处理能力了，因此一台穿越控制服务器可以接入数量庞大的网络摄像机和客户端(例如有P2P方案厂家宣传在全球部署超过50台服务器，接入了超过1000万台设备。)。

网络摄像机和客户端之间的访问机制

通常网络摄像机都有唯一ID，并通过该ID注册到穿越控制服务器。客户端要访问对应的网络摄像机时，也需要先注册到穿越控制服务器，并提交对应 网络摄像机的ID，由穿越控制服务器查找对应的网络摄像机，并协助网络摄像机和客户端之间进行NAT穿越，最后打通一个点对点的数据传输通道。之后，二者 即可进行正常的媒体和信令交互了。

为实现更加有效的管理，服务器可对设备接入进行认证。此外，如果设备ID过长，也可以为设备建立别名，客户端访问时用设备别名作为参数，服务器来查找对应设备。

数据传输机制

网络摄像机和客户端之间的数据传递包括有媒体流，信令流等。信令流数据量较小，媒体流数据量加大，而且需要有较好的实时性。

如果媒体流和信令流分开传输，需要打通多个通道，增加了复杂性和出错可能，同时增加了服务器的负担。

前面也讲过，UDP协议能有比较好的NAT穿透性，也比较适合媒体流的传输，但可靠性较差，不宜传输信令。为减轻服务器负担（避免TCP无法穿 透需要转发），提高穿透成功率，建议只打通一个UDP通道，利用该UDP通道封装媒体和信令流，在应用层加以区分，哪些是媒体流，那些是信令流。

由于UDP传输信令可靠性极差，即使是传输媒体数据，在互联网环境下肯定会出现丢包的情况，仍然会出现图像花屏或者解码出错的情况，因此必须要解决此问题。

好在利用UDP协议进行可靠的数据传输的需求早就存在，并有了比较好的解决方案，那就是通过UDP协议在应用层实现数据的缓冲，序列化，重传，可靠性控制和拥塞控制。

如果上述三个问题都已解决，则网络视频监控的P2P方案已经基本实现，剩下的就是产品化的问题。

目前P2P方式远程访问摄像机，有3种主要方式。电脑PC网页端访问，PC电脑客户端访问，手机app访问。

PC访问网络摄像机。

PC访问网络摄像机，可以先访问一个网页，传入网络摄像机的序列号。

网页加载一个控件，该控件通过NAT穿越控制服务器和该序列号对应的网络摄像机实现NAT穿透后，通过可靠的UDP传输信令和媒体数据。控件提供视频浏览，对讲，云台控制，参数查询设置等功能。

如果用PC客户端访问，则不需要加载控件，只需要输入网络摄像机对应的系列号。

手机访问网络摄像机。

手机由于平台的不同，需要单独开发对应的客户端或者插件以实现和PC访问类似功能。但原理是一样的，都需要通过NAT穿越控制服务器和该序列号对应的网络摄像机实现NAT穿透后，通过可靠的UDP传输信令和媒体数据。由于开源的NAT穿越库是可以移植的，在LINUX，WINCE，IOS,Android，Sbrian等都可以实现同样的NAT穿越功能。

P2P穿透限制

1.由于P2P穿透成功后是设备与客户端2者直接进行通信的，因此，访问设备的数量会影响用户的观看体验。不同的厂商对于设备的访问限制处理都不一致：有的厂商是做了访问数量限制，限制访问数为1-3个，那边前3个用户访问设备时可以进行实时预览操作。而超过这个数量的用户将无法进行实时预览，这样的操作是为了保护每个访问设备的用户都可以正常的观看到设备图像，保证图像质量。

2.P2P穿透的成功率。一般来说，P2P穿透不可能100%成功。有些厂家给出的是95%，99%，90%等等的穿透成功率。在穿透不成功的情况下，可以采用流媒体转发的方式来访问摄像机。这样对中间流媒体转发平台要求就比较高了，有些厂商为了节省服务器及带宽资源，对通过转发访问的方式做了些限制，例如通过转发只能访问摄像机的子码流。

P2P穿透访问应用

下图是某个P2P方案商的P2P平台运用



常见的P2P物联网平台

常见的智能摄像头P2P平台

Centos6 安装 stun/turn服务

1，关于stun和turn

STUN（Simple Traversal of UDP over NATs，NAT 的UDP简单穿越）是一种网络协议，它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一 个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT 路由器之后的主机之间建立UDP通信。该协议由RFC 3489定义。目前RFC 3489协议已被RFC 5389协议所取代，新的协议中，将STUN定义为一个协助穿越NAT的工具，并不独立提供穿越的解决方案。它还有升级版本RFC 7350，目前正在完善中。 

http://baike.baidu.com/view/884586.htm

TURN的全称为Traversal Using Relay NAT，即通过Relay方式穿越NAT，TURN应用模型通过分配TURNServer的地址和端口作为客户端对外的接受地址和端口，即私网用户发出的报文都要经过TURNServer进行Relay转发。 

http://baike.baidu.com/subview/351571/10359693.htm

2，安装

参考： 

http://www.hankcs.com/program/network/compile-rfc5766-turn-server-to-build-turn-server.html

代码下载： 

https://github.com/coturn/rfc5766-turn-server/releases 

下载最新的tar.gz包。rfc5766-turn-server-3.2.5.9.tar.gz

安装依赖环境 

##ssl 需要yum安装 yum install openssl openssl-libs libevent libevent-devel

    
	
	
  • 
		1
	
    • 

	
  • 
		2
	
    •

如果还是报错，就手动安装libevent。 

centos Libevent2 development libraries are not installed properly in required location

    
	
	
  • 
		1
	
    •

下载：http://libevent.org/ 官网，下载 

https://sourceforge.net/projects/levent/files/libevent/libevent-2.0/libevent-2.0.22-stable.tar.gz 

然后解压缩编译安装即可

编译turn-server 

tar -zxvf rfc5766-turn-server-3.2.5.9.tar.gz
cd rfc5766-turn-server-3.2.5.9 ./configure 
make
make install

    
	
	
  • 
		1
	
    • 

	
  • 
		2
	
    • 

	
  • 
		3
	
    • 

	
  • 
		4
	
    • 

	
  • 
		5
	
    •

configure成功： 

more is /usr/bin/more
install is /usr/bin/install
pkill is /usr/bin/pkill
Use TMP dir /var/tmp
Compiler: cc Do not use -lsocket Do not use -lwldap32 Do not use -lwldap64 Do not use -lintl
Sockets code is fine: no sin_len field present
Ignore IP_RECVERR
Crypto SSL lib found.
SSL lib found.
Libevent2 development found.
Libevent2 runtime found.
Libevent2 openssl found.
Libevent2 pthreads found.

POSTGRESQL DEVELOPMENT LIBRARY (libpq.a) AND/OR HEADER (libpq-fe.h)
        ARE NOT INSTALLED PROPERLY ON THIS SYSTEM.
        THAT'S OK BUT THE TURN SERVER IS BUILDING WITHOUT POSTGRESQL DATABASE SUPPORT. MYSQL DEVELOPMENT LIBRARY (libmysqlclient) AND/OR HEADER (mysql.h)
        ARE NOT INSTALLED PROPERLY ON THIS SYSTEM.
        THAT'S OK BUT THE TURN SERVER IS BUILDING WITHOUT MYSQL DATABASE SUPPORT. HIREDIS DEVELOPMENT LIBRARY (libhiredis.*) AND/OR HEADERS (hiredis/*.h)
        ARE NOT INSTALLED PROPERLY ON THIS SYSTEM.
        THAT'S OK BUT THE TURN SERVER IS BUILDING WITHOUT REDIS SUPPORT. PREFIX=/usr/local OSLIBS= -L/usr/local/lib/ -L/usr/local/lib/ -L/usr/local/lib64/ -L/usr/local/lib64/ -lrt -pthread -lcrypto -lssl -levent_core -levent_openssl -levent_pthreads  -Wl,-rpath,/usr/local/lib/ -Wl,-rpath,/usr/local/lib/ -Wl,-rpath,/usr/local/lib64/ -Wl,-rpath,/usr/local/lib64/ -Wl,-rpath,/usr/lib64/mysql -Wl,-rpath,/usr/local/lib DBLIBS= OSCFLAGS=-g  -Wall -Wno-deprecated-declarations -Wextra -Wformat-security -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Wcast-qual -I/usr/local/include -I/usr/local/include/ -I/usr/local/include  -DTURN_HAS_DAEMON    -DINSTALL_PREFIX=/usr/local DBCFLAGS=

    
	
	
  • 
		1
	
    • 

	
  • 
		2
	
    • 

	
  • 
		3
	
    • 

	
  • 
		4
	
    • 

	
  • 
		5
	
    • 

	
  • 
		6
	
    • 

	
  • 
		7
	
    • 

	
  • 
		8
	
    • 

	
  • 
		9
	
    • 

	
  • 
		10
	
    • 

	
  • 
		11
	
    • 

	
  • 
		12
	
    • 

	
  • 
		13
	
    • 

	
  • 
		14
	
    • 

	
  • 
		15
	
    • 

	
  • 
		16
	
    • 

	
  • 
		17
	
    • 

	
  • 
		18
	
    • 

	
  • 
		19
	
    • 

	
  • 
		20
	
    • 

	
  • 
		21
	
    • 

	
  • 
		22
	
    • 

	
  • 
		23
	
    • 

	
  • 
		24
	
    • 

	
  • 
		25
	
    • 

	
  • 
		26
	
    • 

	
  • 
		27
	
    • 

	
  • 
		28
	
    • 

	
  • 
		29
	
    • 

	
  • 
		30
	
    • 

	
  • 
		31
	
    • 

	
  • 
		32
	
    • 

	
  • 
		33
	
    •

只是说没有数据库支持的库，暂时不需要。

安装之后说明： 

1) If you system supports automatic start-up system daemon services, 
the, to enable the turnserver as an automatically started system 
service, you have to:

        a) Create and edit /etc/turnserver.conf or /usr/local/etc/turnserver.conf . 
        Use /usr/local/etc/turnserver.conf.default as an example.

        b) For user accounts settings, if using the turnserver with authentication: create and edit /etc/turnuserdb.conf 
        file, or set up PostgreSQL or MySQL or Redis database for user accounts.
        Use /usr/local/etc/turnuserdb.conf.default as example for flat file DB, or use /usr/local/share/turnserver/schema.sql as SQL database schema, or use /usr/local/share/turnserver/schema.userdb.redis as Redis database schema description and/or /usr/local/share/turnserver/schema.stats.redis as Redis status & statistics database schema description.

        c) add whatever is necessary to enable start-up daemon for the /usr/local/bin/turnserver. 2) If you do not want the turnserver to be a system service, then you can start/stop it "manually", using the "turnserver" executable with appropriate options (see the documentation). 3) To create database schema, use schema in file /usr/local/share/turnserver/schema.sql. 4) For additional information, run:

   $ man turnserver
   $ man turnadmin
   $ man turnutils

    
	
	
  • 
		1
	
    • 

	
  • 
		2
	
    • 

	
  • 
		3
	
    • 

	
  • 
		4
	
    • 

	
  • 
		5
	
    • 

	
  • 
		6
	
    • 

	
  • 
		7
	
    • 

	
  • 
		8
	
    • 

	
  • 
		9
	
    • 

	
  • 
		10
	
    • 

	
  • 
		11
	
    • 

	
  • 
		12
	
    • 

	
  • 
		13
	
    • 

	
  • 
		14
	
    • 

	
  • 
		15
	
    • 

	
  • 
		16
	
    • 

	
  • 
		17
	
    • 

	
  • 
		18
	
    • 

	
  • 
		19
	
    • 

	
  • 
		20
	
    • 

	
  • 
		21
	
    • 

	
  • 
		22
	
    • 

	
  • 
		23
	
    • 

	
  • 
		24
	
    • 

	
  • 
		25
	
    • 

	
  • 
		26
	
    • 

	
  • 
		27
	
    • 

	
  • 
		28
	
    • 

	
  • 
		29
	
    • 

	
  • 
		30
	
    •

在根目录创建一个user.db文件 

使用turnserver启动： 

turnserver --userdb /root/turnuser.db 里面是webrtc用户名密码： webrtc:secret

    
	
	
  • 
		1
	
    • 

	
  • 
		2
	
    • 

	
  • 
		3
	
    •

3，页面调用

https://github.com/EricssonResearch/openwebrtc-examples/tree/master/web 

安装node参考之前文章： 

http://blog.csdn.net/freewebsys/article/details/46649667#t1

修改main.js 

// must use 'url' here since Firefox doesn't understand 'urls' var configuration = { "iceServers": [
  { "url": "stun:mmt-stun.verkstad.net" },
  { "url": "turn:mmt-turn.verkstad.net", "username": "webrtc", "credential": "secret" }
  ]
};

    
	
	
  • 
		1
	
    • 

	
  • 
		2
	
    • 

	
  • 
		3
	
    • 

	
  • 
		4
	
    • 

	
  • 
		5
	
    • 

	
  • 
		6
	
    • 

	
  • 
		7
	
    • 

	
  • 
		8
	
    • 

	
  • 
		9
	
    • 

	
  • 
		10
	
    • 

	
  • 
		11
	
    • 

	
  • 
		12
	
    • 

	
  • 
		13
	
    •

将stun服务器和turn服务器替换。

4，总结

stun和trun是webrtc打通的关键服务器，但是资源有限没有在公网测试。

webrtc与stunserver、turnserver建立连接花费时间十秒左右

  很奇怪，使用之前基于webrtc的p2p模块时出了了大问题，问题如标题左右，记得之前使用另外版本的webrtc做开发的时候，本地在CreateOffer后能够能够很快和turnserver连接，估计最左就两三秒，然而现在却是十秒左右了！

   由于换了一个webrtc的版本(此版本是支持winxp系统的)，所以第一感觉似乎是webrtc版本的问题，实际上不是，因为就算是换回之前的版本，client和turnserver的连接时间几乎花费了与当前版本webrtc 差不多的时间。

 
 之前也说了，就是之前有点时间，client与turnserver的连接是正常的，于是在google到了一个解决方案，即是trickle
ice技术，据说使用该方法能够大大缩短client与opposite
client的连接时间，这个解决方案似乎和当前所遇到的问题擦着一点边，但是似乎可以值得尝试，因为这或多或少会提升client连接到对面的体验！然而client和turnserver的连接速度是似乎没多大作用，放弃此方案。

   
实际上只要网络状态好，按道理来讲本地client和turnserver的connect
时间应该很短才对，实际上也是如此！后来调试发现在client连接turnserver的过程中在stunrequest.cc中都有调用OnTimeout函数，而且说明本地client和turnserver的连接很不理想，通过查看源码获知在timeout的过程中，本地客户端总共尝试了MAX_SENDS次重发送(发送给turnserver、stunserver)，在源码中MAX_SENDS被宏定义为9，超过9次之后才正式通知外部(OnTimeout),
OnTimeout函数最终会触发webrtc底层，告知client本地的icecandidate的收集已经完成，接着出发了外部的OnIceGatheringChange函数，该函数的icecandidate收集状态state将会为kIceGatheringComplete，此时本地的client才会知道本地的icecandidate信息收集已经完结，那么怎么根据当前peerconnection是否成功和stunserver、turnserver连接呢？如果已经收集到的icecandidate中不但包含了本地的ip信息，还包括了stunserver、turnserver的ip信息，那么就可以决断本地client已经成功和turnserver连接，如果只是包含了本地的ip地址信息(icecandidate信息的type字段为host、local)，那么就可以决断本地client连接turnserver服务器失败。

 
 而我遇到的情况是，从client开始连接到收集icecandidate信息成功花费了太长的时间(10左右)，不过最后还是能够成功连接上turnserver，之前也说了花费了那么长时间全是浪费在timeout上了，那么问题来了？为什么我本地的网络情况良好(可下载、可开网页)，怎么在就是在探测turnserver的时候那么艰难呢？断点查看timeout时对应的ip地址，明白了，这个ip地址是我电脑中之前安装的virtulBox中一个虚拟机的ip地址，这个我真是没想到!查看源码，知道webrtc在探测turnserver的时候是要遍历当前平台下的所有的网络适配器的，不管是系统自带的无限网络、还是以太有线网，还是其他应用软件虚拟出来的适配器，webrtc探测时都会遍历，之所以出现时间是花在timeout上，也只是说明对应的网络适配器在和turnserver尝试连接的时候，网路状况不好！鉴于此，于是在控制面板中将virtualBox中虚拟出来的适配器禁用，重新打开本地的client，发现几乎是秒连了！

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

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

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