CN102510395A

CN102510395A - 一种基于P2SP的flash视频调度方法

Info

Publication number: CN102510395A
Application number: CN2011103215641A
Authority: CN
Inventors: 白鹏; 姚健; 邱丹; 吴昊宇; 潘柏宇; 卢述奇
Original assignee: 1Verge Internet Technology Beijing Co Ltd
Current assignee: Alibaba China Co Ltd; Youku Network Technology Beijing Co Ltd
Priority date: 2011-10-21
Filing date: 2011-10-21
Publication date: 2012-06-20
Anticipated expiration: 2031-10-21
Also published as: CN102510395B

Abstract

本发明涉及一种基于P2SP的flash视频调度方法，发起播放请求的客户端Peer通过向P2P服务器P2P Server发送视频ID请求播放与该视频ID对应的视频，由P2P Server进行调度，决定由哪些资源向发起播放请求的Peer传送视频分片文件；发起播放请求的Peer将当前播放视频的统计信息发送给P2P Server；P2P Server进行调度基于通信健康度H，每次调度选出一组通信健康度H的值为正值的资源，提供给发起播放请求的客户端Peer，如果找不到任何满足条件的资源，则直接选择CDN作为资源。本发明所述的基于P2SP的flash视频调度方法，减少CDN的带宽消耗，降低成本，对各个客户端Peer较为公平，不会在客户端关闭播放行为后依然占用客户端Peer宝贵的网络带宽。

Description

一种基于P2SP的flash视频调度方法

技术领域

本发明涉及flash视频播放技术领域，具体说是一种基于P2SP的flash视频调度方法。即：在P2SP架构下的flash视频调度方法，所述P2SP(Peer to Server&Peer)是指用户对服务器&用户。peer是p2p技术中指代客户端的习惯用语，peer等同于client，其中文含义可以理解为客户端。

背景技术

利用Macromedia公司开发的动画编辑工具flash制成的flash视频，因为其视频文件尺寸小、显示效果好而广受视频网站的青睐，但是现有的基于P2SP(在P2SP架构下)的视频网站提供的flash视频播放依然存在以下的缺点：

1、对flash视频的播放流畅程度依赖于较大的客户端磁盘缓存空间：现有的基于P2SP的flash视频播放技术依赖于较大的客户端磁盘缓存空间，如pplive、ppstream等网络视频软件。

例如：某用户在A客户端用pplive看一个长500M的电影(flash视频)，pplive会把这个电影拆分(分段)成若干个flash视频文件(视频分片文件)，依次分别传输并存储在A客户端的磁盘上，分段存储的这些flash视频文件所占用的磁盘空间就是所说的客户端磁盘缓存空间；对A客户端的磁盘空间的占用大都是悄悄进行的，用户不一定知道，有时占用的客户端磁盘缓存空间高达几个G；

2、用户即使对已经看过的flash视频不感兴趣了，仍然会占用该用户所在的客户端的网络带宽，不公平：即使用户没有打开软件观看flash视频，软件在后台依然以磁盘缓存空间中存储的flash视频文件(视频分片文件)为依托，悄悄的将其上传给其他客户端，挤占用户所在的客户端的系统资源(网络带宽、CPU等)。

例如：某用户在B客户端用pplive看一个长700M的电影，pplive会把这个电影拆分(分段)成若干个flash视频文件，依次分别传输并存储在B客户端的磁盘上；当用户看完电影关掉pplive后，B客户端的客户端磁盘缓存空间中的flash视频文件并不被删除。如果另一个用户在A客户端同样看这个长700M的电影，则pplive会利用B客户端的客户端磁盘缓存空间中已经存下来的flash视频文件，调度B客户端给A客户端(或者更多的其他观看此电影的用户所在的客户端)传送相关内容，这个时侯就占用了B客户端的网络带宽；如果视频热门的话，用户在使用B客户端时这个对网络带宽的占用可能一直进行。

发明内容

针对现有技术中存在的缺陷，本发明的目的在于提供一种基于P2SP的flash视频调度方法，减少CDN(Content Delivery Network，内容分发网络)的带宽消耗，降低成本，对各个客户端Peer较为公平，不会在客户端关闭播放行为后依然占用客户端Peer宝贵的网络带宽。

为达到以上目的，本发明采取的技术方案是：

一种基于P2SP的flash视频调度方法，其特征在于：发起播放请求的客户端Peer通过向P2P服务器P2P Server发送视频ID请求播放与该视频ID对应的视频，

P2P Server负有协调调度的职能，由P2P Server进行调度找到哪些资源中有所需视频的视频分片文件，并决定实际由哪些资源向发起播放请求的Peer传送视频分片文件；

发起播放请求的客户端Peer根据从P2P Server收到的调度信息，从其他客户端peer获取所需视频的视频分片文件，或从CDN获取所需视频的视频分片文件，所述P2P Server向Peer发送的调度信息为JSON格式的字符串，至少包括：请求目标地址，视频ID，分片ID，分片总长度，所述请求目标地址为其他客户端Peer的地址或为CDN；

发起播放请求的客户端Peer在播放视频的同时，将当前播放视频的统计信息发送给P2P Server，P2P Server根据接收到的当前播放视频的统计信息形成并更新调度信息；所述Peer向P2P Server发送的统计信息为JSON格式的字符串，至少包括：Peer的ip地址，当前播放视频的ID，该视频的分片数组，当前分片的ID，当前分片总的字节数，当前分片已经下载的字节数；

P2P Server进行调度的具体过程如下：

P2P Server将统计信息抽象成一个Hash表Hash<key，value>，其关键字key为视频ID，取值value为能给该视频ID对应的视频提供下载服务的资源列表，所述资源列表就是一组资源的集合，

P2P Server进行调度基于通信健康度H，每次调度选出一组通信健康度H的值为正值的资源，提供给发起播放请求的客户端Peer，如果找不到任何满足H的值为正值这一条件的资源，则直接选择CDN作为资源，提供给发起播放请求的客户端Peer，

所述通信健康度H的计算公式为：

通信健康度H＝[播放完所用时间t1-下载完所用时间t2]/视频总时长T，

如果H＜0，则预期播放过程会阻塞。

在上述技术方案的基础上，所述资源列表中的资源包括：CDN网络本身和客户端列表peer_list；初始条件下，资源列表中的资源就是CDN网络本身。

在上述技术方案的基础上，Hash表的更新策略如下：

策略1、将value初始化为CDN：将value值初始化为CDN的边界服务器的域名；

策略2、如果某一客户端Peer通过向P2P Server发送视频ID请求播放某一视频，并获得响应，则将该客户端Peer加入到客户端列表peer_list中；

策略3、如果某一客户端Peer关闭播放行为，则将该客户端Peer移出客户端列表peer_list。

在上述技术方案的基础上，客户端Peer在存活期间会主动联系P2P Server，通告自己的存活状态，如果在规定时间内收不到客户端peer发来的状态信息，就视为客户端Peer关闭播放行为。

在上述技术方案的基础上，其特征在于：

播放完所用时间t1＝(total_b-play_b)/play_v；

下载完所用时间t2＝(total_b-loaded_b)/loading_v；

视频总时长T＝(total_b)/play_v；

公式中：play_v为播放速度，play_b为当前播放位置到开头的字节数，loaded_b为当前分片已下载的字节数，total_b为当前分片的总字节数，loading_v为当前分片的P2P下载速度。

在上述技术方案的基础上，在最开始调度的时候，由于没有历史的下载数据供分析，loading_v的计算按以下方式获取：

直接向请求地址发送一个TCP数据分节32byte，然后计算下RTT，

loading_v＝32*1000/RTT。

在上述技术方案的基础上，当发起播放请求的客户端Peer接收到调度信息以后，视为其获得响应，此时，发起播放请求的客户端Peer要在某一指定的时限之内发一个反馈信息给P2P server，如果超时仍未收到反馈，则认为该次通信失败，loading_v取值为大于0的极小值。

在上述技术方案的基础上，在大规模应用的情况下，满足H＞0的客户端peer会很多，将它们全部返回并不利于后续调度，引入一个通信能力标记cap(peer)来启发式的寻找最适合响应的资源集合，该标记策略如下：

对特定视频ID对应的视频，利用Hash表找出P2P Server中的客户端列表peer_list后，对其中的每一个资源进行如下操作：

a.如果发现H＞＝0，则该资源对应的cap(peer)++，然后对下一个peer进行H值测试；

b.如果发现H＜0，则该资源对应的cap(peer)--，然后对下一个peer进行H值测试；

直至客户端列表peer_list中的全部peer均测试完毕；

根据Cap(peer)，对peer_list进行降序排列；并返回前N个peer，N是可配置项。

在上述技术方案的基础上，在发起播放请求的客户端Peer收到P2P Server端返回的一组客户端列表peer_list以后，根据Cap(peer)进行升序排序，逐个选择客户端列表peer_list中的peer进行通信。

本发明所述的基于P2SP的flash视频调度方法，其优点在于：

1、由于使用通信健康度H来调度服务资源，仅在所有的客户端peer的通信健康度H均小于0的情况下，才会向CDN请求数据，因而自然会减少CDN的带宽消耗，降低带宽成本；

2、如果某个客户端Peer关闭播放行为(可能是该视频播放完毕，也可能是中途退出)，则将该客户端peer从客户端列表peer_list中移出，这样的话，就能保证不会在客户端关闭播放行为后依然占用客户端Peer宝贵的网络带宽，从而避免了饱受用户诟病的P2P(点对点模式)软件后台强行上载的不良特征。

附图说明

本发明有如下附图：

图1本发明的通信模型示意图。

具体实施方式

以下结合附图对本发明作进一步详细说明。

本申请中涉及HTTP协议标准请参见：

http://www.w3.org/Protocols/rfc2616/rfc2616.html

本申请中涉及TCP/IP协议标准请参见：

http://www.ietf.org/rfc/rfc793.txt

本发明的通信模型如图1所示，本发明所述的技术的核心要点在于依托P2SP双层网络通信结构提供的综合的视频内容调度策略。本系统的通信结构为两层，上层为P2P server的调度网络，下层为peer与peer，peer与CDN之间的内容分发。图中：

带箭头的实心黑线代表传送的flash视频内容(例如：视频分片文件)，其中：客户端peer之间能够互相传送flash视频内容，CDN能够向任意一个或任意多个客户端peer传送flash视频内容。

P2P服务器(P2P Server)和客户端peer之间的带箭头的黑色虚线代表客户端Peer向P2P服务器发送的当前播放视频的统计信息。

P2P服务器(P2P Server)和客户端peer之间的带箭头的黑色点划线代表P2P服务器向客户端Peer发送的调度信息。

本发明所述的基于P2SP的flash视频调度方法，其具体调度步骤如下：

第一，发起播放请求的客户端Peer通过向P2P服务器P2P Server发送视频ID请求播放与该视频ID对应的视频，视频ID(视频身份标识号码)用于唯一的标识某一个视频，

第二，客户端Peer通过向P2P Server发送视频ID请求播放某一视频，P2P Server负有协调调度的职能，当Peer发起播放某一视频的请求时，由P2P Server进行调度找到哪些资源中有所需视频的视频分片文件，并决定实际由哪些资源向发起播放请求的Peer传送视频分片文件；

发起播放请求的客户端Peer根据从P2P Server收到的调度信息，从其他客户端peer获取所需视频的视频分片文件，或从CDN获取所需视频的视频分片文件，

所述P2P Server向Peer发送的调度信息为JSON格式的字符串，至少包括：请求目标地址，视频ID，分片ID，分片总长度，所述请求目标地址为其他客户端Peer的地址或为CDN。分片即指视频分片文件，请求播放的视频通常分为若干视频分片文件后，再依次传输给客户端Peer。

P2P Server向Peer发送的调度信息为JSON格式的字符串，各字段及含义如下：

Target	请求目标地址(既可能是Peer，也可能是CDN)
		Vid	视频ID
Sid	分片ID
		totalBytes	分片总长度

第三，发起播放请求的客户端Peer在播放视频的同时，将当前播放视频的统计信息发送给P2P Server，P2P Server根据接收到的当前播放视频的统计信息形成并更新调度信息；

所述Peer向P2P Server发送的统计信息为JSON格式的字符串，至少包括：Peer的ip地址，当前播放视频的ID，该视频的分片数组，当前分片的ID，当前分片总的字节数，当前分片已经下载的字节数；

Peer向P2P Server发送的统计信息为JSON格式的字符串，各字段及含义如下：

IP	Peer的ip地址
		VideoID	当前播放视频的ID
Segs	该视频的分片数组
		Segs.sid	当前分片的ID
Segs.totalBytes	当前分片总的字节数
		Segs.loadedBytes	当前分片已经下载的字节数

P2P Server进行调度的具体过程如下：

P2P Server将所存储的统计信息抽象成一个Hash表Hash<key，value>，其关键字key为视频ID，取值value为能给该视频ID对应的视频提供下载服务的资源列表，所述资源列表就是一组资源的集合，Hash表是计算机技术中广泛应用的一种数据结构，能通过key值，快速找到对应的value值。

其中资源用如下结构表示：

struct Resource{

Address CDN；

Array<Address>peer_list；

}

资源列表就是一组资源的集合，可以用List<Resource>来表达资源列表。

初始条件下，资源列表中的资源就是CDN网络本身；

Hash表的更新策略如下：

策略1、将value初始化为CDN：将value值初始化为CDN的边界服务器的域名；例如，youku cdn边界服务器的域名为f.youku.com；

关闭播放行为的判断利用心跳机制：客户端Peer在存活期间会主动联系P2P Server，通告自己的存活状态，如果在规定时间内收不到客户端peer发来的状态信息，就视为客户端Peer关闭播放行为。

在P2P系统中，为了判定与节点的连接是否有效，服务器定时发送一个自定义的结构体(称为心跳包或心跳帧)，节点收到心跳包以后，向服务器返回自己的心跳包，从而确认该节点仍然存活。如果在一定时间内收不到节点返回的心跳包，则认为该连接失效了。心跳包的具体实现可以利用TCP/IP协议中的send，recv等方法。

P2P Server进行调度基于通信健康度H，每次调度选出一组通信健康度H的值为正值的资源，提供给发起播放请求的客户端Peer，如果找不到任何满足H的值为正值这一条件的资源，则直接选择CDN作为资源，提供给发起播放请求的客户端Peer，则：发起播放请求的客户端Peer直接选择CDN进行播放。P2P Server中存储着能针对与视频ID对应的视频提供服务的资源候选列表，每次调度以此为基础，选出上述满足H值要求的资源集合。

所述通信健康度H的计算公式为：

如果H＜0，则预期播放过程会阻塞；

具体计算办法如下：

[参数]

play_v播放速度(单位：byte/s)

play_b当前播放位置到开头的字节数(单位：byte)

loaded_b当前分片已下载的字节数(单位：byte)

total_b当前分片的总字节数(单位：byte)

loading_v当前分片的P2P下载速度(单位：byte/s)

这里的分片就是指：把请求播放的某一视频拆分(分段)成多少个flash视频文件，即：把一个大视频拆分(分段)为若干个小的flash视频文件，每一个flash视频文件即为一个分片。

例如50M的视频，被分成10个分片，每个分片5M。分片有利于稳定的传输。

[公式]

播放完所用时间t1＝(total_b-play_b)/play_v；

下载完所用时间t2＝(total_b-loaded_b)/loading_v；

视频总时长T＝(total_b)/play_v；

结合前述的通信健康度H计算公式，通过上述参数计算通信健康度H的算公式如下：

考虑在各个客户端的play_v基本相同，这里把play_v统一设为10000000(相当于10M/s)，那么最终的通信健康度指标计算公式如下：

其中，在最开始调度的时候，由于没有历史的下载数据供分析，loading_v可以利用类似ping的技术进行简单估算。例如：

可以直接向请求地址发送一个TCP数据分节32byte，然后计算下RTT(Round Trip Time，资料在网络上延迟的时间)，则：

loading_v＝32*1000/RTT，

公式中，loading_v的单位是byte/s，RTT的值一般为ms，所以要1000/rtt。

利用上述策略，我们可以选择一组资源对发起播放请求的客户端Peer传送数据。这样的话，就能在保障用户流畅观看的前提下，节省CDN的带宽资源。

当发起播放请求的客户端Peer接收到调度信息以后，视为其获得响应，此时，发起播放请求的客户端Peer要在某一指定的时限之内发一个反馈信息给P2P server，告诉P2P server当前通信已经完成，方便记录loading_v，loaded_b等值。这里需要设置一个超时策略，如果超时仍未收到反馈，则认为该次通信失败，loading_v为0，为方便前述通信健康度H的公式计算，可以将loading_v设为一个极小值，例如0.0000000001。

在大规模应用的情况下，满足H＞0的客户端peer会很多，将它们全部返回并不利于后续调度(客户端列表peer_list会很大，每次顺序查找就比较费时了)。这里引入一个通信能力标记cap(peer)来启发式的寻找最适合响应的资源集合。

该标记策略如下：

对特定视频ID对应的视频，利用Hash表找出P2P Server中的客户端列表peer_list后，对其中的每一个资源分别进行如下操作：

直至客户端列表peer_list中的全部peer均测试完毕；

根据Cap(peer)，对peer_list进行降序排列；并返回前N个peer，N是可配置项。例如：返回前10个peer、返回前20个peer。

在发起播放请求的客户端Peer收到P2P Server端返回的一组客户端列表peer_list以后，根据Cap(peer)进行升序排序，逐个选择客户端列表peer_list中的peer进行通信。根据Cap(peer)进行升序排序，有助于进行负载均衡，避免某些peer承担过多的内容分发的压力。

案例一：热门连续剧播放

热门连续剧往往有很多观众，他们都集中在同一时段观看该剧。以当前网上热门连续剧《水浒传》为例，每日20点左右，优酷会把最新剧集放在播放列表里，很多观众等着看。这样的话，就会在一个时段，有很多Peer同时播放同一个视频。这正是本发明发挥作用的时候。

在这个情境中，P2P server的资源hash表中的peer_list会存储大量的peer信息，这些peer下载的分片内容密集重叠。这样的话，只要少部分peer从CDN拿到数据，就能快速的向其他peer分发数据。

举例如下：

Peer数量：4

视频文件包含分片的数量：3

当前播放状态矩阵

其中seg代表分片，ci表示第i个Peer，本实施例中i的取值为1～4，

ci所在的列表示该Peer当前的播放状态，其中最后一行表示该Peer正在请求的分片，其余行表示已经下载的分片。以上述矩阵中的c1为例，它已经下载了分片1和分片2，当前正在请求分片3。再以c2为例，它已经下载了分片1，当前无正在请求的分片。

通信健康度矩阵

矩阵单元中的数值表示两个peer间的通信健康度，例如第一行中的首个-1表示H(c1，c2)＝-1，c1当前请求分片3，而c2中并没有分片3的内容，因而H(c1，c2)为负值，在这个示例中为-1，其余以此类推。例如：第一行中的第二个-1，表示H(c1，c3)＝-1，c1当前请求分片3，而c32中并没有分片3的内容，因而H(c1，c3)为负值。再例如：第二行中的第一个2，表示H(c2，c1)＝-1，c2中后续需要的两个分片，c1中都有，因此H(c2，c1)为正值。

通信能力标记矩阵

矩阵单元中的数值表示行Peer请求时，列Peer对应的通信能力标记值Cap(ci)。以第二行c2为例，在c2请求分片1时，c1中已经存储有分片1，并且通信健康度为2，因此Cap(c1)＝1；以第三行c3为例，在c3请求分片2时，c1已经存储分片2，并且通信健康度也为2，因此Cap(c1)加1，即Cap(c1)＝2，其余以此类推。

在获得上述两个矩阵的情况下，我们来描述调度结果：

c1：由于H(c1，c2)，H(c1，c3)，H(c1，c4)均为负值，因而c1将直接从CDN地址获取分片3；

c2：H(c2，c1)＝2，H(c2，c3)＝1，P2P server会把c1，c3地址返回给c2，c2再根据c1，c3的通信能力标记值排序，取其中1个，例如这里取c3，意味着c2将向c3请求分片1；

c3：H(c3，c1)＝2，P2P server会把c1地址返回给c3，c3将向c1请求分片2；

c4：H(c4，c1)＝2，H(c4，c3)＝3，并且在通信能力标记矩阵中，Cap(c1)＝3，Cap(c3)＝2，这时P2P server会把c1，c3地址返回给c4，c4根据Cap值进行升序排列，最终向c3请求分片1。

通过上述分析可见，本文描述的方法确实能有效调度视频内容，减少CDN消耗的带宽。

案例二：大型视频节目直播

大型视频节目直播比热门连续剧更有利于本发明的使用，其共同特征就是P2P server中构建了一个丰富的资源hash表，存有大量的分片内容重叠的peer。这种情况下，每次调度都能选出最优的peer，从而实现快速的文件分发。

本系统的调度策略中的通信能力指标表达了每个节点的总体传输能力，并通过对通信能力指标的两次排序过程实现了负载均衡策略，避免某些节点压力过大的情况。

总体传输能力：注意到Cap(peer)的值是累加的，并不是每次计算完都清零。这就是“总体传输能力”的意思。隐含的意思是一个节点往期的传输能力(历史传输能力)越强，现在的传输能力可能也不差。

负载均衡就是通过一次升序+一次降序，实现负载均衡，避免请求都指向Cap值最高的那些节点。

本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。

Claims

1.一种基于P2SP的flash视频调度方法，其特征在于：发起播放请求的客户端Peer通过向P2P服务器P2P Server发送视频ID请求播放与该视频ID对应的视频，

P2P Server进行调度的具体过程如下：

所述通信健康度H的计算公式为：

如果H＜0，则预期播放过程会阻塞。

2.如权利要求1所述的基于P2SP的flash视频调度方法，其特征在于，所述资源列表中的资源包括：CDN网络本身和客户端列表peer_list；初始条件下，资源列表中的资源就是CDN网络本身。

3.如权利要求2所述的基于P2SP的flash视频调度方法，其特征在于，Hash表的更新策略如下：

4.如权利要求3所述的基于P2SP的flash视频调度方法，其特征在于：客户端Peer在存活期间会主动联系P2P Server，通告自己的存活状态，如果在规定时间内收不到客户端peer发来的状态信息，就视为客户端Peer关闭播放行为。

5.如权利要求3所述的基于P2SP的flash视频调度方法，其特征在于：

播放完所用时间t1＝(total_b-play_b)/play_v；

下载完所用时间t2＝(total_b-loaded_b)/loading_v；

视频总时长T＝(total_b)/play_v；

6.如权利要求5所述的基于P2SP的flash视频调度方法，其特征在于：在最开始调度的时候，由于没有历史的下载数据供分析，loading_v的计算按以下方式获取：

直接向请求地址发送一个TCP数据分节32byte，然后计算下RTT，

loading_v＝32*1000/RTT。

7.如权利要求5所述的基于P2SP的flash视频调度方法，其特征在于：当发起播放请求的客户端Peer接收到调度信息以后，视为其获得响应，此时，发起播放请求的客户端Peer要在某一指定的时限之内发一个反馈信息给P2P server，如果超时仍未收到反馈，则认为该次通信失败，loading_v取值为大于0的极小值。

8.如权利要求3所述的基于P2SP的flash视频调度方法，其特征在于：在大规模应用的情况下，满足H＞0的客户端peer会很多，将它们全部返回并不利于后续调度，引入一个通信能力标记cap(peer)来启发式的寻找最适合响应的资源集合，该标记策略如下：

直至客户端列表peer_list中的全部peer均测试完毕；

9.如权利要求8所述的基于P2SP的flash视频调度方法，其特征在于：在发起播放请求的客户端Peer收到P2P Server端返回的一组客户端列表peer_list以后，根据Cap(peer)进行升序排序，逐个选择客户端列表peer_list中的peer进行通信。