常见直播协议介绍：RTMP、HTTP-FLV、HLS_直播推流协议

#.推流协议：

    由Adobe公司提出的一种应用层的协议，可用于实时传递音视频媒体数据。它基于传输层的TCP协议，通过与服务端建立长连接来传递数据。相较于其它同类协议，传输稳定，延迟较低，一般在1~3s，非常适合用于直播场景下的推流。

    当前手机app端只要是使用该协议来推流。

1.1 RTMPS:  RTMP的变种，使用HTTPS协议来传输数据，支持数据加密。

（可使用Rtmpdump库来进行Rtmp推流，Rtmpdump库也支持Rtmps，但打包时需要Openssl和zib库的支持。）    

#.拉流协议：

延迟较低，一般1~3s

由Adobe公司主推， HTTP-FLV 是 Http和Flv的结合体。在服务器端将推流端发送过来的视频帧和音频帧封装成flv格式，然后通过HTTP协议传输给拉流端，在传输层也是使用TCP协议。延迟较低，非常适合用于手机APP端拉流。

Flv格式：Adobe公司推出的一种媒体封装格式，用于封装H264+AAC编码帧。

包括文件头和文件体两大部分，文件头中包含了数据编码的相关信息，文件体由很多tag单元组成，每个tag单元中包含一个tag header(记录音频/视频类型、大小、时间戳等)和tag data(存储媒体数据)。

    HLS（HTTP Live Streaming）是由苹果公司推出的的基于 HTTP 的流媒体网络传输协议。

延迟较高，一般10~30s。

    它的工作原理当采集推流端将视频流推送到流媒体服务器时，服务器将收到的流信息每缓存一段时间就封包成一个新的 ts 文件，同时服务器会建立一个 m3u8 的索引文件来维护最新几个 ts 片段的索引。拉流端通过m3u8 索引文件获知需要的 ts 视频文件片段，通过HTTP协议请求这些片段。因为一个ts片段一般5~10s一个，在服务端要“攒够”足够长的数据才能下发给拉流端，所以延迟较长。

    延迟较高，不太适合用于直播场景。但很适合做回放点播，点播时服务端已经有了这些视频数据，不需要“攒数据”的时间。

    虽然延迟较低(1~3s)，但很多播放器不支持。国内的CDN也主要支持HTTP-FLV和HLS协议拉流。 而在 浏览器端需要 FlashPlayer支持 ，但 FlashPlayer也已被主流浏览器禁用。（ Ijkplayer官方版本也不支持，需要自己修改扩展功能后才能支持。）

1.1 Http是明文传递，没有加密，数据在中间被捕获后可被窃取和篡改；

  （即使使用了加密，在秘钥传输阶段，秘钥本身就可能被窃取。除非不用网络传输秘钥，本来双方就线下约定好了。）

1.2 Http没有很好的身份验证方式，客户端无法有效安全判断服务端身份，无法防范“中间人攻击”。（中间人攻击： 攻击者与通讯的两端分别创建独立的联系，交换所收到的双方数据，使通讯两端认为他们进行一个私密的连接与对方直接通话，而实际上数据可被中间人获取和篡改 ）。

     Https即Http协议+SSL/TSL协议，通过SSL/TLS协议来验证服务端身份，约定后继通信中的秘钥，这个过程使用非对称加密。

    然后后继利用这个秘钥使用对称加密来通信。

大概过程：

1.开始时，客户端的请求到达服务器端， 服务端返回自己的公钥证书给客户端 ；

（使用非对称加密算法生成公钥和私钥，可以向CA机构申请SSL证书，也可以用自签名方式自己生成。）

2.客户端验证公钥证书可靠性，确认服务端身份无误后，生成后继通信用的key，用服务端公钥加密后发送给服务端。

（因为只有服务端拥有对应的私钥，即使被截获，监听者也无法解密出这个key。 ）

（如果公钥证书是CA机构签发的，可用CA的公钥来验证；如果是自签名的，就要客户端来选择是否信任了。）

3.服务端用自己的私钥解密出这个key，后继使用这个key做秘钥，与客户端之间进行对称加密通信。 二者之间的数据都通过该key加密和解密。