QQ 直播 (QQLive) 介绍

Zhangqing 、 zbf2007/11

客户端介绍

Zhangqing2007/11

P2PStreaming 的发展和技术要点

主要特性和特点

软件结构

后续发展方向

P2PStreaming 发展过程

WebCast

萌芽期

（1998）

EMS

NICE->ZigZagOvercast

第一个里程碑

（2000）第二个里程碑

（2002）

CoolStreamingSplitStream

第三个里程碑

（2004）

P2P Live Streaming

关键技术点

网络的构建及维护 决定系统的可扩展性、可维护性、稳定性、以及系统运转的效率。

Buffer 管理根据具体的应用来选取合适的Buffer管理策略；例如直播与点播的Buffer管理策略不相同；

伙伴节点的选择决定系统运转的效率，伙伴节点过多，则造成系统维护开销过大；伙伴节点过少，则造成系统的稳定性差。伙伴节点的质量差则系统的服务质量难以满足Streaming 的需求；

数据传输的优化调度；决定流媒体数据传输的QoS。

QQLive 流媒体部分系统架构

与服务器B连接的Peer

与服务器A连接的Peer

SP

服务器群

服务器A

服务器B

SP1

SP2

源（发布者）

Proxy Server

...

...

...

图例

信息通道

数据通道

接入 Server

信息通道 Stun测试 Server

QQLive 主要特性和特点

基于 P2P(Peer To Peer) 的流媒体直播节省带宽 90% 以上稳定的提供流媒体直播…

和频道相关的聊天室节目导航

频道列表频道节目预告、实时截图、介绍等…

简单易用的 SDK个人信息播放控件最近观看一键点击播放

QQLive 客户端模块

广告 UI

Skin

QQLive API

Web Other Components

QQLive Player Control Chat

一些基础程序，网络通讯/HTTP下载等

认证/收费P2PStreaming

导航

P2P 流媒体播放部分

P2PSTREAMING LAYER(live.dll)P2P协议，P2P连接，P2P网络，P2P数据交换

P2PNETWOAK层略（其他开发组提供tntprox.dll)

LIVESTREAMING LAYER(livestream.dll)连接播放器和P2P 数据源

把播放任务传给P2P层处理

把P2P 数据以ＳＴＲＥＡＭ的方式提供给PLAYER播放

OCX LYAER(qqliveocx.dll)集成PLAYER，实现一个能播放STREAMING的ACTIVX控件

（两个版本：精简版本，复杂版本）

MULTIPANE(multipane.dll)提供一个多PANE功能的ACTIVEX，其中一个PANE是

PLAYER OCX的容器

QQLIVE应用程序(QQLIVE.EXE)

QQLIVEX(qqlivex.dll)

IE P2P播放 WEB PAGE

函数调用 消息回调

COM EVENT回调

P2P 数据交互概要

从 CLIENT 的视点来看，一个 QQLIVE CLIENT 和SERVER 交互两件事情：

登陆，注册网络状态信息；获取 SP ， PEER 信息，播放的文件信息

连接 SP 和其他 PEERS ，得到 STREAM DATA

然后就是 Client 通过 Server 筛选合适的种子与其交换数据

未来的 QQLive – 网络流媒体播放软件

同时支持点播和直播

支持不同的格式，对用户保持一致的体验

允许用户自发布

……

一些正在探索加强的技术点

带宽限制 / 调度；

减少延迟；

提高流畅度；

新的界面技术；

整合点播 ;

丰富的格式支持；

安全性和兼容性的增强；

……

服务端介绍

Zbf2007/11

介绍

现有 P2Pstreaming 方案

QQLive- 方案选择

QQLive- 基本架构

QQLive- 流程

QQLive- 模块介绍

P2P-Streaming- 主要方案1-树形

采用 server 中心控制，客户端上报自己的网络状况和带宽信息， server 实现成员管理，并生成最优的转发树 .server仅负责信令通讯 ,数据由各节点进行转发，并可扩展 .

优点：

1. 客户端逻辑实现比较简单，不需要考虑文件的分片，一个客户端仅对应一个源提供者 ,简单的收到数据然后转发 .

2. 结构稳定的时候，延时相对固定 , 数据波动性较小 .比较流畅

缺点：

1.没有考虑用户网络带宽的差异性

2. 用户的频繁上下线会导致转发树的不稳定，并对其他用户的收看效果影响较大

3. 就目前状况而言，实现工作量较大

4.当用户数量到万级的时候系统稳定性令人担忧

绿色为服务器 , 黄色为直播源 , 灰色为收看客户端

红线虚线为信令控制流 , 蓝色实现为数据流

箭头表示数据流的方向

P2P-Streaming- 主要方案2- 网格型

同样采用服务器控制，服务器负责成员管理、播放时间同步，分配给用户正在参与的其他用户信息。客户端与其他用户进行通讯和数据交换。与树形最大不同是客户端之间的数据交换没有严格的顺序，是无序的，数据源的选择和数据的交换依靠客户端的算法来实现。

优点：

1.充分考虑用户间网络的差异性 , 部分网络状况较差的用户不会影响其他用户 .

2. 服务器实现逻辑简单 .

3. 用户的频繁上下线只会影响很少部分的用户

4. 用户数量的多少对系统稳定性影响不大

缺点：

1. 客户端实现逻辑比较复杂，需要考虑播放时间的同步以及获得数据的算法

2. 需要对流数据进行分片处理

3. 播放的延时和流畅性依赖于算法 ,并且波动会较大

绿色为服务器 , 黄色为直播源 , 灰色为收看客户端

红线虚线为信令控制流 , 蓝色实现为数据流

箭头表示数据流的方向

QQLive- 方案选择

目前主要的 P2PStreaming都采用了网格型方案，原因主要有：

1.充分考虑用户间网络状况的差异性

2.考虑用户的频繁上下线

3.当在线用户数量上万级时候系统的稳定性

4.考虑服务器实现逻辑的简单化

5. 可以在目前已有的 p2p 下载的系统上进行改进，实现工作量较小

需要解决的问题：1. 数据源的选择和数据交换的策略

2. 直播媒体流的分片处理和分片传输

3. 播放器和编解码器

4. 文件播放的延时和抖动的控制

5. 版权保护

QQLIVE 基本架构

与服务器B连接的Peer

与服务器A连接的Peer

SP

服务器群

服务器A

服务器B

SP1

SP2

源（发布者）

Proxy Server

...

...

...

图例

信息通道

数据通道

QQLIVE 流程

用户PC2P2p

Streaming 服务器

节目发布

源

中央CDN服务器机

群

请求发布CCTV5的节目（带上节目的相关描述信息 ,）

经过认证，同意发布

登陆服务器 ,说明我是 cdn服务器

登陆成功

查询当前节目列表

返回当前节目列表

分别请求观看 cctv5或其他在直播节目

返回节目源信息 ,记录此服务器信息

心跳维持

连接节目源

仅超级种子可以连接 /成功

直播数据交互 ,心跳维持

查询其他正在观看的用户 （定时进行）

返回其他正在观看的用户信息

连接普通用户 1,并互相交互数据，维持心跳

用户PC1

连接普通用户 1,并互相交互数据 ，维持心跳

定时查询当前节目列表

返回当前节目列表

发现新的节目源 ,重复连接数据源过程

登陆服务器

认证通过 ,登陆成功

请求观看 cctv5节目 ,,服务器记录此用户相关信息

认证通过 ,返回源描述信息以及 cdn服务器资源

连接cdn服务器并交互数据 ，维持心跳

心跳维持

定时不断查询正在观看此节目的其他用户

随机返回正在收看的用户信息

连接用户2并交换数据 ,维

持心跳

QQLIVE 服务模块介绍

Peer 服务模块用户登陆 PServer ， PS 分配唯一的 UIN ，并将其加入到 UIN List当中

用户请求下载指定节目，实际就是要求观看该节目， PS为其分配 SessionID ，并将其加入 Session List ，返回观看节目的配置参数、当前 SP 信息和当前源的播放时间。

用户心跳时 Server返回源的最新播放时间。

用户查询种子，根据 SessinID在 Session List 中返回其他种子。

用户停止观看节目，收回 SessionID ，并从 Session List 中删除。

用户退出或者超时，收回 UIN ，并从 UIN List 中删除。

QQLIVE 服务模块介绍

SP 服务模块

登录 proxy 服务，从 proxy 服务上同步 SP 节目信息

发布源登录 SP ，发送流数据

用户登录 SP ，获取初始流数据

QQLIVE 服务模块介绍

Proxy 服务模块

PS 登录 proxy ，获取节目、 SP 等信息

SP 登录 proxy ，获取节目、发布源等信息

定时同 PS 、 SP 等服务同步节目时间点等信息

问题讨论

流量节约？

CDN 部署？

突发流量接入？

......

谢谢！