总体概述
流媒体（streaming media）是指将一连串的媒体数据压缩后，经过网上分段发送数据，在网上即时传输影音以供观赏的一种技术与过程，此技术使得数据包得以像流水一样发送；如果不使用此技术，就必须在使用前下载整个媒体文件。流媒体实际指的是一种新的媒体传送方式，有声音流、视频流、文本流、图像流、动画流等，而非一种新的媒体。主要相关协议包含：RTSP、RTMP、HLS、HTTP-FLV、WebSocket-FLV、HTTP-TS、WebSocket-TS、HTTP-fMP4、WebSocket-fMP4、MP4、WebRTC等。下面我们对其中几种协议进行介绍。
RTSP
RTSP协议说明
RTSP(Real Time Streaming Protocol):实时流媒体协议，是TCP/IP协议体系中的一个在IP网络上传输流媒体数据的应用层协议，RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，如音频流、视频流。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。HTTP与RTSP相比，HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。
RTSP架构流程
RTMP
RTMP协议说明
RTMP(Real Time Messaging Protocol)实时消息传输协议是Adobe公司提出得一种媒体流传输协议，其提供了一个双向得通道消息服务，意图在通信端之间传递带有时间信息得视频、音频和数据消息流，其通过对不同类型得消息分配不同得优先级，进而在网传能力限制下确定各种消息得传输次序。
RTMP是TCP/IP协议模型中的应用层协议，其工作在TCP之上，默认端口为1935，RTMP协议是基于TCP协议进行传输，因此其需要TCP特性来保证消息传输的可靠性，TCP通过三次握手成功建立连接后，RTMP协议还需要客户端和服务端通过RTMP握手协议来建立RTMP Connection,RTMP握手协议主要目的是协商RTMP版本及时间对齐作用。
RTMP Connection上会传输RTMP控制信息，比SetChunkSize,SetACKWindowSize，CreateStream等，其中CreateStream命令会创建一个Stream链接，用于传输具体的音视频数据和控制这些信息传输的命令信息。RTMP协议以RTMP Message格式传输，为了更好地实现多路复用、分包和信息的公平性，发送端把Message划分为带有MessageID的Chunk，每个Chunk可能是一个单独的Message，也可能是Message的一部分，在接受端会根据chunk中包含的data的长度，messageid和message的长度把chunk还原成完整的Message，从而实现信息的收发。
RTMP架构流程
HLS
HLS协议说明
HLS（HTTP Live streaming），是基于HTTP的流媒体传输协议，由Apple公司所提出的一种用于传输音视频的协议交互方式，当前HLS被广泛应用于视频点直播领域。HLS采用HTTP协议传输音视频数据，HLS通过将音视频流切割成一个个小的TS切片及生成m3u8的播放列表文件，播放客户端通过HTTP协议下载播放列表文件，按照播放列表文件制定的顺序下载切片文件并播放，从而实现边下载边播放，类似于实时在线播放的效果。
由于传输层只采用HTTP协议，因此其具备HTTP的网传优势，比如可以方便的透过防火墙或者代理服务器，可简单的实现媒体流的负载均衡，可以方便的结合CDN进行媒体分发等，另外HLS协议本身可实现码率自适应，通过视频转码，切片成不同码率的TS文件（码流），从而实现播放客户端根据网络带宽情况，自由的选择码流进行播放，但是HLS在直播时延时较大。 采用HLS协议传输流媒体的优劣势总结如下：
l 优势：客户端支持简单，H5 video即可直接播放；网络兼容性好，可很方便的通过防火墙或代理服务器，可很简单的实现媒体流的负载均衡，CDN支持良好；自带多码率自适应机制，实现播放码率自由选择。
l 劣势：延时较高，不能用于对延时较为苛刻的场景，如互动直播领域；TS切片较多，特别是实时视频流，需要动态的生成和删除TS切片文件，为了实现高性能、低碎片化，对于文件存储的逻辑需要更加复杂的设计。
HLS架构流程
HLS整体流程框图如下：
音视频输入单元采集音视频数据，通过媒体编码器编码成所需要的编码格式和码率，并以TS格式对音视频流进行封装，流切片器对封装好的TS流，按照预设的分割时间大小对TS流进行切片，并同时更具切片信息生成或更新m3u8文件列表文件，把播放列表文件和TS文件存储到web服务器配置的路径下，播放客户端通过HTTP协议向web服务器拉取播放列表，根据播放列表内容依次拉取TS切片文件并播放。
l 媒体编码器(media decoder)：媒体编码器获取音视频设备的实时信号，通过预设的编码格式进行编码，或者通过流媒体协议接入已编码好的音视频流，根据流媒体预设条件确定是否需要转码，由编码或者转码操作，得到编码后的音视频流，然后根据TS封装格式对音视频流进行封装，封装后发送到切片器进行切片。
l 流切片器(stream segmenter)：接收媒体编码器打包好的TS流，或者读取TS流的录像文件，按照预设时间间隔把TS流切片成等时间间隔的TS流切片文件，并生成或更新索引文件(m3u8文件/playlist播放列表文件)，每个新的切片生成之后，索引文件都要更新，索引文件用于定位切片文件的位置及有效性判断。
l web服务器：用来提供HTTP服务器，并提供索引文件和切片文件下载的服务，这里可采用nginx来搭建。
FLV
HTTP-FLV
HTTP-FLV，即将音视频数据封装成 FLV，然后通过 HTTP 协议传输给客户端。FLV (Flash Video) 是 Adobe 公司推出的另一种视频格式，是一种在网络上传输的流媒体数据存储容器格式。其格式相对简单轻量，不需要很大的媒体头部信息。整个FLV由 The FLV Header, The FLV Body 以及其它 Tag 组成。因此加载速度极快。采用 FLV 格式封装的文件后缀为 .flv。而HTTP-FLV 即将流媒体数据封装成 FLV 格式，然后通过 HTTP 协议传输给客户端。
HTTP协议中有个约定：Content-Length字段，HTTP的body部分的长度服务器回复HTTP请求的时候如果有这个字段，客户端就接收这个长度的数据然后就认为数据传输完成了，如果服务器回复HTTP请求中没有这个字段，客户端就一直接收数据，直到服务器跟客户端的socket连接断开。
HTTP-FLV直播就是利用第二个原理，服务器回复客户端请求的时候不加Content-Length字段，在回复了HTTP内容之后，紧接着发送flv数据，客户端就一直接收数据了。
（1）优点
HTTP-FLV 依靠 MIME 的特性，根据协议中的 Content-Type 来选择相应的程序去处理相应的内容，使得流媒体可以通过 HTTP 传输。相较于 RTMP 协议，HTTP-FLV 能够较好的穿透防火墙，它是基于 HTTP/80 传输，有效避免被防火墙拦截。除此之外，它可以通过 HTTP 302 跳转灵活调度/负载均衡，支持使用 HTTPS 加密传输，也能够兼容支持 Android，iOS 的移动端。
（2）缺点
由于HTTP-FLV的传输特性，会让流媒体资源缓存在本地客户端，在保密性方面不够好。因为网络流量较大，它也不适合做拉流协议。
WebSocket-FLV
基于WebSocket传输FLV，依赖浏览器支持播放FLV。WebSocket建立在HTTP之上，建立WebSocket连接前还要先建立HTTP连接。基于WebSocket来传输FLV格式的音视频。可以用来替代RTMP，解决其需要浏览器端依赖flash的问题；替代HTTP-FLV，解决浏览器同域名请求的最大并发数限制导致的浏览器只能播放6路HTTP-FLV流的问题。
fMP4
FMP4格式（Fragmented MP4）是一种视频和音频流媒体格式，是MPEG-4 Part 12标准的一种扩展。与传统的MP4格式不同，FMP4格式将媒体文件分成若干个片段（Fragment），每个片段都是一个完整的MP4文件，其中包含了媒体数据、元数据和索引信息。
FMP4格式（Fragmented MP4）是一种视频和音频流媒体格式，是MPEG-4 Part 12标准的一种扩展。与传统的MP4格式不同，FMP4格式将媒体文件分成若干个片段（Fragment），每个片段都是一个完整的MP4文件，其中包含了媒体数据、元数据和索引信息。
FMP4格式的应用范围广泛，包括直播、点播、视频会议等。它具有低延迟、高清晰度、高效传输等特点，能够为用户带来更加流畅和稳定的视听体验。
HTTP-fMP4
HTTP-fMP4 (HTTP-Fragmented MP4)是一种使用HTTP协议传输fMP4格式的流媒体的协议。fMP4是一种流式媒体格式，通常与HTML5视频播放器一起使用。它支持更好的流式传输和更好的性能，适用于现代Web应用和移动设备。
WebSocket-fMP4
WebSocket-fMP4（Fragmented MP4） 是一种使用WebSocket协议传输fMP4格式的流媒体的协议。它具有实时性，与HTML5视频播放器兼容，适用于现代Web应用和移动设备。总的来说，HTTP-FLV 和 WebSocket-FLV 使用了FLV格式，而HTTP-fMP4 和 WebSocket-fMP4 使用了fMP4格式。FLV通常与Flash相关，而fMP4更适合现代Web和移动设备。WebSocket-FLV 和 WebSocket-fMP4 都使用WebSocket协议，适用于实时流传输。选择其中一个协议取决于您的需求和项目的技术栈。
WebRTC
WebRTC协议说明
WebRTC（Web Real-Time Communication），是一个支持网页浏览器进行实时语音对话或视频对话的API。WebRTC使用安全实时传输协议（Secure Real-time Transport Protocol，SRTP）对RTP数据进行加密，消息认证和完整性以及重播攻击保护。它是一个安全框架，通过加密RTP负载和支持原始认证来提供机密性。WebRTC的安全特性是其可靠性的重要组成部分，其基础全部围绕实时传输协议（Real-time Transport Protocol）进行。
WebRTC架构流程
WebRTC目前比较普遍的框架描述如下图所示，WebRTC整体架构从上到下一共分为三层，最上层是WebAPI层，这一层是暴露给开发人员的用于开发WebRTC应用的JavaScript API;中间的那一层是WebRTC技术最为关键核心的一层，一共包括三个模块，分别是音频引擎、视频引擎以及网络传输；最下层是由各厂商自主开发的一层，用于实现音视频的采集和网络IO。
l 音频引擎
音频引擎（VoiceEngine）负责WebRTC的音频通信，通过一套完整的音频处理框架，解决了音频从外接设备如麦克风读入数据然后再通过网络进行传输的音频处理问题。主要分为两个模块：音频编解码和语音信号处理。其核心是回声消除(AcousticEchoCancceler，AEC)和降噪(NoiseReduction，NR)。回声消除是一种改善声音质量，消除产生的回声或防止其发生的方法。降噪是从信号中去除噪声的过程。音频机制主要分为iSAC和iLBC两大类编解码器。iLBC编解码器该窄带音频编解码器适用于IP上的语音通信。
l 视频引擎
视频引擎（VideoEngine）负责WebRTC的视频通信，通过一套完整的视频处理框架，解决了视频从外接设备如摄像头采集数据然后再通过网络传输最后显示视频的视频处理问题。主要分为两个模块：视频图像编解码和视频图像处理。视频图像编解码方面，默认的编解码器是VP8，比较适合实时通信场景下的视频编解码。视频图像处理方面，通过两种方式来保证传输的视频图像的高质量、美观性，一方面，利用视频抖动缓冲器来减小由于抖动和丢包带来的影响，另一方面对采集到的图像进行颜色增强、降噪等处理来提升图像清晰度。
l 网络传输
网络传输负责音视频数据的传输，通过一套完整的传输框架，解决了音视频数据的加密传输和防火墙穿透问题。一方面，通过SRTP协议保证音视频数据在加密的状态下进行传输，另一方面，通过整合了STUN和TURN的ICE协议来保证音视频数据可以突破防火墙和NAT网络的限制。
应用场景说明
RTMP和HTTP-FLV都是建立在FLV封装之上的。RTMP一般用作直播源推流，HTTP-FLV一般用作直播观看。RTMP 协议为流媒体而设计，在推流中用的比较多，同时大多 CDN 厂商支持RTMP 协议。
HTTP-FLV 使用类似 RTMP流式的 HTTP 长连接，需由特定流媒体服务器分发的，兼顾两者的优点。以及可以复用现有 HTTP 分发资源的流式协议。它的实时性和 RTMP 相等，与 RTMP 相比又省去了部分协议交互时间，首屏时间更短，可拓展的功能也更多。
HLS 作为苹果提出的直播协议，在 iOS 端占据了不可撼动的地位，Android 端也同时提供相应的支持。