流媒体业务是一种对实时性、连续性、时序性要求非常高的业务，无论从带宽消耗上还是质量保障上来说，
对best-effort的IP网络都是一个不小的冲击
–高带宽要求
–高QoS要求
–组播、广播要求（目前IP网络无法实现端到端的组播业务）
播放一个视频分为以下四个步骤
–Access
–Demux（音视频分离）
–Decode(解码解压缩)
–Output
RTP、RTCP、RTSP、RTMP的关系：
RTSP协议用来实现远程播放控制，RTP用来提供时间信息和实现流同步，
RTCP协助RTP完成传输质量控制<=（播放控制），
=>（传输控制）RTMP和HTTP streaming则是将流同步、播放控制、质量控制集成起来的企业自有流媒体传送协议
RTMP是adobe的传输协议。
RTMP的基本通信单元：消息块（chunk）和消息（message）
RTMP协议架构在TCP层之上，但RTMP消息并不是直接封装在TCP中，而是通过一个被称为消息块的封装单元进行传输。
消息在网络上发送之前往往需要分割成多个较小的部分，这样较小的部分就是消息块，属于不同消息流的消息块可以在网络上交叉发送。
RTSP/RTP和HTTP streaming是目前应用最广泛的流化协议，
目前电信运营商在IPTV（特殊通道的基于IP的流媒体播放）的流化上主要以RTSP/RTP技术为主，
而互联网视频网站（点播/直播）则多倾向于使用HTTP streaming的流化技术。
HTTP streaming前身是progressive download（渐进式下载：边下载边播放，直到下载完）。
HTTP streaming首先会将视频数据（包括直播的视频流和点播的视频文件）在服务器上进行编码，
然后将编码后的数据进行更细粒度的分片，再把每个分片通过 HTTP协议传输到客户端。
HTTP streaming的客户端需要对视频文件的每个分片都发出一个HTTP请求，
这样，在视频播放速度低于下载速度的情况下，
客户端可以灵活控制HTTP请求的发出速度，从而保证用户在中途退出时不会出现下载浪费。
另外，因为采用分片的特点，HTTP streaming还可以实现媒体播放过程中的码率切换（码率自适应），
结合网络带宽资源，为用户提供更好的体验。
HTTP streaming
支持点播、直播
可对分片文件加密，保证数字版权
因为分片传输，故支持码率自适应
Progressive download
仅支持点播
直接把媒体文件分割成多个小文件分片，无法保障版权所有
只支持固定码率
HTTP streaming
基于TCP，更高可靠性，也可以直接利用TCP的流控机制来适应带宽的变化
可将播放过的内容保存在客户端
使用80端口，能穿越防火墙
采用标准的HTTP协议来传输，只需要标准的HTTP服务器支撑
RTSP/RTP
基于UDP
不能保存在客户端
使用特殊端口
需要特殊的流媒体服务器
HTTP streaming的几个主流阵营：
–3GPP adaptive HTTP Streaming
–Microsoft IIS Smooth Streaming
-Adobe HTTP Dynamic Streaming (HDS)
–Apple HTTP Live Streaming (HLS)
HLS流化技术主要分三个部分：
服务器组件、分发组件和客户端软件
–服务器组件主要负责从原始的音视频设备捕捉相应的音视频流，并对这些输入的媒体流进行编码，
然后进行封装和分片，最后交付给分发组件来进行传送；
–分发组件主要负责接收客户端发送的请求，然后将封装的流媒体分片文件连同相关的索引文件一起发送给客户端。
对于没有采用CDN服务的源服务器，标准的 Web服务器就是一个分发组件，
而对于大型的视频网站或者类似的大规模应用平台，分发组件还应包括支持RTMP协议的CDN；
–客户端软件负责确定应该请求的具体媒体流，下载相关资源，并在下载后通过拼接分片将流媒体重新展现给用户
HLS音视频流或流媒体文件在经过编码、封装和分片后，变成多个以.ts结尾的分片文件。
流分割器产生的索引文件是以.M3U8为后缀的，用户可以直接通过Web访问来获取
分发组件负责将分片文件和索引文件通过HTTP的方式发送给客户端，
无须对现有的Web服务器和Cache设备进行额外的扩展、配置和升级
客户端组件根据URL来获取这个视频的索引文件。
索引文件包含了可提供分片文件的具体位置、解密密钥以及可用的替换流。
HDS，点播内容是通过一个简单的预编码生成MP4片段以及Manifest清单文件；
直播的内容准备工作流程相对复杂一点，
在播放的过程中生成MP4.（直播推荐用RTMP，使用FMS推流器）
MPEG-2 TS是指TS格式封装的、MPEG-2编码格式的媒体流。大多数IPTV系统使用这种内容源。
H.264这一层完成原始文件的压缩编码，TS这一层负责音 视频的复用以及同步，
RTP这一层负责流的顺序传输，UDP这一层负责数据包的交付，IP层负责传输路由选择
流媒体加速的回源要求：因为流媒体文件传送带宽需求高，而且往往需要维持TCP长连接，
所以一旦CDN回源比例过高，源 站服务器I/O将不堪负荷。
CDN对内容采取分发方式分为pull和push两种。Pull是被动下拉的方式，push是主动推送的方式。
对于流媒体内容，系统一般会选择对热点内容采取push方式的预分发，而普通的网页内容几乎100%是pull方式的。
在流媒体CDN系统中，用户访问的调度会更多考虑内容命中，主要是因为流媒体内容文件体积大，业务质量要求高，
如果从其他节点拉内容再向用户提供服务会带来额外的延迟，影响用户体验。
为进一步提高命中率，流媒体CDN系统普遍采用了对热点内容实施预先push的内容分发策略
在流媒体服务系统中，主要关注的技术是对不同流媒体协议、不同编码格式、不同播放器、不同业务质量要求等的适应。
流媒体CDN与Web CDN的对比（业务差异）
主要差异点
内容类型
流媒体CDN:大文件、实时流、QoS要求高
Web CDN:小文件、固定大小、QoS要求低
用户行为
流媒体CDN:拖曳、暂停等播放控制
Web CDN:下载后浏览
内容管理
流媒体CDN:内容冷热度差异明显（对命中率要求高），内容生命周期长
Web CDN:内容冷热度差异不明显，内容生命周期短
回源要求
流媒体CDN:回源比例小
Web CDN:回源比例大
现在已经投入商用的CDN系统，基本都是同时提供Web CDN能力和流媒体CDN能力的，
而且这两种能力的实现在系统内部几乎都是互相隔离的，从调度系统到节点设备都没有交叉互用
流媒体CDN与Web CDN的设计差异（设计差异）
主要差异点
Cache
流媒体CDN:支持多种流化协议，硬件配置大存储、高I/O
Web CDN：支持多协议（HTTP、FTP等）硬件配置小存储、高性能CPU
负载均衡
流媒体CDN:DNS+HTTP重定向方式
Web CDN:DNS方式
内容分发方式
流媒体CDN：热片PUSH，冷片PULL
Web CDN：全PULL方式
组网
流媒体CDN：多级组网，可能要求组播、单播混合组网
Web CDN:两级组网
流媒体CDN的Cache设备与Web Cache无论在软件实现还是硬件要求上差异都很大，我们很少看到这两种业务共用同一台设备
当用户请求的内容在Cache上命中时，Cache直接向用户提供流服务，此时Cache设备充当流媒体服务器的角色； 当用户请求内容未能在Cache上命中时，Cache会从上一级Cache（二级缓存设备或中间缓存设备）或者源站服务器获取内容，再提供给用户。
Cache在用户与另一个流媒体服务器之间扮演代理的角色
分布式存储技术因其大容量、低成本的特点，目前也被业界关注和研究作为流媒体CDN系统的存储解决方案之一。
常用的分布式存储技术包括分布式文件系统和分布式数据库，
由于采用了数据副本冗余（每份数据复制2~3份）、磁盘冗余（Raid1、Raid10、Raid5）等技术，
通常可以提供良好的数据容错机制，当单台存储设备断电或者单个存储磁盘失效时，整个存储系统仍能正常工作
负载均衡设备在进行用户访问调度时，会综合考虑很多静态的、动态的参数，包括IP就近性、连接保持、内容命中、响应速 度、连接数等。
但没有哪个CDN会考虑所有参数，而是会根据业务特点进行一些取舍，否则均衡系统就太复杂了。
而流媒体CDN在进行用户访问调度时，会更多考虑内容命中这一参数
有两种GSLB实现方式，一种是基于DNS的，一种是基于应用层重定向的
PUSH方式适合内容访问比较集中的情况，如热点的影视流媒体内容，PULL方式比较适合内容访问分散的情况
对使用CDN服务的SP来说，CDN的作用在于尽量就近为用户提供服务，
帮助SP解决长距离IP传输和跨域传输带来的种 种业务质量问题（通过空间换取时间）。
因此，为用户提供服务的Cache设备一定部署在离用户比较近的地方。另一方面，CDN的建设者从成本角度考虑，又 不能把所有内容都存放在这些离用户最近的节点中，这会消耗大量存储成本，所以这些提供服务的Cache设备会根据需要从源站服务器或者其他Cache获取 内容。
这样就形成了CDN网络分层部署的概念。
从网络分层上看，Web CDN通常是两级架构（也有三级架构以减少回源），即中心-边缘。而流媒体CDN通常有三级以上架构，即中心-区域-边缘。
产生这种区别的原因在于流媒体 回源成本比较高，源站服务器响应一次流媒体内容回源请求，要比Web内容回源消耗更多资源。
尤其对于流媒体直播业务来说，只要直播节目没结束，服务器就需 要长时间持续吐流，如果没有第二层节点作为中继，那么中心节点的压力将是不可想象的。
分层部署的方式，对点播业务而言的主要意义是节省存储成本，对直播业务而言在于减少带宽成本。
在点播业务中，边缘Cache只需存储用户访问量大的内容或者内容片断，其余内容存储在区域Cache中。
在直播业务中，边缘Cache从区域中心获取直播流，而不需要直接向中心节点（源站）获取，
从而节省了区域中心到中心节点这一段的大部分带宽。
因为直播流在各个Cache中都不需要占用很大的存储空间，只需少量缓存空间即可，
所以直播业务方面并不用注重考虑存储成本
考虑到电信运营商的IP拓扑和流量模型，区域中心Cache通常部署在重点城市的城域网出口的位置，
以保障向各个边缘 Cache的链路通畅。
边缘Cache的位置选择则以整个节点能够提供的并发能力为主要依据，依据业务并发数收敛比，
计算出单个Cache需要覆盖的用户 规模，从而选择一个合适的部署位置。
当然，边缘Cache离用户越近，服务质量越好，但覆盖的用户数越少，部署成本越高。
内容文件预处理
是指视频内容进入CDN以后，进入内容分发流程之前，CDN系统对内容进行的一系列处理过程。这个预处理过程的目的有几个：
–为全网内容管理提供依据，比如对内容进行全网唯一标识，对内容基础信息进行记录等
–为提高CDN服务效率或降低系统成本提供手段，比如内容切片
–为满足业务要求提供能力，比如对同一内容进行多种码率的转换以满足动态带宽自适应或三屏互动业务要求
视频转码(video transcoding)
– 码率转换
–空间分辨率转换
–时间分辨率转换
– 编码格式转换。编码格式主要包括H.264、MPEG-4、MPEG-2、VC-1、REAL、H.263、WMV。通常是把其他编码格式转换成H.264
文件切片
是指按照一定的规则把一个完整的文件切成大小一致的若干个小文件；
由于流媒体CDN需要提供的内容体积越来越大，传统整片存储带来的成本消耗超出了CDN服务商的承受范围；
切片的另一个目的是，使边缘Cache能够支持自适应码率业务
防盗链机制和实现
–基于IP的黑白名单
–利用HTTP header的referer字段
–使用动态密钥（随机生成的key通过算法生成新的url）
–在内容中插入数据（对有版权内容进行加密（DRM），如Microsoft的playready，Google的Widevine）
–打包下载：在原文件的基础上进一步封装，使得资源的hash值改变
备注：随笔中内容来源于网上资料整理,仅供参考。