在Internet上,流（Streaming）的定义非常广泛，主要是指通过网络传输多媒体数据的技术总称。
一、流媒体的定义
流媒体包含广义和狭义两种内涵：
. 广义流媒体
指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称，即流媒体技术；
. 狭义流媒体
是相对于传统的下载-回放方式而言的，指的是一种从Internet上获取音频和视频等多媒体数据的新方法，
它能够支持多媒体数据流的实时传输和实时播放。
通过运用流媒体技术，
服务器能够向客户机发送稳定和连续的多媒体数据流，
客户机在接收数据的同时以一个稳定的速率回放，而不用等数据全部下载完之后再进行回放。
流式传输有:
顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。
. 实时流式传输(Realtime Streaming)是实时传送，
特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差，以减少对传输带宽的需求。
"实时"的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系，这需要相应的协议支持，
它包括的协议有：
RTP, RTCP和RTSP
. 顺序流式传输(Progressive Streaming)
顺序流式传输是顺序下载，顺序流式传输不像实时流式传输那样，可以在传输期间根据用户连接的速度进行调整。
它包括的协议比较多，有：
RTMP， HTTP, MMS， 和HLS
二、RTP，RTCP和RTSP
2.1 RTP
参考文档 RFC3550/RFC3551
Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输层协议。
RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。
RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），
使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。
RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。
RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。
RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，
例如：在视频解码中，就不需要顺序解码。
RTP 由两个紧密链接部分组成：
RTP ― 传送具有实时属性的数据；
RTP 控制协议（RTCP） ― 监控服务质量并传送正在进行的会话参与者的相关信息。
2.2 RTCP
实时传输控制协议（Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）
是实时传输协议（RTP）的一个姐妹协议。RTCP为RTP媒体流提供信道外（out-of-band）控制。
RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。
RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量（Quality of Service）提供反馈。
RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，jitter，单向和双向网络延迟等等。
网络应用程序可以利用RTCP所提供的信息试图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。
RTCP本身不提供数据加密或身份认证。SRTCP可以用于此类用途。
实现实时视频流时，先用采集设备，直接把视频做成 H.264 的 NAL unit,而后通过 RTP打包，传输给客户端
有一篇文就是介绍如何把 NALu 用RTP打包的
图1 基于RTP的H.264视频传输
2.3 SRTP & SRTCP
参考文档 RFC3711
安全实时传输协议（Secure Real-time Transport Protocol或SRTP）
是在实时传输协议（Real-time Transport Protocol或RTP）基础上所定义的一个协议，
旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。
它是由David Oran（思科）和Rolf Blom（爱立信）开发的，并最早由IETF于2004年3月作为RFC3711发布。
由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议（RTP Control Protocol或RTCP）有着紧密的联系，
安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议（Secure RTCP或SRTCP）；
安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性，就像安全实时传输协议为实时传输协议提供的那些一样。
在使用实时传输协议或实时传输控制协议时，使不使用安全实时传输协议或安全实时传输控制协议是可选的；
但即使使用了安全实时传输协议或安全实时传输控制协议，所有它们提供的特性（如加密和认证）也都是可选的，
这些特性可以被独立地使用或禁用。唯一的例外是在使用安全实时传输控制协议时，必须要用到其消息认证特性。
2.4 RTSP
参考文档 RFC2326
是由Real Networks和Netscape共同提出的。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。
RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。
数据源包括现场数据与存储在剪辑中的数据。
该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、多播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。
RTSP（Real Time Streaming Protocol）是用来控制声音或影像的多媒体串流协议，
并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，
服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，
但并不特别强调时间同步，所以比较能容忍网络延迟。
而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，
更进而支持多方视讯会议（Video Conference）。
因为与HTTP1.1的运作方式相似，所以代理服务器《Proxy》的快取功能《Cache》也同样适用于RTSP，
并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。
2.5 RTSP 和RTP的关系
RTP不象http和ftp可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，
客户端也是按照这种速度观看影视文件，当影视画面播放过后，就不可以再重复播放，除非重新向服务器端要求数据。
RTSP与RTP最大的区别在于：
RTSP是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。
当然，RTSP可基于RTP来传送数据，还可以选择TCP、UDP、组播UDP等通道来发送数据，具有很好的扩展性。
它时一种类似与http协议的网络应用层协议。
图2 RTP-RTCP-RTSP的关系
RTP：实时传输协议（Real-time Transport Protocol）
RTP/RTCP是实际传输数据的协议
RTP传输音频/视频数据，如果是PLAY，Server发送到Client端，如果是RECORD，可以由Client发送到Server
整个RTP协议由两个密切相关的部分组成：RTP数据协议和RTP控制协议（即RTCP）
RTCP：RTCP包括Sender Report和Receiver Report，用来进行音频/视频的同步以及其他用途，是一种控制协议
RTSP：实时流协议（Real Time Streaming Protocol，RTSP）
RTSP的请求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顾名思义可以知道起对话和控制作用
RTSP的对话过程中SETUP可以确定RTP/RTCP使用的端口，PLAY/PAUSE/TEARDOWN可以开始或者停止RTP的发送，等等
2.6 SDP
会话描述协议（SDP）为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述。
会话目录用于协助多媒体会议的通告，并为会话参与者传送相关设置信息。
SDP 即用于将这种信息传输到接收端。
SDP 完全是一种会话描述格式 ― 它不属于传输协议 ―
它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、
MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。
SDP 的设计宗旨是通用性，它可以应用于大范围的网络环境和应用程序，而不仅仅局限于组播会话目录，
但 SDP 不支持会话内容或媒体编码的协商。
在因特网组播骨干网（Mbone）中，会话目录工具被用于通告多媒体会议，
并为参与者传送会议地址和参与者所需的会议特定工具信息，这由 SDP 完成。
SDP 连接好会话后，传送足够的信息给会话参与者。
SDP 信息发送利用了会话通知协议（SAP），它周期性地组播通知数据包到已知组播地址和端口处。
这些信息是 UDP 数据包，其中包含 SAP 协议头和文本有效载荷（text payload）。
这里文本有效载荷指的是 SDP 会话描述。此外信息也可以通过电子邮件或 WWW （World Wide Web） 进行发送。
SDP 文本信息包括：
会话名称和意图；
会话持续时间；
构成会话的媒体；
有关接收媒体的信息（地址等）。
协议结构
SDP 信息是文本信息，采用 UTF-8 编 码中的 ISO 10646 字符集。SDP 会话描述如下：（标注 * 符号的表示可选字段）：
v = （协议版本）
o = （所有者/创建者和会话标识符）
s = （会话名称）
i = * （会话信息）
u = * （URI 描述）
e = * （Email 地址）
p = * （电话号码）
c = * （连接信息 ― 如果包含在所有媒体中，则不需要该字段）
b = * （带宽信息）
一个或更多时间描述（如下所示）：
z = * （时间区域调整）
k = * （加密密钥）
a = * （0 个或多个会话属性行）
0个或多个媒体描述（如下所示）
时间描述
t = （会话活动时间）
r = * （0或多次重复次数）
媒体描述
m = （媒体名称和传输地址）
i = * （媒体标题）
c = * （连接信息 — 如果包含在会话层则该字段可选）
b = * （带宽信息）
k = * （加密密钥）
a = * （0 个或多个会话属性行）
三、RTMP
3.1 RTMP(Real Time Messaging Protocol)实时消息传送协议
是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。
它有三种变种：
1)工作在TCP之上的明文协议，使用端口1935；
2)RTMPT封装在HTTP请求之中，可穿越防火墙；
3)RTMPS类似RTMPT，但使用的是HTTPS连接；
RTMP协议(Real Time Messaging Protocol)是被Flash用于对象,视频,音频的传输.这个协议建立在TCP协议或者轮询HTTP协议之上.
RTMP协议就像一个用来装数据包的容器,这些数据既可以是AMF格式的数据,也可以是FLV中的视/音频数据.
一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的.
3.2 RTMP VS TCP&UDP
. TCP为点对点的协议，
这意味着各个客户需要分开客户机/服务器链接，因而无法在网络级实现对多个客户机的数据广播。
如果有一个数据流必须同时被传送到多个客户机，服务器必须传送数据流的副本到各个客户机，
TCP能够根据网络带宽和拥挤程度动态地调节传送速度并重新发送丢失的数据包，这样虽然保证了数据传输的可靠性，
但是对服务器资源耗费较大，在数据流大的场合难以保证数据流传输的实时性。
. UDP为不可靠传输协议，
在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度，计算机的能力和传输带宽的限制；
在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。
UDP协议不需要维护连接状态，也不认为每个数据包都必须到达接受端，因此网络负荷比TCP小，传输速度也要比TCP快；
但在网络越拥挤时，越有更多的数据包丢失。
. RTMP协议是一个专门为高效传输视频，音频和数据而设计的协议。
它通过建立一个二进制TCP连接或者连接HTTP隧道实现实时的视频和声音传输。
共享对象是RTMP数据中一种比较重要的数据类型，任何客户端改变数据时，共享对象能够及时更新服务器端的数据，
这样，每个客户端都能够及时了解到数据的变化。
RTMP比传统媒介服务器流出的媒介协议支持更多。
它支持可能包含声音，影像和脚本数据从服务器到客户和从客户到服务器多条线路的动态传输。RTMP对声音、影像和脚本数据分别处理。
声音和视频数据被分开地缓冲在服务器中。
如果声音数据在声音缓冲器中达到某一极限，所有在缓冲器中的数据将被丢掉，
并且最近到达的数据被允许开始收集在缓冲中并被送到各个客户。
视频数据被以相似的方式处理，不同是当新的关键帧到达时，缓冲器中数据才被清除。
在丢掉旧的帧数据时，如果发现客户端的数据有误，则将新旧两个不同的帧进行拟合。
RTMP对数据给予不同的优先级别。
在实时交谈中，声音是最重要的，影像给予低优先级，而脚本数据被给予的优先权介于声音和影像中间。
RTMP协议可以创建多个数据流，但是每个数据流只能有一个方向。
使用RTMP可以构建这样的一个系统，客户端可以同时与RTMP服务器和应用服务器进行交互，使得服务端的负荷得以分散，
虽然在这种改进的系统结构中，RTMP服务器的性能要求比较高。
四、MMS
MMS (Microsoft Media Server Protocol)，中文“微软媒体服务器协议”，用
来访问并流式接收 Windows Media 服务器中 .asf 文件的一种协议。
MMS 协议用于访问 Windows Media 发布点上的单播内容。
MMS 是连接 Windows Media 单播服务的默认方法。
若观众在 Windows Media Player 中键入一个 URL 以连接内容，而不是通过超级链接访问内容，则他们必须使用MMS 协议引用该流。
MMS的预设埠（端口）是1755
当使用 MMS 协议连接到发布点时，使用协议翻转以获得最佳连接。
“协议翻转”始于试图通过 MMSU 连接客户端。
MMSU 是 MMS 协议结合 UDP 数据传送。如果 MMSU 连接不成功，则服务器试图使用 MMST。
MMST 是 MMS 协议结合 TCP 数据传送。
如果连接到编入索引的 .asf 文件，想要快进、后退、暂停、开始和停止流，则必须使用 MMS。
不能用 UNC 路径快进或后退。若您从独立的 Windows Media Player 连接到发布点，则必须指定单播内容的 URL。
若内容在主发布点点播发布，则 URL 由服务器名和 .asf 文件名组成。例如：mms://windows_media_server/sample.asf。其中
windows_media_server 是 Windows Media 服务器名，sample.asf 是您想要使之转化为流的 .asf 文件名。
若您有实时内容要通过广播单播发布，则该 URL 由服务器名和发布点别名组成。
例如：mms://windows_media_server/LiveEvents。这里 windows_media_server 是 Windows Media 服务器名，
而 LiveEvents 是发布点名
五、HTTP
由于标准的HTTP服务器可发送这种形式的文件，也不需要其他特殊协议，因而它经常被称作HTTP流式传输。
由于该文件在播放前观看的部分是无损下载的，最终播放质量较好，
因而特别适合质量较高、数据量较小、通过Modem发布的短片段，如片头、片尾、广告等。
但用户在观看前必须经历数秒的延迟，传输速度较慢时尤为明显。
对通过调制解调器发布的短片段，顺序流式传输显得很实用，它允许用比调制解调器更高的数据速率创建视频片段。
尽管有延迟，毕竟可发布较高质量的视频片段。顺序流式文件是放在标准HTTP或FTP服务器上，因而易于管理，基本上与防火墙无关。
顺序流式传输不适合长片段和有随机访问要求的视频，如讲座、演说与演示，它也不支持现场广播。
因此，严格地说来，它本质上是一种点播技术。
六、HLS
HTTP Live Streaming（HLS）是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议，
可实现流媒体的直播和点播，主要应用在iOS系统，为iOS设备（如iPhone、iPad）提供音视频直播和点播方案。
HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。
相对于常见的流媒体直播协议，例如RTMP协议、RTSP协议、MMS协议等，
HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。
HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），
而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，
这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。
由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。
由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，
客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。
不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。
根据以上的了解要实现HTTP Live Streaming直播，需要研究并实现以下技术关键点
采集视频源和音频源的数据
对原始数据进行H264编码和AAC编码
视频和音频数据封装为MPEG-TS包
HLS分段生成策略及m3u8索引文件
HTTP传输协议
