以P2P为基础对流媒体技术进行研究

发布时间：2022-10-05 21:43 热度：

　　摘要：本文提出了一个新的P2P Streaming模型，该模型融合了P2P技术和C/S技术的优点，可以在网络带宽效率、延时和可靠性三者之间做出更好的权衡。该模型通过C/S的方式组织节点而通过P2P的方式分发数据。该模型克服了传统C/S模式的不能支持大规模范围的缺陷，并通过引入MDC有效地解决了网络异构性问题，使不同类型用户都能观看视频。

　　关键词：P2P,流媒体,分层多描述编码,异构性

　　1 引言

　　随着Internet的迅猛发展和普及，流媒体技术广泛应用于在线直播、视频点播、远程教育、视频会议、数字图书馆等领域。但流媒体的传输对带宽、延迟和包的丢失率等服务质量QoS(Quality of Service)都有十分严格的要求，然而随着用户人数的增多，传统的集中式管理使中央服务器负载过重，使得这些服务质量得不到保障。而对等网络(Peer-to-Peer，P2P)系统具有负载均衡、自适应、自组织和容错力强等优点，因此很多研究者开始将对等网络运用到流媒体的传输中来[1]。

　　本文在参考近年来国内外的相关研究成果的基础上，提出了一个新的基于P2P的流媒体系统架构模型—P2PStreaming，该模型融合了P2P技术和C/S技术的优点，可以在网络带宽效率、延时和可靠性三者之间做出更好的权衡。

　　2 基于P2P的流媒体系统

　　2.1 P2PStreaming系统结构

　　如图1所示，本系统采用混合式P2P网络结构，即采用融合C/S模式特点和P2P模式特点的模型，一方面易于实现，可靠性和扩展性高;另一方面，我们可以看出通过把节点管理的功能独立到服务器的管理模块，节点与节点之间交换的数据越多，服务器的负担相对越轻，如果当节点和节点之间交换的数据为零，那么该结构将退化为一个普通的C/S结构，也就是说，即便在最差的情况下系统性能也等同于C/S模式的性能[2]。

　　在系统中，我们采用了基于目录服务的P2P模型，由目录服务器管理整个“内容传输链”，为新加入的客户提供最合适的媒体源，来最大限度地保证整个系统的服务质量，这一点是自组织的、结构比较松散的网络模型很难做到的[3]。图1所示整个系统是由3部分组成：源节点、目录服务器和Peer，图中连线的粗细表示了网络流量的大小，从图中可以看出Peer和目录服务器之间的通信流量只占了整个系统流量的一小部分。主要的通信流量是集中在Peer之间和Peer和源节点之间。系统每个部分的主要功能为：

　　1)源节点：负责提供原始流媒体数据源，并对数据进行分层MDC。源节点逻辑上是与其他节点相同的，只是它是纯粹的资源贡献者，不必下载数据。为了减轻源节点的负担，将源节点的优先级设置为最低，除了最初必须由源节点提供数据外，节点在获取数据时，优先从其它节点获取，除非该节点负荷超出了设置值。

　　2)Peer：下载所需数据，并进行分层MDC解码观看，同时将自己的数据资源共享给系统中的其他节点。

　　3)目录服务器：主要负责收集、统计、更新节点信息，并且对节点进行管理;目录服务器是节点的协调者，它存储网络中所有节点的信息列表，使得节点可以迅速地找到其他连接节点，但是它不能处理与媒体流相关的任何数据，只是为发现节点而存在。

　　2.2 基于分层思想的P2P流媒体系统设计

　　在P2P网络中，客户节点不仅只有客户端的功能，也需要具备部分服务器的功能。为了把复杂的问题简化，并且利于以后系统的升级，我们对P2P流媒体系统采用分层的设计方法，如图2所示，从图中可以看出每个客户节点都具有双重的身份，一个是位于现实Internet中，一个是位于虚拟的P2P网络中，P2P网络是把Internet上有共同兴趣的节点归类在一起的一个虚拟的点对点的网络。

　　从图2看出，整个系统包括了5层，最底层是Internet，它保证数据包的接收和传送，网络探测层可以获取网络状况的信息，包括带宽和时延的估计，防火墙检测等。P2P层实现与其它客户联系或者信息交换。编/解码层进行分层MDC编/解码，系统利用分层MDC增加数据传输冗余，解决网络异构性的问题[4]。

　　3 系统中关键部分的实现技术

　　3.1 目录服务器的实现

　　3.1.1 目录服务器通信的实现

　　本系统中，节点对服务器的访问通过http协议进行，节点加入P2P网络时，先通过HTTP访问服务器，一般的系统中表现为访问WEB页;接着由节点管理模块将每个加入节点的要求都被逻辑上转化为一个CHTTP请求对象，该请求发送给服务器内的数据库，数据库分配给该请求一个相应的URL值，同时数据库对请求进行解析，产生一个CHTTP应答，将该应答返回给节点管理模块，由它发送给请求节点[5]。

　　3.1.2 节点的加入和注销

　　节点登录时通过调用该目录服务器上的登入页面声明它的IP地址和共享资源。服务器的管理模块把节点的IP地址及共享资源信息记录到数据库中。如果执行成功，目录服务器给节点返回代表成功验证信息：如果失败，则返回包含失败原因的文档。当节点要从P2P网络注销时，需要调用该服务器上的注销页面。服务器的管理模块根据该节点的IP地址等信息，从数据库中删除该节点的相应记录。

　　3.1.3 伙伴列表的获得

　　如果节点想了解当前存在的其他节点的情况，先请求管理模块，由它查询数据库，把查询结果返回给请求节点，包括其他节点IP地址、所有数据等信息。则节点就可以得到当前存在的其他节点的连接信息，进而和其他节点进行直接通信。节点利用服务器搜索查询特定的节点或共享信息的机制也是如此。

　　3.2 节点的实现

　　节点能力或者说异构性级别(Capacity or Heterogeneity Level)的概念至关重要。我们将节点的能力概括为一个包括网络访问带宽、处理器主频、内存容量及外存访问延迟等参数的向量。对于特定的流媒体应用而言，与服务质量关系最为密切的参数就是节点带宽。因此，在我们的模型中，我们把节点的网络访问带宽作为最关键的参数，并根据这个参数来为节点定级。带宽还能很好的描述节点的异构性。这里节点的信息被存储在数据库中，当一个节点请求数据时，节点管理模块通过访问数据库得到节点需要的路由信息，并发送给相应节点，请求节点就向相应的节点发起请求，建立连接，进行数据的传输。

　　3.2.1 节点间通信的实现

　　1) 节点间通信的建立过程

　　节点之间的通信遵循“请求-应答”的模式。节点成功登录服务器后在特定的端口监听来自其它节点的请求。想要发出请求的节点根据请求的类型和内容在内存中生成相应格式的信息，然后向目的节点的监听端口发出连接请求，建立连接后，把信息放入输出流。被请求节点收到请求后，取出并解析请求信息，根据它的类型和内容作出相应的动作。

　　2)节点状态

　　每两个建立连接的节点之间，一个节点中对另一个节点设置两个状态：阻塞(choking)与感兴趣(interesting )，这两个状态仅在两个连接的节点之间。“阻塞”表示是否愿意给对方传送数据，如果节点阻塞对方，表示该节点就不会给对方传送数据，对方即使向该节点请求下载，该节点也不会回应。只有当该节点通知对方取消阻塞，对方才能开始向该节点请求下载。“感兴趣”表示对方是否有该节点需要的数据，如果有，那么该节点对对方感兴趣，否则不感兴趣。实际上，节点还需要保存对方对该节点的两个状态，也就是说，节点对每个连接保存了四个布尔值：(1)am_choking：对方被阻塞;(2)am_interesting：对对方感兴趣;(3)am_choked：被对方阻塞(4)am_interested：对方对自己感兴趣。其中前两个值是自己设置的，后两个值是根据对方的通知来设置的。初始值阻塞为1，感兴趣为0。当节点不阻塞对方，且对方对该节点感兴趣时，节点才有可能向对方传送数据。

　　3)节点间数据交换过程

　　通过节点间通信的建立过程后就开始节点的数据交换过程。节点间通信才是实际的P2P通信，文件的传输都是在这一部分完成的。节点之间通信是基于TCP协议之上的。

　　3.2.2 编/解码层数据组织

　　为了方便节点之间交换缓存信息，需要对媒体数据进行离散化的表示。为了适应网络的异构性，在P2PStreaming中部署了分层多描述编码，码流首先由一个基本层和多个增强层组成，然后对基础层采用MDC，分别用：代表每一个层，其中n表示分层的数量，m表示基础层描述的数量。在把每一个层离散成时间长度相等的片段(每个片断的时间为T)，每一层都用一个缓存映射 来表示节点中是否拥有某个片断的数据。节点通过更新伙伴的BM来了解伙伴的缓存情况。在本文中，假设每个片断代表一秒的数据，用一个滑动窗口( Sliding window)来代表BM，大小为30个片断，BM中用30个比特来记录，每个比特代表一个片断是否存在，1表示有这个片断，0表示没有。

　　3.2.3 伙伴列表的管理

　　系统内的每个节点自己维护一个伙伴列表Partnerlist，节点可以从伙伴节点获取媒体数据。其实，源节点作为一个特殊的节点是所有节点的伙伴，但不承担下载数据的责任。节点和伙伴节点不断的交换各自的缓存信息，然后根据伙伴的缓存信息，通过一定的数据调度算法从伙伴节点获取媒体数据。

　　4 系统安全

　　4.1 节点信任关系

　　在P2P系统中，各个异构的对等点共享各自的资源，某些对等点乐于提供服务，某些对等点可能是恶意的，不能够提供满足质量的服务，而在分布式的环境下，没有一个中心节点来对其进行监控，传统的安全技术主要是采用授权认证，只能防范已知的恶意节点，对于那些未知对等点和提供可变质量服务的对等点无能为力，因而需要建立一种节点安全信任模型来区分搭档的好坏[6]。

　　4.2 路由的隐患

　　4.2.1 不正确的路由查询

　　第二代P2P，比如chord，CAN等的查找协议需要维护路由表来进行节点路由定位，恶意节点可以将某个查询请求发往错误或者不存在的节点，从而导致路由失败，请求重传。因为恶意节点也可以参与到路由更新算法中，他不能够从其它节点的路由表中完全删除，这样重传的请求会被再次发送到恶意节点。对于这一问题，可以通过节点追踪来解决，查询请求的每一跳所路径的节点关键字都应该不断的向目标关键字靠拢，一旦违反了这一规律就可以断定路由存在错误，返回到上一个正确节点从新进行发送。这种办法需要每个节点具有跟踪查询请求的能力，路由的每步对于请求的发送方都是可见的。

　　4.2.2 不正确的路由更新

　　各个对等点的路由信息都是通过其他节点获得的，给恶意节点以机会可乘，恶意节点可以不断发送不正确的路由更新信息，从而破环了其它节点路由表信息的准确性，这种攻击的后果是一些无辜的节点会把路由请求发送到不正确的或者不存在的节点上去。但是如果系统能给正确的路由更新消息某种标志，让其他节点可以识别路由更新消息的真伪，这一问题就会迎刃而解。比如，在Pastry中，每一个路由更新消息需要各个表入口有一个正确的前缀。这样不正确的路由更新可以很容易的识别，只有当一个节点被证实是可达时，才能被更新到路由表中。

　　参考文献

　　[1] 钟玉琢，向哲，沈洪.流媒体和视频服务器[M].北京：清华大学出版社，2003

　　[2] 杜茗，常朝稳.基于移动通讯网络的流媒体播放系统设计方案[J].微计算机信息，2006，8(2)：275-278