网易视频云流媒体服务器原理和架构解析Word文件下载.docx
《网易视频云流媒体服务器原理和架构解析Word文件下载.docx》由会员分享，可在线阅读，更多相关《网易视频云流媒体服务器原理和架构解析Word文件下载.docx（18页珍藏版）》请在冰豆网上搜索。
传输协议
专用协议RTSP，
HLS或RTMP等
一般的HTTP协议，
与传输网页的协议相同
跳播
可随机访问任意片段
在给定时刻，用户只能观看已下载的那部分，而不能跳到还未下载的部分
主流的流媒体协议
主流的流媒体协议主要有：
RTMP，
HLS，
RTSP等。
RTMP
HLS
RTSP
全称
RealTimeMessageProtocol
HttpLiveStream
RealTimeStreamingProtocol
上层协议
TCP或HTTP
HTTP
RTP，RTCP
软件模型
C\S
B\S
研发主要来自
Adobe
Apple
Microsoft
针对客户端
支持Flash类产品
的浏览器
支持HTML5的浏览器
苹果的Safari浏览器
播放器
视频格式要求
FLV，
F4V
MP4
无
服务器要求
专用Flash服务器
Red5
普通HTTP服务器
专用RTSP流媒体服务器
实况直播要求
专用编码器上传
FlashMediaEncoder
Apple开发工具
与服务器相关，
自定义上传
文件播放要求
FLV
，F4V文件即可，
服务器会自动分解为
F4f
数据文件
f4x索引文件
TS数据文件，
M3u8索引文件
与播放器相关
流媒体协议原理
（一）
HTTP渐进式下载原理（仅支持文件播放）
HTTP边下载边播放，严格意义上讲，不是直播协议。
他的原理是先下载文件的基本信息，音频视频的时间戳，再下载音视频数据，以播放mp4为例，先下载文件头，根据文件头指引下载文件尾，然后再下载文件的音视频数据。
播放方式：
浏览器调用系统播放器播放；
使HTML5的Video标签，浏览器支持直接播放。
（二）
苹果支持的HLS原理（实况直播、文件点播）
服务器端有三个组件：
其一：
编码器（mediaencoder）,
用于将设备输出的格式转为H264和AAC，并封装为MPEG-2传输流；
其二：
流分段器（streamsegmenter）,
用于实况直播，将MPEG-2流分割为多个小片段后输出；
其三：
文件分段器（filesegmenter）,
用于文件点播，将文件分隔为多个小片段后输出；
分发原理
数据经以上三部分处理后为.ts文件（媒体数据）及.m3u8文件（媒体数据索引）存在于服务器之上。
客户端访问.m3u8后按索引下载.ts文件进行播放。
下面为某m3u8文件内容：
#EXTM3U
#EXT-X-TARGETDURATION:
30
#EXTINF:
30,
http:
//192.169.1.176/sample_100k-1.ts
//192.169.1.176/sample_100k-2.ts
//192.169.1.176/sample_100k-3.ts
#EXT-X-ENDLIST
根据这个文件，播放器会依次下载sample_100k-1.ts，sample_100k-2.ts，sample_100k-3.ts
HLS的文件点播
1.
使用苹果开发工具“文件分段器”将基于H264和AAC或MP3的MPEG4分段，
生成.ts和.m3u8文件，存储于普通服务器上。
2.
苹果应用程序或苹果浏览器可以通过访问.m3u8文件获取到索引，并下载所需要的数据片段来播放。
HLS的实况直播
使用苹果开发工具“流分段器”将基于H264、AAC、MP3的MPEG2传输流分段，
可使用其它工具将MPEG4音视频文件加载到MPEG2传输流当中。
（三）
AdobeFlash
支持的RTMP协议（支持文件播放和实况直播）
RTMP（RealTimeMessagingProtocol）
是AdobeSystems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。
它有四种变种：
1）
工作在TCP之上的明文协议，使用端口1935；
2）
RTMPS通过TLS/SSL连接；
3）
RTMPT封装在HTTP请求之中，可穿越防火墙；
4）
RTMPS类似RTMPT，但使用的是HTTPS连接；
RTMP协议（RealTimeMessagingProtocol）是被Flash用于对象,视频,音频的传输。
这个协议建立在TCP协议或者轮询HTTP协议之上。
RTMP协议就像一个用来装数据包的容器,这些数据既可以是AMF格式的数据,也可以是FLV中的视/音频数据。
一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的。
必须采用Flash服务器FMS（FlashMediaServer）
或
RED5.
FMS的文件点播
服务器将F4v
Flv文件转化为RTMP流或HTTP流
客户端获取RTMP流，提取相应的Flv
F4v文件片段进行播放。
FMS的实况直播
设备端将数据转化为F4v片段，通过RTMP流上传到服务器
服务器转发RTMP流到客户端
3.
客户端获取RTMP流，提取数据片段播放。
（四）
RTSP协议
该协议用于C/S模型，是一个基于文本的协议，用于在客户端和服务器端建立和协商实时流会话。
实时流协议（RTSP）是应用级协议，控制实时数据的发送。
RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。
数据源包括现场数据与存储在剪辑中数据。
该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。
实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。
尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。
换言之，RTSP充当多媒体服务器的网络远程控制。
RTSP连接没有绑定到传输层连接，如TCP。
在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。
此外，可使用无连接传输协议，如UDP。
RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。
协议支持的操作如下：
（1）从媒体服务器上检索媒体：
用户可通过HTTP或其它方法提交一个演示描述。
如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。
如演示仅通过单播发送给用户，用户为了安全应提供目的地址。
（2）媒体服务器邀请进入会议：
媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。
这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
（3）将媒体加到现成讲座中：
如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。
如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。
下面区分几种操作模式。
（1）单播：
用户选择的端口号将媒体发送到RTSP请求源。
（2）服务器选择地址多播：
媒体服务器选择多播地址和端口，这是现场直播或准点播常用的方式。
（3）用户选择地址多播：
如服务器加入正在进行的多播会议，多播地址、端口和密钥由会议描述给出。
RTSP控制通过单独协议发送的数据流，与控制通道无关。
例如，RTSP控制可通过TCP连接，而数据流通过UDP。
因此，即使媒体服务器没有收到请求，数据也会继续发送。
在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。
所以，服务器需要维持能联系流与RTSP请求的连接状态。
RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：
（1）SETUP：
让服务器给流分配资源，启动RTSP连接。
（2）PLAY与RECORD：
启动SETUP分配流的数据传输。
（3）PAUSE：
临时停止流，而不释放服务器资源。
（4）TEARDOWN：
释放流的资源，RTSP连接停止。
标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连接产生连接标识。
RTSP为纯粹的传输控制协议。
RTSP协议本身不与它负载的媒体数据相关。
RTSP协议需要自定义客户端向服务器发送RTSP命令。
流媒体服务器的协议栈
在TCP／IP参考模型中，传输层通信协议TCP和UDP都不能满足流媒体传输的QoS要求。
由于TCP协议采用滑动窗口控制机制，数据传送随着流控窗口动态的启动和关闭，难以满足流媒体实时和等时的传送要求。
UDP协议的无连接特点能够提高传输速率，虽然可以在某种程度上满足流媒体的实时性要求，但是由于其本身的不可靠性，也无法满足流媒体传输的需要。
针对传输层协议的矛盾，为了实现流媒体在IP上的实时传送播放，设计流媒体服务器时需要在传输层协议（TCP／UDP）和应用层之间增加一个通信控制层。
在增加的通信控制层，采用相应的实时传输协议，主要有：
数据流部分的实时传输协议RTP（Real－timeTransportProtocol），用于控制部分的实时传输控制协议RTCP（Real－timeControlProtocol）和实时流化协议RTSP（Real－timeStreamingProtocol）。
流媒体服务器的协议栈，如图1所示。
RTP协议主要是用来传送实时的流媒体信息，数据报主要包括多媒体数据，以及所携带负载的时间戳，顺序号等。
RTCP协议的数据报主要包括了接收者收到某个多媒体流的服务质量信息Qos，用于对服务器端的反馈。
RTSP是一种控制协议，包括通信连接前的设定，从服务器送出的多媒体资料的控制。
用于控制具有实时性的数据传输。
它提供对流媒体的类似VCR（VideoCassetteRecorder）的控制功能，如播放、暂停、快进、录制等，也就是RTSP对多媒体服务器实施网络远程控制。
流媒体服务器的功能框图，如图2所示。
当服务器收到RTSP请求，它首先产生RTSP请求对象。
服务器通过RTSP协议的应答信息将请求的内容以流会话（streamingsession）的形式描述，内容包括数据流包含多少个流、媒体类型、和编解码格式。
一个流会话由一个或多个数据流组成，如视频流和音频流等。
实际的数据流通过RTP协议传递到客户端。
RTP在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。
RTP本身并不能为顺序传送数据包提供可靠的传送机制，它依靠RTCP一起提供流量控制和拥塞控制服务。
在RTP会话期间，各连接者监视下层网络的性能，并将相关信息放入RTCP包，周期性地传送RTCP包来通知发送方。
发送方也可以用RTCP包提供每次的会话信息，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。
因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。
RTP和RTCP配合使用，因有效的反馈和最小的开销使传输效率最佳化。
通过流媒体服务器的协议栈的设计，可以明确流媒体服务器是在传输层协议（TCP，UDP）上解释RTP，RTCP，RTSP协议的，所有的客户连接请求都是以TCP的端口获得的，流媒体数据也都是打成RTP包，通过UDP端口发出去的，因此，对于TCP，UDP端口事件的调度以及如何把大量的流媒体数据从磁盘空间传递到网络上成为制约流媒体服务器性能的主要因素。
传统流媒体服务器的处理流程，如图3所示。
流媒体服务器面对一个单一的客户，完成的过程如下：
1）在客户端发出RTSP连接请求后，服务器通过对TCP端口的监听，读入请求。
2）解析请求内容，调入相应的流媒体文件。
3）形成RTP包，分发数据流包，获得RTCP包。
4）数据包发送完毕，关闭连接。
上图是RTSP直播服务器的系统框图。
从摄像头采集实时图像，送到编码器进行实时编码，一般是生成TS格式的数据流，然后数据流输出到视频直播服务器。
客户端先发送请求到web服务器，然后再重定向到RTSP视频服务器，从视频服务器读取数据，同时实现播放，暂停等功能。
流媒体的传输技术
一、单播：
主机之间“一对一”的通讯模式，网络中的交换机和路由器对数据只进行转发不进行复制。
如果10个客户机需要相同的数据，则服务器需要逐一传送，重复10次相同的工作。
但由于其能够针对每个客户的及时响应，所以现在的网页浏览全部都是采用IP单播协议。
网络中的路由器和交换机根据其目标地址选择传输路径，将IP单播数据传送到其指定的目的地。
单播的优点：
服务器及时响应客户机的请求
服务器针对每个客户不通的请求发送不通的数据，容易实现个性化服务。
单播的缺点：
服务器针对每个客户机发送数据流，服务器流量＝客户机数量×
客户机流量；
在客户数量大、每个客户机流量大的流媒体应用中服务器不堪重负。
二、广播：
主机之间“一对所有”的通讯模式，网络对其中每一台主机发出的信号都进行无条件复制并转发，所有主机都可以接收到所有信息（不管你是否需要），由于其不用路径选择，所以其网络成本可以很低廉。
在数据网络中也允许广播的存在，但其被限制在二层交换机的局域网范围内，禁止广播数据穿过路由器，防止广播数据影响大面积的主机。
广播的优点：
网络设备简单，维护简单，布网成本低廉
由于服务器不用向每个客户机单独发送数据，所以服务器流量负载极低。
广播的缺点：
1.无法针对每个客户的要求和时间及时提供个性化服务。
网络允许服务器提供数据的带宽有限，客户端的最大带宽＝服务总带宽。
广播禁止在Internet宽带网上传输。
三、组播：
主机之间“一对一组”的通讯模式，也就是加入了同一个组的主机可以接受到此组内的所有数据，网络中的交换机和路由器只向有需求者复制并转发其所需数据。
主机可以向路由器请求加入或退出某个组，网络中的路由器和交换机有选择的复制并传输数据，即只将组内数据传输给那些加入组的主机。
这样既能一次将数据传输给多个有需要（加入组）的主机，又能保证不影响其他不需要（未加入组）的主机的其他通讯。
组播的优点：
需要相同数据流的客户端加入相同的组共享一条数据流，节省了服务器的负载。
具备广播所具备的优点。
由于组播协议是根据接受者的需要对数据流进行复制转发，所以服务端的服务总带宽不受客户接入端带宽的限制。
此协议和单播协议一样允许在Internet宽带网上传输。
组播的缺点：
1．与单播协议相比没有纠错机制，发生丢包错包后难以弥补，但可以通过一定的容错机制和QOS加以弥补。
2．现行网络虽然都支持组播的传输，但在客户认证、QOS等方面还需要完善，这些缺点在理论上都有成熟的解决方案，只是需要逐步推广应用到现存网络当中。
自适性串流技术
自适性串流（ABS-adaptivebitratestreaming），是一种在电脑网络使用的一种串流技术。
过去的流媒体技术多使用
RTP/RTSP，但现在的技术则大多基于
HTTP，并为更高效在大型分布式HTTP网络（例如互联网）分发而设计。
此技术根据实时检测的用户的带宽和CPU使用率，调整视频流的质量。
这需要使用一种可以将单一视频源输出为多码率的编码器。
播放器客户端依赖可用资源在不同码率的流之间切换。
"
结果就是：
更少缓存、更快的开始播放、为低端和高端链接都提供良好的体验。
根据当前广泛使用的实现，更具体来说，自适应串流（ABS）：
使用
HTTP
传送视频流；
使用多码率编码源内容；
每个单码率的流被切成小的，几秒钟的小切片；
流媒体客户端首先获取所有码率的切片索引信息。
一开始，客户端先请求最低码率的串流。
如果客户端判断下载速度比当前码率的切片串流快，它就去请求下一个更高码率的串流。
随着播放的进行，如果客户端发现下载速度比当前码率的切片串流慢，转而请求下一个较低码率的串流。
切片大小和具体实现密切相关，不过一般都在2～10秒之间。
每个切片由一个完整的GOP序列组成，一个GOP序列里面有1个或者多个I帧，GOP序列的第一个帧必须是I帧，并且每个切片都能单独的解码播放显示。
与传统的流媒体技术比较，缺点：
需要额外的存储，更多的编码代价，复杂的只适应码率逻辑。
Adaptivestreamingoverview
Adaptivestreaminginaction
MPEG-DASH（DynamicAdaptiveStreamingoverHTTP）
MPEG-DASH
是基于HTTP的自适应串流方案中的唯一国际标准。
技术由
MPEG
主导开发：
2010年开始DASH相关工作，2011年1月成为国际标准草案，2011年11月成为国际标准[3]，2012年4月，MPEG-DASH
以ISO/IEC23009-1:
2012
发表。
基于3GPP第9版的
AdptiveHTTPstreaming（AHS）和
OpenIPTVForum第2版的
HTTPAdaptiveStreaming（HAS）。
作为与MPEG合作的一部分，3GPP第10版采用了DASH（采用特别的编码和操作模式），用于无线网络。
可用的
实现有：
bitmovinGmbH
的开源
DASH
客户端库
libdash
和
DASHEncoder
AdobeHDS（HTTPDynamicStreaming）
FlashPlayer
FlashMediaServer
的最新版支持传统的
RTMP
协议和
HTTP协议。
后者和Apple和微软基于HTTP的方案类似。
基于HTTP的流的优势是：
不需要防火墙开普通web浏览器所需端口以外的任何端口
允许视频切片在浏览器、网关和CDN的缓存，从而显著降低源服务器的负载。
HDS
的文件格式为
FLV/F4V/MP4，索引文件为
f4m，同时支持直播和时移。
AppleHLS（HTTPLiveStreaming）
是一种基于HTTP的媒体流通信协议，在
iPhone3.0
及更新版中成为标准功能。
2010年10月，所有自适应串流方案都作为产权提供时，Apple
将HLS提交到
IETF，成为正式的
RFC.
HLS
串流使用扩展名为
.m3u8
的文件作为索引，文件切片格式为TS，支持直播和时移。
支持的客户端包括
iPad,iPhone,STB，VLC和其他支持的设备。
MicrosoftMSS（MicrosoftSmoothStreaming）
SmoothStreaming
是IIS的媒体服务扩展，用于支持基于HTTP的自适应串流。
在2010年11月发布的
IISMediaServices4.0
中，微软引入了一项使
LiveSmoothStreamingH.264/AAC
视频动态封装成
AppleHLS
格式的功能，直接提供给
iOS
设备，而不需要再次编码。
同时支持直播和点播把1080P全高清视频发送到Silverlight客户端。
MSS
的文件切片格式为
mp4（fragmented-mp4），索引文件为ism/ismc，同时支持直播和时移。
流行视频网站的流媒体服务器架构
为了能够提供各类设备的在线视频播放需求，对于在线视频流媒体服务，提出了很多需求，对于早期建立的视频网站（土豆，优酷，ku6等）都只提供一种视频流媒体格式（FLV）的支持，我们称之为单一的流媒体服务架构，如图：
图1
：
单一流媒体服务的架构图
但是，在实际业务运营中遇到了很多问题：
1）视频存储的压力很大
同一种视频码流（h.264）,因为针对不同平台应用设备（如表2）的播放需求，需要不同的封装格式，需要将产生大量重复视频流存储的压力，视频网站的视频量巨大，多支持一种格式将产生几百TB级的存储压力，从机房到机柜，视频流同步等环节负载和压力都是巨大的。
2）封装后的视频格式是否真的被播放
视频流封装完成后，同步到各地的中心节点后，是否真的有视频流请求产生，还是仅仅处于视频准备状态，是否会影响中心节点的磁盘占用，缓存节点的命中率不高。
3）封装格式的功能性升级，导致老视频再次封装
封装格式的不断发展，TS流，HTTPlive
升级会员 