CN102984279A - Cdn预先主动选择优质节点开展优化内容分发服务的方法 - Google Patents

Abstract

本发明属于网络多媒体技术领域，具体为一种CDN预先主动选择优质节点开展优化内容分发服务的方法。本发明在覆盖网中加入了一个放大层；CDN服务器通过从对等节点得到的信息选择一定数量优质的节点作为放大层节点；在系统性能不好或服务能力有限的时候，CDN直接优先服务这些节点而不是盲目地服务普通节点，这些优质节点再继续服务普通节点，从而把流媒体数据进行更高效的传播。通过这种方式，CDN可以和P2P、VOD等系统进行更高效的合作。本发明经试用，运行稳定，结果表明,本发明与现有传统的CDN-P2P混合架构相比，性能至少提高了10-25%,实验比较指标包括启动延时、播放质量以及播放延时。

Description

CDN预先主动选择优质节点开展优化内容分发服务的方法

技术领域

本发明属于网络多媒体技术领域，具体涉及一种面向新一代互联网环境的CDN预先主动选择优质节点开展高效优化内容分发服务的方法。

背景技术

数字内容产业在下一代IP网络的应用中占有十分重要的地位。新一代互联网中，随着宽带的发展，互联网应用已经从单纯的Web浏览转向以丰富的内容为中心的综合应用，丰富媒体内容的分发服务将占越来越大的比重，流媒体、IPTV、大文件下载、高清视频等应用逐渐成为宽带应用的主流。根据Cisco2010年视频网络调查报告，2010年视频流量占到整个Internet流量的三分之一，预期在2014年超过57%。这些视频应用所固有的高带宽、高访问量和高服务质量要求对以尽力而为为核心的互联网提出了巨大的挑战，如何实现快速的、有服务质量保证的内容分发传递成为核心问题。特别是随着网络融合的趋势，不同的终端将通过不同的网络来获取内容和服务，构建一个IP之上的、应用无关的、可运营的电信级通用内容承载平台具有重要的意义。在这种情况下，CDN（Content Delivery Networks）和P2P（Peer to Peer）先后应运而生，以不同的方式解决了内容承载问题。CDN和P2P是当前互联网上实现内容分发传递的两种主流技术。但是受计算模型的制约，二者各有优势，也都存在一些根本的缺点：CDN的高成本和高复杂性制约了其规模扩展的能力，P2P则在网络友好性、可靠性和可管理性上有较大问题。CDN和P2P内容分发模式的融合是一个重要的发展趋势。P2P和CDN融合的驱动力来自于二者互补的计算模型。近几年来工业界和学术界都在研究和开发CDN和P2P、VOD等各种流媒体系统融合的技术。一些研究和开发项目已经开始集中CDN-P2P的混合架构上。通过我们对CDN-P2P的混合架构技术所做的调研和对现有技术的分析，我们发现在大多数这些系统中，CDN只是对请求的P2P和VOD客户节点提供了一种消极被动和尽力而为的服务，P2P、VOD等流媒体系统和CDN服务器之间没有动态的交互行为，CDN并不能提供有选择性和主动的服务。在这个背景下，我们提出了CDN预先主动优化选择节点服务的技术。

经对现有技术的文献检索发现，Akamai在2008年申请一项公开专利：“Hybridcontent delivery network (CDN) and peer-to-peer (P2P)network”。在这项专利里面，他们描述了以下几个机制：一个典型的内容分发网络(CDN)包括一个映射系统，它可以把用户的请求引导到相应合理的CDN服务器上。多个客户节点与CDN服务器产生关联，映射系统被用来使一个节点可以在网络中定位另一个对等节点或者是CDN服务器。使用这种结合技术后，CDN用户的下载内容可以来自CDN边缘服务器、P2P网络或者是同时来自它们二者。具体的，用户内容被上传到CDN边缘服务器，接着CDN初始化一个P2P网络，这个P2P网络将在后期承担部分的用户请求。在该专利中，P2P节点的请求是由边缘服务器来服务还是由P2P网络来服务取决于网络的具体负载和流量情况，CDN节点并不能主动和优化选择Peer节点来有选择地提供服务。

发明内容

本发明的目的在于提出一种CDN预先主动选择优质节点开展优化内容分发服务的方法。

在P2P或VOD等流媒体系统节点租用和使用CDN节点提供服务的过程中，因为CDN节点的服务能力是有限的，CDN节点不是盲目地尽力而为对所有请求节点提供服务，而是根据采集的信息主动和预先选择优质节点来提供针对性服务，这些被选择的节点在获得CDN服务后可以更好地为其他普通Peer节点或客户服务,在整个流媒体分发网络中能够起到更好的放大传播作用。

本发明提出的CDN预先主动选择节点进行针对性优化高效服务的方法，具体步骤为：

第一步: 定义和构建放大层。

当一个对等节点进入覆盖网络时，它可以从一个Tracker服务器上拿到一份节点列表。接着它将会把该列表中的节点作为自己的邻居并与之建立连接，之后可以互相传输数据。如果一个节点正在启动或者播放质量下降，它将通过请求Tracker服务器使其数据请求重定向到CDN服务器上。CDN节点可以通过自己的交互接口获得对等节点的有用信息。如节点的缓冲区情况、邻居列表和上传带宽等等。 根据这些信息，系统通过节点选择算法和节点替换策略来决定将服务哪些节点以及服务的时间长度。在本发明中，我们把一个边缘CDN服务器以及它所领导的一批对等节点看作是一个自治区。因此，整个系统被分为了许多个不同的自治区，每个自治区有一个CDN节点。在每个自治区内部，CDN节点可以通过从其所管理的对等节点那获得的信息来决定系统的问题和瓶颈，从而选出合适的中介放大层节点并为之提供服务。CDN节点使用轻量级的方法来收集P2P节点的统计信息。每个对等节点不需要定期向其自治区的CDN节点汇报所有自己的信息。它们只要 在向CDN节点请求紧急数据块的情况下汇报这些信息即可，节点汇报的具体信息如下表所示。

表格1 节点汇报信息

每个汇报信息中都必须包括节点ID和时间戳。一般来说对于请求紧急数据的对等节点来说，会提供1.请求块列表2.筛选后的邻居列表。如果一个节点被选为中介放大节点而接受CDN服务器的服务，它将提供的信息有：1.播放缓冲区情况2.播放点。当CDN服务器决定是否继续服务一个中介放大节点时，CDN将会让该对等节点提供：1. 流量上传速度2. 播放缓冲区情况3.上传带宽使用率4. 播放点。有关于这些请求和放大层节点的具体信息将在下文进行详细描述。

 (1) 发明放大层节点的基本架构

这部分实际上就是对原有的网状结构加了一个扩展层，即有若干节点直接从服务器获取数据，获取数据的方式采用的是Pull模式。假设CDN允许直接服务N个节点，就会有N个节点与CDN做邻居，其它节点均不能与CDN做邻居。主要结构如图1所示。

(2) 放大层的初始建立机制

在开始阶段，CDN节点开放N个直连通道，但没有节点与其连接，之后随着Peer节点（Peer节点即是对等节点）的陆续加入，CDN开放的N个直连通道会依据某种算法被使用。

所谓放大层的含义就是，在放大层的节点的上传带宽必须大于支持播放的最小码流。设观看所需的最小码流大小为a，放大层中节点的最小上传带宽为b，则必须满足条件a<b，这样在它服务其他普通节点时才能起到放大传播的作用。

设StreamingRate是流媒体直播中正常观看所需要的码流大小，N为放大层中节点的个数，则服务器在放大层中所消耗的流量总和为，

U_direct=StreamingRate * N     （公式1）

设为放大层中节点i（i∈[1,N]）的上传带宽，则放大层节点在上传带宽充分利用的情况下提供的流量将是，

$U_{\mathrm{magnification}}=\underset{i=1}{\overset{N}{\mathrm{\&Sigma;}}}{U}_{{\mathrm{peer}}_i}$ （公式2）

显然有U_{magnification}≥U_direct

节点进入放大层的算法代码流程如下：

在本发明中,算法初始运行阶段，需要添加邻居的节点都会优先考虑是否可以与CDN节点建立直接的连接，接着才会考虑与其他节点建立连接，这就保证了CND节点开放出来的直连通道能够被对等节点快速优先使用。这里注意到，如果一个节点已经是直连节点，它就不能与其他放大层节点建立邻居关系，这样做的目的一是让这些放大层的节点尽可能的服务其它普通节点；二是由于放大层节点本身不缺少内容块，它们的块都是从CDN服务器直接获取的，所以让两个放大层节点互为邻居没有意义。

找邻居算法是当一个对等节点所拥有的邻居节点数目小于一个节点所允许的最大邻居数时触发的。每个对等节点都会定时检查自己的实际邻居数，一旦符合条件，该算法将被执行。

网络中上传能力较强的节点，它们可以为自己的邻居节点提供较好的服务。中介放大节点算法的思路就是，当系统的性能下降时，本发明会通过服务这些能力强的节点，让这些节点有较完善的数据，从而这些节点可以更好的为它们各自的邻居服务。这样CDN服务器只要推出一道流给这些中介放大节点，就可以通过该节点把数据块传播出去。因此这些节点就是一个中介节点，它们的作用是为了更好的服务自己的邻居节点。问题是如何找到合适的中介放大节点，CDN节点辅助它们多久时间最为合适是本发明解决的关键问题。

第二步: 选择和确定进入放大层的节点

每个向CDN服务器请求紧急数据块（快要播放的数据块）的消息中，都会同时会附上节点本身的一些信息，这些信息如第一步所述；CDN通过定期统计分析这些信息，找到中介放大节点并对其予以帮助，来提高系统总体性能。目标是该中介放大节点要足够强，并且它的邻居节点播放质量要相对较差，这样才能达到最好的效果，让CDN服务了最该服务的节点。

在系统中，节点会向CDN请求紧急的数据块（前文已描述），做法是节点向CDN节点发送块请求包，请求包内包括该节点所要请求的块和该节点的邻居中能力比较强的邻居节点id。在此，所谓能力比较强的节点指的是邻居节点中上传带宽处在前50%的节点，如果能力太差将无法达到放大流量的效果。请求包格式如下，

节点ID

时间戳

请求块列表

筛选后的邻居列表

每隔一段时间，CDN节点都会对收集到的数据进行分析，统计每个请求节点的邻居列表中的节点出现次数，并从中找出出现次数最多的若干个节点作为中介放大节点。该算法发明的理论依据是：当一个节点在统计信息中出现的次数越多时，说明它有越多的邻居请求紧急数据块，从而推出该节点的有较多邻居的播放质量较差。但由于该节点能力较强，所以CDN节点通过把数据块推送给该节点，让其将数据扩散给其周围邻居，这样CDN只需推一道流就可以改善尽可能多的对等节点的播放质量。具体操作如图3所示.

其中暗色节点表示向CDN服务器请求紧急数据块的节点。连线表示了汇报关系，如节点2向CDN节点汇报了自己的邻居4和5。于是图3（a）表示的是节点2、6、8都向CDN节点请求紧急数据并报告它们较强的邻居节点，报告信息如下表：

表格2 CDN节点统计信息

节点ID	较强邻居列表
		2	4，5
6	3，4
		8	4，5，7

节点4是出现最多的节点，出现了3次，节点5出现两次，节点3一次，节点7一次，因此节点4被选为中介放大节点。这些节点信息被存在HashMap里面，HashMap的Key值是节点的id，value是该节点被统计的次数。如图3（b）。

CDN对对等节点的信息收集算法流程图如图4所示。

这里有两重判断条件，第一层判断使得只有请求块数超过α块的节点才予以统计，根据实验统计，如果不加这一条件，在系统不稳定阶段，几乎所有节点都会向CDN服务器要数据，也就是所有的节点都会被统计，这样就失去了区分度。通过使用阈值α，能过滤掉一批次要节点，α在实验中为3。另外，由于CDN每隔一段时间会执行该算法，为了避免同一节点在该时段内多次向CDN节点发出请求，导致其邻居多次被计入统计信息，因此加了第二层判断条件来过滤这种情况。

最终CDN边缘服务器要选出k个节点作为中介放大节点。k的计算方法如下，

$k=\min (\frac{U_{\mathrm{CDN}}-U_{\mathrm{outgoing}\_\mathrm{rate}}}{\mathrm{STRM}\_\mathrm{RATE}*\mathrm{\&alpha;}}*\mathrm{\&beta;},\frac{{\mathrm{NUM}}_{\mathrm{online}\_\mathrm{nodes}}}{10})$ （公式3）

$\mathrm{\&beta;}=e^{(\frac{{\mathrm{NUM}}_{\mathrm{req}}}{{\mathrm{NUM}}_{\mathrm{online}\_\mathrm{nodes}}}-1)}$ （公式4）

在公式中，α是常数，代码中为0.75，分子中U_CDN是CDN的服务带宽能力，U_{outgoing_rate}是CDN服务器目前正在提供的服务带宽，它们相减是CDN服务器的剩余带宽乘，实际上STRM_RATE*α是对CDN服务一个瓶颈节点每秒所需流量的期望值，是预估CDN剩下的流量最多能服务多少个中介放大节点。但由于把所有剩下的流量都用于服务瓶颈节点不切实际，因此要乘以一个(0,1)中的数β。其中NUM_req是在该时间段内向CDN服务器发出请求的节点个数，NUM_{online_nodes}是该边缘CDN服务器所管的节点总数。显然，当请求紧急块的节点个数越多，说明系统状况越不好，这时就需要CDN节点来服务更多的中介放大节点一提高系统性能，在公式中有

得到

因此

这么做的原因一是当请求节点数增加时β值也随之增加，二是为了让β的下限不至于过小。最后为了让k的值不要太大，因此加了个上线

即该边缘CDN服务器所管的节点总数的10%。

第三步:给放大层节点提供内容分发服务

当CDN服务器从统计信息中找出k个（有可能小于k，因为统计信息中的节点个数有可能小于k）中介放大节点，就会同时向这些节点发送服务启动消息，这些中介放大节点在收到服务启动消息后，会返回自己的BufferMap给CDN服务器，CDN服务器根据每个节点的BufferMap情况进行相应的服务。主要流程如图5所示。

CDN服务器服务中介放大节点采用推（Push）的方式，推送区域是整个普通区，如图6所示。选择该区域为服务对象的主要原因是为了降低冗余块的个数，即节点自身拉到的块与CDN服务器推来的块相互重叠。这是因为这部分区域在块调度过程中的优先级是最低的。因此CDN服务器首先会查看中介放大节点的缓冲区，找出在该服务区域内的所有缺失块，并以一定码流大小将其推送至对等节点。为了减少冗余，对等节点在收到服务启动消息时，会对CDN服务器服务部分的数据块做标注，使得节点本身不会去主动下载该区域内的数据块。

CDN服务器会根据如下公式决定在多少时间内把所有数据全部推送给对等节点：

$T_{\mathrm{fast}}=\frac{{\mathrm{NUM}}_{\mathrm{lack}}}{\mathrm{STRM}\_\mathrm{RATE}/\mathrm{STRM}\_\mathrm{PACK}\_\mathrm{SIZE}}$ （公式5）

T_slow=T_fast×2（公式4-8）

$T=T_{\mathrm{slow}}-(T_{\mathrm{slow}}-T_{\mathrm{fast}})\&times;\frac{{\mathrm{NUM}}_{\mathrm{req}\_\mathrm{nbr}}}{{\mathrm{NUM}}_{\max \_\mathrm{nbr}}}$ （公式6）

NUM_lack指的是该服务区内缺失块的个数，显然，Tfast是把这些缺失块以播放码流的速度送出时所需要的时间，Tslow是把这些缺失块以播放码流速度的一半输出所需要的时间。NUM_{req_nbr}表示该节点有多少邻居向CDN服务器请求紧急块，NUM_{max_nbr}表示每个节点的最大邻居数，因此

最终的时间T介于T_fast和T_slow两个值之间，相应的传输速度介于播放码流的一半和播放码流之间。可以看出对于一个节点来说，在一段时间内自己有越多的邻居向CDN服务器发出紧急块请求，时间T就越短，相应传输速度也就越快。

第四步: 判断对放大层节点的服务是否延续

当CDN节点服务了一个放大层节点一段时间T后，会根据该节点的表现决定是否继续服务该节点，判断是否继续服务的公式如下：

$U_{\mathrm{average}}=\frac{{\&Integral;}_{t=\mathrm{start}\_\mathrm{service}}^{t=\mathrm{current}\_\mathrm{time}}{U}_{\mathrm{outgoing}\_\mathrm{rate}}\left(t\right)\mathrm{dt}}{T_{\mathrm{current}\_\mathrm{time}}-T_{\mathrm{start}\_\mathrm{service}}}>U_{\mathrm{outgoing}\_\mathrm{rate}}(\mathrm{start}\_\mathrm{service})$ （公式7）

其中U_{outgoing_rate}(t)表示时刻t时，节点的上传速度大小，

表示从CDN服务节点开始到现在，该节点上传的流量总数，U_average表示服务期间瓶颈节点的平均上传流量。U_{outgoing_rate}(start_service)表示被服务前中介放大节点的上传速度。满足以上不等式，CDN即可继续服务该对等节点。继续服务的缓冲区区间不变，CDN服务器会根据如下公式决定在多少时间内把所有数据全部推送给对等节点：

$T=T_{\mathrm{slow}}-(T_{\mathrm{slow}}-T_{\mathrm{fast}})\&times;\frac{{\mathrm{Upload}}_{\mathrm{peer}}-U_{\mathrm{current}}}{{\mathrm{Upload}}_{\mathrm{peer}}}$ （公式8）

T_fast和T_slow的意义与上节相同，Upload_peer表示中介放大节点的上传带宽，也就说如果瓶颈节点剩余的上传带宽越大，时间T将越短，对应流量也就越大。

第五步: 放大层节点的更换

每隔一段时间，直连节点都会对自己的邻居进行一次扫描，找出那些能力即上传带宽比自己强，且不是直连节点的邻居节点。找到以后，该直连接节点将利用一定策略，把该节点置换到放大层，而自己重新变为普通节点从放大层退出。

图7是放大层节点更换算法的流程图，每个节点定时触发一次该算法，只有放大层的节点才会真正执行该算法流程。在找出的优质邻居节点符合交换条件的时候，首先会判断该邻居节点的邻居数是否达到了上限，如果没有，只需简单的让该邻居与CDN节点建立连接，本节点与CDN断开连接，这样该邻居节点的邻居数增加一；否则需要解除本节点与该邻居节点的邻居关系，用以腾出该邻居节点的可用邻居连接让给CDN服务器。

当一个放大层节点离开系统时，它会选出自己最强的邻居节点来替换自己，这样保证了放大层节点的扩展性和稳定性。图8是简单的示意图。

具体算法流程如下：

1.向自己的所有邻居发送断开连接请求。

2.如果是非放大层节点转第五步，否则转到第三步。

3.遍历自己的邻居列表，找出能力最强的节点（该节点有可能上传带宽没有达到放大层所需的要求，但一定是该退出节点最强的邻居），对该最强节点发出消息包，使其在邻居列表加入CDN边缘服务器的信息并把退出节点的信息从邻居列表中删除。

4.向CDN服务器发出消息包，使其在邻居列表加入新节点的信息并把该退出节点的信息从邻居列表中删除。

5.删除本机邻居列表中的所有信息并退出系统。

第六步: 定时监控放大层节点

虽然放大层的节点在找邻居时会避免与同样在放大层的节点建立邻居关系，但由于上一节的放大层邻居交换算法，可能导致以下这种情况的发生，如图9所示。

开始的时候，放大层有节点1、2、3，节点4作为一般节点同时与放大层中的节点1和2互为邻居。过了一段时间，节点2利用节点交换算法，把能力比自己强的节点4交换到了放大层。此时，节点4作为放大层节点，却与同为放大层节点的节点1互为邻居，从而导致放大层节点内的节点互为邻居，浪费了放大层节点的对外连接数。这就是监控算法的必要所在，算法流程如图10所示。

该算法对于节点来说同样也是间隔一段时间执行一次，其思路很简单，就是首先判断自己是不是放大层节点，不是的话直接退出操作；否则，检查自己所有的邻居，如果发现没有一个邻居是放大层节点的话就退出，否则将解除自己与该节点的邻居关系，由于解除邻居关系后本节点的邻居节点个数减少，因此要重新执行邻居查找算法对自己的邻居数进行补充。

第七步: 动态调整放大层节点的数量

在一个实际的系统中，Peer节点进出频繁且系统总节点个数是不断动态变化的，因此放大层的节点数目不应该是个静态的数值。一般情况下，系统中服务的节点数目越多，放大层中所需的节点数也应该越多，尤其是在一段时间内有大量节点陆陆续续的加入时，更需要增加放大层中的节点数目来提高系统的服务质量。

本发明通过利用CDN服务器在运行时收集到的信息来动态调整放大层中的节点数量。动态调整算法如下：

其中node_num 表示放大层中允许的最大节点数量，urgent_outgoing表示CDN服务器用于服务peer节点紧急请求的平均上传流量， direct_outgoing表示服务放大层的平均上传流量，这两个平均上传流量定时统计一次。实验代码的具体做法是以十秒为一次统计单位，在该时间段内统计各自流量消耗总数，到达第十秒时把各自流量总数除以十秒即得到相应每秒的流量大小，接着清零进入下一次的统计阶段。

一般来说，放大层的节点数目越多，系统性能也会相对更好， CDN服务器在放大层的流量开销也会越大，但系统从长远角度来说会消耗更少的流量。因为服务对等节点紧急数据请求的流量开销将会随着系统性能的提升而减少，随着系统性能的下降而升高。

表格3放大层节点数量动态调整算法

因此，当有过多的节点向CDN服务器发出紧急块请求时，也就是说该比值较大时，说明此时系统的播放质量不太好，因此要加大放大层节点的数目来解决这一问题， node_num*1.3的意思是放大层中允许的最大节点数量变为原来的1.3倍；反之，当该比值较小时，说明放大层的节点数量过多，为了减小CDN服务器的上传带宽以支持更多的流媒体频道数，我们可以适当降低放大层中的节点数目， node_num/1.2的意思是放大层中允许的最大节点数量除以1.2。注意到参数α和β，这两个参数是开启该算法的时间阈值，本文取值为30秒和150秒。注意到node_num在算法中有上下界outbound_bw()*0.8/STRM_RATE和3，这样能保证node_num在有效的范围内浮动，不至于太小或者太大。该算法的公式表示如下，

$\mathrm{node}\_\mathrm{num}=\left\{\begin{array}{ccc}\mathrm{node}\_\mathrm{num}*\mathrm{\&theta;},& \mathrm{if}& \frac{\mathrm{urgent}\_\mathrm{outgoing}}{\mathrm{direct}\_\mathrm{outgoing}}\&GreaterEqual;0.4\\ \frac{\mathrm{node}\_\mathrm{num}}{\mathrm{\&lambda;}},& \mathrm{if}& \frac{\mathrm{urgent}\_\mathrm{outgoing}}{\mathrm{direct}\_\mathrm{outgoing}}\&le;0.15\end{array}\right.$ （公式9）

其中θ是1.3，λ是1.2。

综上，本发明在覆盖网中加入了一个放大层；CDN服务器通过从对等节点得到的信息选择一定数量优质的节点作为放大层节点；在系统性能不好或服务能力有限的时候，CDN直接优先服务这些节点而不是盲目地服务普通节点，从而把流媒体数据进行更高效的传播。通过这种方式，CDN可以和P2P、VOD等系统进行更高效的合作。本发明经试用，运行稳定，结果表明,本发明与现有传统的CDN-P2P混合架构相比，性能至少提高了10-25%,实验比较指标包括启动延时、播放质量以及播放延时。

附图说明

图1为放大层节点结构。

图2为放大层构建算法流程图。

图3为中介放大节点找寻过程。其中，（a）表示的是节点2、6、8都向CDN节点请求紧急数据并报告它们较强的邻居节点，（b）中HashMap的Key值是节点的id，value是该节点被统计的次数。

图4为统计信息收集算法流程图。

图5为 CDN-P2P推服务交互过程。

图6为中介放大节点服务区示意图。

图7为放大层节点更换算法流程图。

图8为放大层节点更换算法示意图。

图9为放大层节点更换示意图。

图10为放大层节点定时监控算法流程。

图11为500个节点的启动延时比较结果。

图12为500个节点的播放延时比较结果。

图13为500个节点的播放质量比较结果。

具体实施方式

为了实施方法发明的全过程并评估发明算法的性能，本发明使用著名的仿真软件p2pstrmsim来执行大规模节点（500-1000）仿真实验,它是由清华大学博士生张萌等人开发的。这个模拟器原本主要支持基于拉模式的流媒体传输策略。我们在此基础上增加了一个可配置的CDN层。以下是我们实验实施的详细参数设置：

表格4 实施实验的详细参数设置

在我们的实施案例中，我们可以配置多个CDN节点个数来并可以切换CDN-P2P算法策略的种类（它们分别是原始的NATIVE-CDN-P2P 和我们的CPDID-CDN-P2P）。一个CDN节点拥有50M的上传带宽，并维护着一批邻居节点。在规模为500个节点的实验中，2个CDN节点在一开始时就加入了系统；同样在规模为1000个节点的实验中，3个CDN节点在一开始时就加入了系统。它们将提供所有的视频数据块。当节点加入系统时，它将通过一个叫做tracker的服务器从现有的节点中找到自己合适的邻居。在播放过程中，如果一个客户端发现自己的对等节点邻居无法满足自己的播放需求时，它将会主动的向离自己最近的CDN节点要数据。在NATIVE-CDN-P2P系统中，当一个节点为了在短时间内可以启动，它会直接贪婪的向CDN服务器发出请求，而我们的CPDID-CDN-P2P系统会使用我们前几章 所介绍的算法来合理有效的利用CDN服务器资源。

在我们的实验中，我们使用了以下几个指标来评估算法的性能，它们可以在一定程度上表现出客户端的用户体验。

启动延时，是从用户加入该流媒体直播频道一直到他收到了足够的块可以播放视频的这一段等待时间。

播放延时，是源服务器产生数据块到用户播放该数据块的时间延时。所谓平均播放延时是指把所有客户端的这一延时相加取平均值。

播放质量，是指在播放中实际成功播放的块数与理想情况下所应播放块数的比值。这一比例越低，说明播放过程中跳过的数据块越多，播放质量也就越差。特别指出的是该模拟仿真软件在客户端播放到某缺失块时并不执行缓冲等待操作，而是直接跳过处理。

该实施案例中，模拟时间长度为600秒即10分钟，模拟节点总个数分别为500个和1000个。系统中有三种类型的节点，上传能力分别为512000、384000、128000bps，比例为0.15、0.50、 0.35，在头300秒所有能力不同的节点均匀加入该系统，其中20%的节点陆续在系统的后300秒退出。α和β分别取值为30秒和150秒。初始时，CDN服务器在放大层开放6个直连通道。实验中每个peer节点的缓冲区长度为20s，

为12秒。

图11中展现了2个CDN带500个对等节点的情况。图中用累计分布图（cumulative distribution function (CDF)）表示了两种P2P-CDN混合系统的启动延时。在CPDID-CDN-P2P系统中，60%的节点启动延时少于25秒，而在传统的NATIVE-CDN-P2P系统中，大多数节点的启动延时是大于30秒的。经统计，CPDID-CDN-P2P系统中各节点的启动延时平均为27秒，而传统系统为35秒,提高率为23%.

图12中展现的是在500个节点的规模下，NATIVE-CDN-P2P系统和我们的CPDID-CDN-P2P系统在600秒的模拟时间内的平均播放延时。在我们的混合架构下，播放延时从原来的23500毫秒被降低到了22500毫秒左右。这是因为请求紧急数据块的节点和中介放大节点都是直接从CDN服务器拿到自己所需的数据块，因此这些直接从CDN服务器上拿到的数据延时比较小，降低了平均的播放延时。而传统的块调度算法中，节点拿到的一般是已经中转过好几轮的数据块，节点的播放延时也相应较大。

可以从图13看出我们的CPDID-CDN-P2P系统拥有比NATIVE-CDN-P2P系统更好的播放质量。原因有以下几点，首先我们的把贪婪算法和稀缺块优先下载算法相结合的策略比以往的块调度算法更有效；其次，节点可以向CDN服务器请求紧急数据块，也对播放质量的改进做出了巨大的贡献。由于CDN服务器的上传带宽比过去一般的源服务器大得多，所以利用它来辅助P2P系统能收到很好的效果。由于贪婪算法和稀缺块优先下载算法相结合的策略运行效果比较好，且向CDN节点要数据的紧急区又比较短，因此CDN在紧急数据块请求服务方面所使用的开销并不很大。

Claims (2)

1.一种CDN预先主动选择优质节点开展优化内容分发服务的方法，其特征在于具体步骤为：

第一步: 定义和构建放大层

把一个边缘CDN服务器以及它所领导的一批对等节点看作是一个自治区，把整个系统分为多个不同的自治区，每个自治区有一个CDN节点；在每个自治区内部，CDN节点通过从其所管理的对等节点获得的信息来决定系统的问题和瓶颈，从而选出需要媒体内容数据并能力强的节点进入放大层，并为之提供服务；CDN节点使用轻量级的方法收集P2P节点的统计信息；每个对等节点不需要定期向其自治区的CDN节点汇报所有自己的信息，只要在向CDN节点请求紧急数据块的情况下汇报这些信息；

每个汇报信息中都必须包括节点ID和时间戳；对于请求紧急数据的对等节点来说，提供：（1）请求块列表，（2）筛选后的邻居列表；如果一个节点被选为中介放大节点而接受CDN服务器的服务，它提供的信息有：（1）播放缓冲区情况，（2）播放点；当CDN服务器决定是否继续服务一个中介放大节点时，CDN让该对等节点提供：（1）流量上传速度，（2）播放缓冲区情况，（3）上传带宽使用率，（4）播放点；

 (1) 建立放大层节点的基本架构

是从原有的P2P网状结构中选拔节点形成一个扩展和放大层，即有若干节点直接从服务器获取数据，获取数据的方式采用的是CDN直接Push模式；假设CDN允许直接服务N个节点，会有N个节点与CDN做邻居，其它节点均不能与CDN做邻居；

(2) 放大层的初始建立机制

在开始阶段，CDN节点开放N个直连通道，但没有节点与其连接，之后随着Peer节点的陆续加入，CDN开放的N个直连通道会依据某种算法被使用；

所谓放大层的含义是，在放大层的节点的上传带宽必须大于支持播放的最小码流；设观看所需的最小码流大小为a，放大层中节点的最小上传带宽为b，则必须满足条件a<b，这样在它服务其他普通节点时才能起到放大传播的作用；

设StreamingRate是流媒体直播中正常观看所需要的码流大小，N为放大层中节点的个数，则服务器在放大层中所消耗的流量总和为：

U_direct=StreamingRate * N            （公式1）

设为放大层中节点i，i∈[1,N]，的上传带宽，则放大层节点在上传带宽充分利用的情况下提供的流量是：

$U_{\mathrm{magnification}}=\underset{i=1}{\overset{N}{\mathrm{\&Sigma;}}}{U}_{{\mathrm{peer}}_i}$     （公式2）

显然有U_{magnification}≥U_direct；

第二步:选择和确定进入放大层的节点

每个向CDN服务器请求紧急数据块即快要播放的数据块的消息中，同时附上节点本身的一些信息,这些信息如第一步所述；CDN通过定期统计分析这些信息，找到进入放大层的节点并对其予以帮助，来提高CDN分发效率和系统总体性能；

在系统中，节点向CDN请求紧急的数据块，做法是节点向CDN节点发送块请求包，请求包内包括该节点所要请求的块和该节点的邻居中能力比较强的邻居节点ID，这里，所谓能力比较强的节点指的是邻居节点中上传带宽处在前50%的节点，请求包格式如下：

节点ID 时间戳 请求块列表 筛选后的邻居列表

每隔一段时间，CDN节点对收集到的数据进行分析，统计每个请求节点的邻居列表中的节点出现次数，并从中找出出现次数最多的若干个节点作为中介放大层节点；

最终CDN边缘服务器选出k个节点作为中介放大节点，k的计算方法如下：

$k=\min (\frac{U_{\mathrm{CDN}}-U_{\mathrm{outgoing}\_\mathrm{rate}}}{\mathrm{STRM}\_\mathrm{RATE}*\mathrm{\&alpha;}}*\mathrm{\&beta;},\frac{{\mathrm{NUM}}_{\mathrm{online}\_\mathrm{nodes}}}{10})$     （公式3）

$\mathrm{\&beta;}=e^{(\frac{{\mathrm{NUM}}_{\mathrm{req}}}{{\mathrm{NUM}}_{\mathrm{online}\_\mathrm{nodes}}}-1)}$     （公式4）

在公式中，α是常数，分子是CDN服务器的剩余带宽乘以β，STRM_RATE*α是对CDN服务一个瓶颈节点每秒所需流量的期望值，是预估CDN剩下的流量最多能服务多少个中介放大节点；其中NUM_req是在该时间段内向CDN服务器发出请求的节点个数，NUM_{online_nodes}是该边缘CDN服务器所管的节点总数；

第三步:给放大层节点直接提供内容分发服务

当CDN服务器从统计信息中找出k个中介放大节点，同时向这些节点发送服务启动消息，这些中介放大节点在收到服务启动消息后，返回自己的BufferMap给CDN服务器，CDN服务器根据每个节点的BufferMap情况进行相应的服务；

CDN服务器服务中介放大节点采用推送的方式，推送区域是Peer节点缓存区中的整个普通区，选择该区域为服务对象的主要原因是为了降低冗余块的个数，即节点自身拉到的块与CDN服务器推来的块相互重叠；因此CDN服务器首先查看中介放大层节点的缓冲区，找出在该服务区域内的所有缺失块，并以一定码流大小将其推送至对等节点；

CDN服务器根据如下公式决定在多少时间内把所有数据全部推送给对等节点：

$T_{\mathrm{fast}}=\frac{{\mathrm{NUM}}_{\mathrm{lack}}}{\mathrm{STRM}\_\mathrm{RATE}/\mathrm{STRM}\_\mathrm{PACK}\_\mathrm{SIZE}}$     （公式5）

T_slow=T_fast×2    （公式4-8）

$T=T_{\mathrm{slow}}-(T_{\mathrm{slow}}-T_{\mathrm{fast}})\&times;\frac{{\mathrm{NUM}}_{\mathrm{req}\_\mathrm{nbr}}}{{\mathrm{NUM}}_{\max \_\mathrm{nbr}}}$     （公式6）

NUM_lack指的是该服务区内缺失块的个数，Tfast是把这些缺失块以播放码流的速度送出时所需要的时间，Tslow是把这些缺失块以播放码流速度的一半输出所需要的时间；NUM_{req_nbr}表示该节点有多少邻居向CDN服务器请求紧急块，NUM_{max_nbr}表示每个节点的最大邻居数，最终的时间T介于T_fast和T_slow两个值之间，相应的传输速度介于播放码流的一半和播放码流之间；

第四步: 判断对放大层节点的服务是否延续

当CDN节点服务了一个中介放大层节点一段时间T后，根据该节点的表现决定是否继续服务该节点，判断是否继续服务的公式如下：

$U_{\mathrm{average}}=\frac{{\&Integral;}_{t=\mathrm{start}\_\mathrm{service}}^{t=\mathrm{current}\_\mathrm{time}}{U}_{\mathrm{outgoing}\_\mathrm{rate}}\left(t\right)\mathrm{dt}}{T_{\mathrm{current}\_\mathrm{time}}-T_{\mathrm{start}\_\mathrm{service}}}>U_{\mathrm{outgoing}\_\mathrm{rate}}(\mathrm{start}\_\mathrm{service})$     （公式7）

其中U_{outgoing_rate}(t)表示时刻t时，节点的上传速度大小，

表示从CDN服务节点开始到现在，该节点上传的流量总数，U_average表示服务期间瓶颈节点的平均上传流量；U_{outgoing_rate}(start_service)表示被服务前中介放大节点的上传速度；满足以上不等式，CDN即可继续服务该对等节点；继续服务的缓冲区区间不变，CDN服务器会根据如下公式决定在多少时间内把所有数据全部推送给对等节点：

$T=T_{\mathrm{slow}}-(T_{\mathrm{slow}}-T_{\mathrm{fast}})\&times;\frac{{\mathrm{Upload}}_{\mathrm{peer}}-U_{\mathrm{current}}}{{\mathrm{Upload}}_{\mathrm{peer}}}$     （公式8）

T_fast和T_slow的意义与上节相同，Upload_peer表示中介放大节点的上传带宽；

第五步: 放大层节点的更换

放大层节点需要不断更新和替换，每隔一段时间，放大层直连节点对自己的邻居进行一次扫描，找出那些能力即上传带宽比自己强，且不是直连节点的邻居节点；找到以后，该直连接节点利用一定策略，把该节点置换到放大层，而自己重新变为普通节点从放大层退出；

每个节点定时触发一次该算法，只有放大层的节点才执行该算法流程；在找出的优质邻居节点符合交换条件的时候，首先判断该邻居节点的邻居数是否达到了上限，如果没有，只让该邻居与CDN节点建立连接，本节点与CDN断开连接，这样该邻居节点的邻居数增加一；否则，解除本节点与该邻居节点的邻居关系，用以腾出该邻居节点的可用邻居连接让给CDN服务器；

当一个放大层节点离开系统时，它选出自己最强的邻居节点来替换自己，以保证放大层节点的扩展性和稳定性；

第六步: 定时监控放大层节点

为了避免放大层的节点在找邻居时会与同样在放大层的节点建立邻居关系,我们需要定时监控放大层节点的算法，对于节点来说也是间隔一段时间执行一次，即首先判断自己是不是放大层节点，不是的话直接退出操作；否则，检查自己所有的邻居，如果发现没有一个邻居是放大层节点的话就退出，否则将解除自己与该节点的邻居关系，由于解除邻居关系后本节点的邻居节点个数减少，因此要重新执行邻居查找算法对自己的邻居数进行补充；

第七步: 动态调整放大层节点的数量

在一段时间内有大量节点陆陆续续的加入时，需要增加放大层中的节点数目来提高系统的服务质量；具体是通过利用CDN服务器在运行时收集到的信息来动态调整放大层中的节点数量，该动态调整算法如下：

其中，用node_num 表示放大层中允许的最大节点数量，urgent_outgoing表示CDN服务器用于服务peer节点紧急请求的平均上传流量，direct_outgoing表示服务放大层的平均上传流量，这两个平均上传流量定时统计一次；该算法的公式表示如下，

$\mathrm{node}\_\mathrm{num}=\left\{\begin{array}{ccc}\mathrm{node}\_\mathrm{num}*\mathrm{\&theta;},& \mathrm{if}& \frac{\mathrm{urgent}\_\mathrm{outgoing}}{\mathrm{direct}\_\mathrm{outgoing}}\&GreaterEqual;0.4\\ \frac{\mathrm{node}\_\mathrm{num}}{\mathrm{\&lambda;}},& \mathrm{if}& \frac{\mathrm{urgent}\_\mathrm{outgoing}}{\mathrm{direct}\_\mathrm{outgoing}}\&le;0.15\end{array}\right.$     （公式9）

其中θ是1.3，λ是1.2。

2.根据权利要求1所述的方法，其特征在于，第五步中，所述当一个放大层节点离开系统时，它选出自己最强的邻居节点来替换自己，以保证放大层节点的扩展性和稳定性，

具体算法流程如下：

（1）向自己的所有邻居发送断开连接请求；

（2）如果是非放大层节点，则转第（5）步，否则转到第（3）步；

（3）遍历自己的邻居列表，找出能力最强的节点，对该最强节点发出消息包，使其在邻居列表加入CDN边缘服务器的信息并把退出节点的信息从邻居列表中删除；

（4）向CDN服务器发出消息包，使其在邻居列表加入新节点的信息并把该退出节点的信息从邻居列表中删除；

（5）删除本机邻居列表中的所有信息并退出系统。

Images