主流流媒体软件pplive和ppstream的分析

     现有P2P流媒体软件开发新的流媒体系统，充分了解现有的流媒体软件的优劣得失是必不可少的。主流的软件pplive和ppstream就是分析的对象。以下分析全部基于Sockmon5的数据包拦截。手上资源有限，对协议的分析不很充分。        

     一、pplive：这款软件的数据分发引擎和播放器是分离的，也给了我们专门分析数据分发引擎的机会。 pplive会打开本地的8888端口，作为windows media服务的端口。对于windows media player来说，认为本地8888端口就是一个cs模式的windows media服务（real格式类同）。节点会在一个时段内集中向几十个其他节点发送udp数据包，每一个数据包略有区别，之后收到其他节点回复。分析为确认节点存在的数据包，或许带有测速信息。之后节点会和速度较高的几个节点建立连接。传输的数据包格式无法解析，但是可以看到规律。数据头为十六进制e9034601的数据包从19K到8K不等，内容丰富。其他规格的数据包头还有e9034401、e9034101等等。e9034201似乎是连接断开的标志。e9034501的数据包大小一致，每发送一次第六字节加一，e9034401的数据分发每个数据包是一致的。每一个节点都主动连接含有数据的上线，这可以从节点没有频繁和连续的accept动作看出。否则用户在获取数据之前必定有一组连续accept的被连接过程。一旦选择一个速度最高的节点，则播放所需所有数据都从这个节点获得。这点从获取数据包的流密度和各IP数据包之间的对比可知。在防火墙穿透策略上，经分析得知每个节点把自己的ip地址和开放的端口号汇报到服务器，服务器把这些信息通知有连接需要的节点。节点不区分获得的ip是公网ip还是内网ip（丛发出的udp测速数据包目标经常为192.168.0.*网段可知）。如果是公网的节点发起连接，连接公网ip的节点一般可以正常连接，如果连接内网ip的节点，肯定无法连接。如果是内网节点发起连接，连接公网ip的节点一般可以正常连接，如果连接内网ip的节点，分为两种情况：1、此节点位于不同局域网中，肯定连接不上；2、此节点位于同一局域网中，正好实现了内网互联。由此可知数据分发引擎完全不具备不同局域网的节点连接能力，网络性能非常依赖公网节点数量。按照这种模式开发流媒体产品，对不同媒体格式和媒体服务器的兼容性较好，节点之间连接策略的处理也比较简单高效。但难点在于如何把流媒体服务器和数据分发层连接，和如何模拟流媒体服务器和播放器握手。这部分技术确实可以解决，但之前没有考虑过实现细节。节点开始播放流媒体之前，必须和服务器建立连接，获得节点列表，然后判断节点之间的联通性。和可以连通的节点建立连接，尝试获得数据填充本地缓冲区。在此过程中，判断速度较高的节点。在持续连接建立后，已经可以获得稳定数据，继续保持低速的连接的发起，遇到更高速的节点，则转向由更高速的节点提供数据（此动作为分析得知，没有非常明确的证据）。

       二、ppstream： ppstream内嵌了浏览器，太多80端口的操作严重干扰了对socket的分析。但是出乎意料，ppstream的连接建立过程比pplive清晰得多！ ppstream的缓冲等待画面位于播放窗口内，而不是像pplive那样由数据分发引擎的单独窗口显示。具体内容为嵌入flash的html页面。由61.172.197.242的服务器提供节目表和频道表等内容，web Server：Apache/2.0.54 (Unix) PHP/4.4.0。61.152.199.56似乎是广告的web服务器。 ppstream和pplive共有的关键字串应该是验证协议。连接61.152.240.252：11012， 回复xml格式的广播源信息，可阅读内容为从61.152.240.252获得广播源信息后，开始连接大量节点，握手过程等同于61.152.240.252。从多次不同时段不同频道连接的情况看，此节点为超级node。并且一个节点上同时承载了多路流媒体的广播。分析可知1.0.0.2138为节点版本。产生本地的回环连接，过程如下：接受端口发送信息：连接到本地节点，之后连接断开。发起端口接到信息：连接到本地节点，之后也断开连接。这时已经从61.152.240.252：11012开始缓冲流媒体信息。并且尝试两个新的节点连接。 4436端口完成绑定。内嵌播放器打开http目录下的.asx文件，由4436端口发起连接至18988端口，按照.asx文件内容请求.asf流媒体。18898端口回复服务器信息及ok。4436端口断开。本地4441端口连接18898端口，请求播放.asf文件。本地4444端口连接18898端口，请求播放.asf文件，获得数据信息。规格等同广播源信息中所包含的可阅读内容。与60.220.82.165握手后，接到信息：上层节点服务繁忙,希望进行降层操作，之后连接断开。新连接的节点此时已经开始传输数据至本地缓存，保持稳定传输的有三个节点。同时还有若干连接正在发起。可以看出ppstream的每一个媒体数据包大小为4K。远程向本地请求数据包，的规则同上。握手信息的格式也相同。分析ppstream所采用的是所连接节点向本地节点通知其它节点存在的方法。预想中，这种调度算法认为与自己连接速度快的节点所连接的节点与自己的速度一般也快。以这种优化手段逐步遍历节点树中所有可能高速的节点。