广电CDN系统浅析.docx
《广电CDN系统浅析.docx》由会员分享，可在线阅读，更多相关《广电CDN系统浅析.docx（45页珍藏版）》请在冰豆网上搜索。
广电CDN系统浅析
广电CDN系统浅析
陈春林（@aspring168）
2016/8/30
目录
1CDN系统概述3
1.1CDN概念及其发展历程3
1.2CDN工作原理4
1.3CDN应用领域6
2广电CDN相关技术概述7
2.1流媒体传输协议7
2.1.1RTP/RTCP和RTSP协议7
2.1.2Rtmp协议11
2.1.3Http-Streaming协议17
2.1.4DVB协议18
2.1.5ISA流控协议20
2.2IPQAM设备的应用21
2.3相关规范24
3广电CDN系统应用25
3.1公网租用26
3.2私网自建26
4典型CDN系统分析27
4.1思华广电CDN系统简介27
4.1.1产品组成28
4.1.2主要流程34
4.2同洲CDN系统简介37
5开源软件搭建广电CDN系统39
广电CDN系统浅析
1CDN系统概述
1.1CDN概念及其发展历程
CDN的全称是ContentDeliveryNetwork，即内容分发网络。
CDN系统在实际物理IP网络基础上放置节点服务器构成一层智能虚拟网络，实时根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上，从而使用户可以就近取得所需内容，解决IP网络拥挤的状况，提高用户访问网站的响应速度。
CDN设计之初是为互联网Web应用系统服务的，它随着互联网的发展而逐步成长，其大致经过以下几个发展阶段：
1、萌芽阶段
1991-1998年，互联网处于萌芽阶段，网络接入方式主要是拨号上网方式，速度慢，用户少，那时候互联网发展的主要瓶颈是接入网速，对应用系统没有太大的压力要求。
但是随着技术的发展，网速日益加快，对于应用系统的压力日渐增加。
1995年，麻省理工学院教授，互联网发明者之一TimBerners-Lee博士预测随着技术的发展，用户上网速度的提升，将会产生网络拥堵问题，提出了CDN网络的设想，并和Leighton博士和其他几位顶尖研究人员开发一套突破性的运算法则，用于在网络服务器所组成的大型网络中只能组织路由和复制内容，并最终成立Akamai公司，1999年正式开始提供商业服务，并宣布世界上网络流量最大的互联网公司雅虎成为自己的合作客户。
2、第一次发展浪潮
1999-2001年是全球互联网发展的高潮期，这时候的互联网内容还是以文本和图片内容为主，所以以页面加速主要需求的CDN系统发展迅速，继Akamai以后，CDN公司如雨后春笋般的创立，典型的如LimeLightNetwork，Level3等独立的CDN服务供应商，向Digitalisland这样的IDC企业也纷纷加入到这一阵列，通过遍布全球的IDC网络构建CDN网络服务。
在国内也催生了蓝汛（Chinacache）、网宿等知名的CDN公司。
3、互联网泡沫冲击和第二次大发展
2001年第一次互联网泡沫破裂，大量.com公司倒闭，网站关闭，CDN的业务量锐减，对整个行业造成了很大的冲击。
2002年，xDSL宽带上网技术的发展，为流媒体服务提供了条件，2004年随着互联网行业的复苏，流媒体服务和Web2.0大行其道，大数据量的应用大量出现，比如网络游戏，下载服务，flash视频等等，CDN服务又开始变得热门，2006年以后步入了新的发展阶段，2010年后云计算概念的推广和普及更是为CDN行业的发展注入了新的发展动力。
1.2CDN工作原理
下面以Web网站加速为例，通过应用CDN前后的工作流程对比来简单介绍一下CDN的工作原理：
一个Web网站在应用CDN以前的工作流程大致是这样的：
1、用户在终端设备（计算机或者手机上）的浏览器上输入web站点的域名地址，浏览器将请求地址送到DNS服务器；
2、DNS服务器对域名地址进行解析，如果缓存中有这个域名的解析结果，就直接响应，否则就在整个DNS系统中寻找这个域名的解析结果，并返回给浏览器；
3、浏览器按照返回的IP地址，向Web服务器发起请求；
4、Web服务器将请求的页面内容发送给浏览器；
在应用CDN后的工作流程大致是这样的：
1、用户在终端设备（计算机或者手机上）的浏览器上输入web站点的域名地址，浏览器将请求地址送到DNS服务器；
2、DNS系统将最终的域名解析权交给CNAME指向的CDN专用的CDN服务器；
3、CDN的DNS服务器将全局负载均衡系统的地址返回给浏览器；
4、浏览器向CDN全局负载均衡系统发起页面内容请求；
5、全局负载均衡系统根据用户区域IP地址，以及用户请求的内容URL，选择一台用户所属区域的区域负载均衡设备，转交请求；
6、区域负载均衡系统根据按照预先设定的调度策略（根据用户IP地址，判断哪个服务器据用户最近，根据用户所请求的URL所携带的内容名称，判断哪个服务器上有用户所需内容，查询各个服务器的忙闲情况，选择合适的服务器提供服务）选择一台合适的缓存服务器提供服务，返回该服务器的IP地址；
6、区域负载均衡系统将所选择的缓存服务器的IP地址返回全局负载均衡系统；
7、全局负载均衡系统将缓存服务器的IP地址返回浏览器；
8、浏览器根据返回的IP地址向缓存服务器发起内容请求；
9、缓存服务器响应用户请求，将内容所需内容传送到用户终端，如果这台缓存服务器上没有用户所要的内容，那么这台服务器就要向它的上一级缓存服务器请求内容，直到追溯到网站的源服务器将内容拉到本地。
（除了拉的方式，源网站的内容也可以主动注入到缓存服务器，实现加速）
1.3CDN应用领域
CDN的主要作用在于提高所承载内容的访问速度，按照所承载内容类型的不同，可以将CDN应用领域分为以下几块：
1）网页加速：
主要以文字、图片、动画等形式的静态网页内容为主，适用于各类门户网站、新闻发布类网站、访问量较大的行业网站、政府机构网站和企业门户网站等，随着Web2.0的兴起和互联网应用的丰富，网页加速也逐渐从静态内容加速到动态内容加速扩展，支持股票行情、电子商务、在线游戏等网站的内容加速。
2）流媒体加速：
主要包括流媒体直播加速和点播加速，通过将流媒体内容推送到离用户最近的POP点，使得用户能够从网络边缘获取内容，从而提高食品传输质量，缩短访问时间，节省骨干网网络带宽，避免单一中心的服务器瓶颈问题。
3）文件传输加速：
通过使用CDN的分布式POP点提供下载服务，网站可以将大量文件下载的性能压力和带宽压力交给CDN来分担，提高用户的下载速度。
主要包括HTTP下载，FTP下载，P2P下载等多种下载方式。
4）应用协议加速：
不针对特定的内容类型进行加速，而是通过对TCP/IP等传输协议的优化，改善和加快用户在广域网上的内容传输速度，或者对一些特定协议，比如SSL协议进行加速，解决安全传输时的性能和相应速度问题。
主要包括SSL应用加速，网页压缩等。
2广电CDN相关技术概述
广电运营商应用CDN系统主要用于视频内容的下发，提供VOD视频点播（VideoonDemand），时移电视（Time-ShiftedTV）等交互电视（InteractiveTV，又称交互式电视）业务，以保证视频服务质量，为用户提供高质量视频收听服务。
所以通常所说的广电CDN系统一般是指用于交互电视业务的流媒体CDN服务系统。
对于广电运营商而言，除了直播以外，VOD视频点播（VideoonDemand）业务，时移电视（Time-ShiftedTV）等业务是其互动电视系统的核心业务之一，能提供可点播的具有高度个性化和互动性的精彩节目，带来全新的收看体验，让收看者真正成为电视的主人。
而CDN系统是整个互动电视系统中核心组成部分，所以广电企业对于CDN系统的重视程度可想而知。
流媒体相对于普通的网页而言，有很大的不同，首先需要占用更多的带宽，其次需要实时和稳定的网络传输，最后数据流突发性很强，需要很好的缓冲机制。
所以对于CDN系统的要求也相对高了很多。
因而无法直接使用http协议，需要采用专用的流媒体传输协议才能保证流媒体的服务质量，所以对于流媒体CDN系统的了解首先可以从流媒体传输协议开始。
2.1流媒体传输协议
目前主流的流媒体传输协议主要有以下几种：
RTP/RTCP和RTSP协议
RTP/RTCP和RTSP都是IEEE发布的标准，简单说明如下：
（一）RTP/RTCP协议
RTP/RTCP主要是流媒体的打包封装协议，可以打包MPEG2的音视频内容，也可以打包H.264的音视频内容，RTP（实时传输协议）用来提供时间信息和实现流同步，RTCP（实时传输控制协议）协助RTP完成传输质量控制。
当应用程序建立一个RTP/RTCP会话时，应用程序将确定一对目的传输地址。
目的传输地址由一个网络地址和一对端口组成，有两个端口：
一个给RTP包，一个给RTCP包，使得RTP/RTCP数据能够正确发送。
RTP数据发向偶数的UDP端口，而对应的控制信号RTCP数据发向相邻的奇数UDP端口（偶数的UDP端口＋1），这样就构成一个UDP端口对。
RTP的发送过程如下，接收过程则相反。
⏹RTP协议从上层接收流媒体信息码流（如H.264），封装成RTP数据包；RTCP从上层接收控制信息，封装成RTCP控制包。
⏹RTP将RTP数据包发往UDP端口对中偶数端口；RTCP将RTCP控制包发往UDP端口对中的接收端口。
（二）RTSP（实时流传输协议）
RTSP是一个应用层协议（TCP/IP网络体系中）,用于实现远程播放控制。
它以C/S模式工作，它是一个多媒体播放控制协议，主要用来使用户在播放流媒体时可以像操作本地的影碟机一样进行控制，即可以对流媒体进行暂停/继续、后退和前进等控制。
RTSP协议通常和RTP/RTCP协议一起为用户提供流媒体服务。
和HTTP协议类似，RTMP协议也是个文本协议，采用文本报文方式进行交互，RTSP有两类报文：
请求报文和响应报文。
请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的回答。
由于RTSP是面向正文的（text-oriented），因此在报文中的每一个字段都是一些ASCII码串，因而每个字段的长度都是不确定的。
RTSP报文由三部分组成，即开始行、首部行和实体主体。
在请求报文中，开始行就是请求行，RTSP请求报文的结构如图所示：
RTSP请求报文的结构
其中RTSP请求报文的常用方法如下表所示：
编号
方法名
作用
1
OPTIONS
获得服务器提供的可用方法
2
DESCRIBE
得到会话描述信息
3
SETUP
客户端提醒服务器建立会话，并确定传输模式
4
TEARDOWN
客户端发起关闭请求
5
PLAY
客户端发送播放请求
6
PAUSE
暂停
GET_PARAMETER、SET_PARAMETER
参数获取和设置
响应报文的开始行是状态行，RTSP响应报文的结构如图所示：
RTSP响应报文的结构
典型的RTSP报文交互过程如下图所示：
Rtmp协议
RTMP（RealTimeMessagingProtocol）实时消息传送协议是AdobeSystems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。
和RTP/RTCP/RTSP不同，该协议首先是adobe公司的协议（虽然该协议也已经在2009年对外开放），其次是这个协议将流同步、播放控制、质量控制等内容都集成在了一起。
它有多种变种：
1）RTMP工作在TCP之上，默认使用端口1935；
2）RTMPE在RTMP的基础上增加了加密功能；
3）RTMPT封装在HTTP请求之上，可穿透防火墙；
4）RTMPS类似RTMPT，增加了TLS/SSL的安全功能；
RTMP协议中基本的数据单元称为消息（Message）。
当RTMP协议在互联网中传输数据的时候，消息会被拆分成更小的单元，称为消息块（Chunk）。
（一）消息
消息是RTMP协议中基本的数据单元。
不同种类的消息包含不同的MessageTypeID，代表不同的功能。
RTMP协议中一共规定了十多种消息类型，分别发挥着不同的作用。
例如，MessageTypeID在1-7的消息用于协议控制，这些消息一般是RTMP协议自身管理要使用的消息，用户一般情况下无需操作其中的数据。
MessageTypeID为8，9的消息分别用于传输音频和视频数据。
MessageTypeID为15-20的消息用于发送AMF编码的命令，负责用户与服务器之间的交互，比如播放，暂停等等。
消息首部（MessageHeader）有四部分组成：
标志消息类型的MessageTypeID，标志消息长度的PayloadLength，标识时间戳的Timestamp，标识消息所属媒体流的StreamID。
消息的报文结构如下图所示。
根据MessageTypeID的不同，可以将消息分为协议控制消息、命令消息、视频消息、音频消息、用户数据消息、共享对象消息，其中比较重要的是协议控制消息和命令消息，下面作重点介绍
协议控制消息
协议控制消息主要包含了用于消息传输和RTMP协议本身的消息，类型1和类型2用于消息块传输控制相关功能，类型3到6用于RTMP本身的控制功能，类型7用于边缘服务器和源服务器的控制通信。
事件
描述
StreamBegin（=0）
服务器发送这个事件来通知客户端一个流已就绪并可以用来通信。
默认情况下，这一事件在成功接收到客户端的应用连接命令之后以ID0发送。
这一事件数据为4字节，代表了已就绪流的流ID。
StreamEOF（=1）
服务器端发送这一事件来通知客户端请求的流的回放数据已经结束。
在发送额外的命令之前不再发送任何数据。
客户端将丢弃接收到的这个流的消息。
这一事件数据为4字节，代表了回放已结束的流的流ID。
StreamDry（=2）
服务器端发送这一事件来通知客户端当前流中已没有数据。
当服务器端在一段时间内没有检测到任何消息，它可以通知相关客户端当前流已经没数据了。
这一事件数据为4字节，代表了已没数据的流的流ID。
SetBufferLength（=3）
客户端发送这一事件来通知服务器端用于缓存流中任何数据的缓存大小（以毫秒为单位）。
这一事件在服务器端开始处理流之前就发送。
这一事件数据的前4个字节代表了流ID后4个字节代表了以毫秒为单位的缓存的长度。
StreamIsRecorded（=4）
服务器端发送这一事件来通知客户端当前流是一个录制流。
这一事件数据为4字节，代表了录制流的流ID。
PingRequest（=6）
服务器端发送这一事件用于测试是否能够送达客户端。
时间数据是为一个4字节的timestamp，代表了服务器端发送这一命令时的服务器本地时间。
客户端在接收到这一消息后会立即发送PingResponse回复。
PingResponse（=7）
客户端作为对ping请求的回复发送这一事件到服务器端。
这一事件数据是为一个4字节的timestamp，就是接收自PingRequest那个。
命令消息
RTMP服务器和客户端通过命令消息传递双方的命令消息，这些命令消息均采用AMF编码。
AMF编码方式是Adobe公司开发的一种通信协议，它采用二进制形式，为基于Flash的播放器和远程服务器提供一种轻量级的、高效能的通信方式。
目前AMF已经从AMF0版本发展到了AMF3.0版本。
通过命令消息，用户可以执行连接、创建流、发布、播放、暂停等操作，接收方也可以通过命令消息向发送方返回请求命令的状态。
（二）消息块
在网络上传输数据时，消息需要被拆分成较小的数据块，才适合在相应的网络环境上传输。
RTMP协议中规定，消息在网络上传输时被拆分成消息块（Chunk）。
消息块首部（ChunkHeader）有三部分组成：
用于标识本块的ChunkBasicHeader，用于标识本块负载所属消息的ChunkMessageHeader，以及当时间戳溢出时才出现的ExtendedTimestamp。
消息块的报文结构如下图所示。
（三）消息分块
在消息被分割成几个消息块的过程中，消息负载部分（MessageBody）被分割成大小固定的数据块（默认是128字节，最后一个数据块可以小于该固定长度），并在其首部加上消息块首部（ChunkHeader），就组成了相应的消息块。
消息分块过程如下图所示，一个大小为307字节的消息被分割成128字节的消息块（除了最后一个）。
RTMP传输媒体数据的过程中，发送端首先把媒体数据封装成消息，然后把消息分割成消息块，最后将分割后的消息块通过TCP协议发送出去。
接收端在通过TCP协议收到数据后，首先把消息块重新组合成消息，然后通过对消息进行解封装处理就可以恢复出媒体数据。
（三）协议交互流程
RTMP交互流程实例：
Connect
RTMP交互流程实例：
Play
Http-Streaming协议
使用传统的HTTP协议进行在线播放叫做“渐进下载”（ProgressiveDownload），所有的视频内容从头到尾必须从服务器传输到客户端，用户只能在传输完的视频长度中选择播放点，而不能自定义播放点及传输点，比如我们在看视频的时候是边下边看，没下载完则看不了，而且也不能绕到视频后面的片段。
当视频观看完毕之后，在浏览器的缓存中会存在一个视频文件。
而使用RTMP协议进行传输的数据包叫做“流”（如FlashMediaServer）,它能够让视频内容分割成多个数据包并源源不断从服务器端传输到客户端，客户端可以在视频内容任意一个点开始请求传输，而不用关心该点之前的内容是否已经传输。
这样我们看视频的时候可以在任意一个地方开始观看，点到哪里就从哪里开始下载，观看完毕之后在客户端不会有缓存文件。
两种协议各有各的优缺点，比如http协议在第二次观看视频的时候会直接使用缓存文件进行播放，速度也比较快，而RTMP协议必须保持源源不断送出“流”，同时本地也无缓存。
而HTTPStreaming则是对两种协议的优点进行了一个组合，达到了两个协议取长补短的服务平台。
其通过对来自RTMP端的“流”进行包装处理，转化成HTTP“流”提供给客户端解析，用户再也不用下载整个文件，同时又能使用HTTP协议进行快速观看视频。
HttpSteaming具有如下优势：
1）支持点播和直播，ProgressiveDownload只支持点播；
2）可以对分片文件进行加密，保证数字版权，ProgressiveDownload直接缓存媒体文件，无法保证版权；
3）支持播放过程中根据网络带宽变化进行码率切换，ProgressiveDownload只能以固定码率进行播放，不支持码率切换。
4）基于TCP协议传输，相对于RTSP/RTP具有可靠性更高，同时也可以利用TCP的流控机制来适应带宽的变化；
5）可以利用80端口来传输流媒体，在穿越防火墙上有优势;
6）采用标准http协议实现，只需要标准的HTTP服务器即可支撑，便于广泛推广。
目前HTTPStreaming几个主流阵营包括：
3GPPAdaptiveHTTPStreaming、MicrosoftIISSmoothStreaming、AdobeHTTPDynamicStreaming以及AppleHTTPLiveStreaming.这里就不展开描述了。
DVB协议
在广电行业，在互动电视业务流行以前，更多的是电视频道直播业务，所采用的是DVB（DigitalVideoBroadcasting，数字视频广播）系统的协议，1993年，欧洲成立了国际数字视频广播组织（DVB组织）。
DVB组织决定新的技术必须是建立在MPEG-2压缩算法上的数字技术，必须是以市场为导向的数字技术。
DVB的宗旨是要设计一个通用的数字电视系统，在此系统内的各种传输方式之间的转换有最简单的方式，尽可能的增加通用性。
DVB标准提供了一套完整的、适用于不同媒介的数字电视系统规范。
DVB数字广播传输系统利用了包括卫星、有线、地面、SMATV、MNDSD在内的所有通用电视广播传输媒体。
它们分别对应的DVB标准：
DVB-S、DVB-C、DVB-T、DVB-SMATV、DVB-MS和DVB-MC，其中在广大电影公司、电视台、广电企业（有线电视网络公司）中普遍采用的DVB-C标准。
在数字电视中，所有视频、音频、文字、图片等经数字化处理后都变成了数据，并按照MPEG-2的标准打包，形成固定长度（188个字节）的传送包，然后将这些数据包进行复用，形成传送码流（TS）。
通常由多个节目及业务复用组成的一个TS（TransportStream传输流）流对应一个8MHz带宽的频道。
TS流的过程生成过程大致如下：
1）将内容生成ES流（ElementaryStream，基本流）：
数字电视各组成部分编码后所形成的直接表示基本元素内容的流，包含视频、音频或数据的连续码流。
2）ES流打包生成PES流（PaketizedElementaryStream，打包基本码流）:
是将基本的码流ES流根据需要分成长度不等的数据包，并加上包头就形成了打包的基本码流PES流。
3）PES流打包为TS流（TransportStream，传输流）：
是将一个节目的多个组成部分按照它们之间的互相关系进行组织并加入各组成部分关系描述和节目组成信息,并进一步封装成传输包后的码流。
TS流是将视频、音频、PSI等数据打包成传输包进行传送。
主要用于节目传输。
TS的传输包长度固定，一般为188字节。
TS流格式简图：
传输流TransportStream（通常称为一路码流），是最基本的传输单元，实现数据以码流的方式输出。
码流中最基本的单位是188字节的包（Packet），前4BYTE是包头，后184为负载。
ISA流控协议
交互服务架构ISA（InteractiveServicesArchitecture）是美国有线运营商时代华纳从1997年为以VOD为代表交互式服务提出的网络框架结构。
通过几年多业务平台的试运营，时代华纳意识软件是网络和后台管理灵活性的关键。
所以通过定义一系列开放的软件接口标准，使多个软硬件的供应商可以基于统一的接口标准开发产品，大大减小了业务推出的时间。
ISA的成功应用更进一步证实了开放接口和TCP/IP服务器/用户端技术的强大产业化力量。
如下图所示为ISA规范的总体架构：
ISA的总体架构如图2所示，包括了业务管理系统（BMS，Business Management System）、视频服务器（Video Server）、应用服务器（Application Server）、机顶盒（STB，Set Top Box）、数字网络控制系统（DNCS，Digital Network Control System）和计费系统（Billing System）等实体。
为了约束实体内部和各实体之间的互操作，ISA定义了Content、Stream、Service、Package、Asset、Provider、Product等一系列组件以及各个组件和实体的隶属关系。
各组件之间通过CORBA的IIOP进行通信，ISA定义了各组件之间的接口描述文件。
各实体的开发人员根据接口描述文件进行相关实体开发，通过接口与其他实体进行通信。
在ISA的规范中，流控
升级会员 