#.推流协议：
1.
RTMP协议（Real Time Message Protocol，实时信息传输协议)
由Adobe公司提出的一种应用层的协议，可用于实时传递音视频媒体数据。它基于传输层的TCP协议，通过与服务端建立长连接来传递数据。相较于其它同类协议，传输稳定，延迟较低，一般在1~3s，非常适合用于直播场景下的推流。当前手机app端只要是使用该协议来推流。
1.1 RTMPS: RTMP的变种，使用HTTPS协议来传输数据，支持数据加密。（可使用Rtmpdump库来进行Rtmp推流，Rtmpdump库也支持Rtmps，但打包时需要Openssl和zib库的支持。）
#.拉流协议：
1.HTTP-FLV
延迟较低，一般1~3s由Adobe公司主推， HTTP-FLV 是 Http和Flv的结合体。在服务器端将推流端发送过来的视频帧和音频帧封装成flv格式，然后通过HTTP协议传输给拉流端，在传输层也是使用TCP协议。延迟较低，非常适合用于手机APP端拉流。
Flv格式：Adobe公司推出的一种媒体封装格式，用于封装H264+AAC编码帧。包括文件头和文件体两大部分，文件头中包含了数据编码的相关信息，文件体由很多tag单元组成，每个tag单元中包含一个tag header(记录音频/视频类型、大小、时间戳等)和tag data(存储媒体数据)。
2.HLS
HLS（HTTP Live Streaming）是由苹果公司推出的的基于 HTTP 的流媒体网络传输协议。延迟较高，一般10~30s。它的工作原理当采集推流端将视频流推送到流媒体服务器时，服务器将收到的流信息每缓存一段时间就封包成一个新的 ts 文件，同时服务器会建立一个 m3u8 的索引文件来维护最新几个 ts 片段的索引。拉流端通过m3u8 索引文件获知需要的 ts 视频文件片段，通过HTTP协议请求这些片段。因为一个ts片段一般5~10s一个，在服务端要“攒够”足够长的数据才能下发给拉流端，所以延迟较长。延迟较高，不太适合用于直播场景。但很适合做回放点播，点播时服务端已经有了这些视频数据，不需要“攒数据”的时间。
3.
RTMP协议（Real Time Message Protocol，实时信息传输协议)
虽然延迟较低(1~3s)，但很多播放器不支持。国内的CDN也主要支持HTTP-FLV和HLS协议拉流。 而在 浏览器端需要 FlashPlayer支持 ，但 FlashPlayer也已被主流浏览器禁用。（ Ijkplayer官方版本也不支持，需要自己修改扩展功能后才能支持。）
##.相关介绍： Http vs Https安全性
1.Http协议
1.1 Http是明文传递，没有加密，数据在中间被捕获后可被窃取和篡改；（即使使用了加密，在秘钥传输阶段，秘钥本身就可能被窃取。除非不用网络传输秘钥，本来双方就线下约定好了。）1.2 Http没有很好的身份验证方式，客户端无法有效安全判断服务端身份，无法防范“中间人攻击”。（中间人攻击： 攻击者与通讯的两端分别创建独立的联系，交换所收到的双方数据，使通讯两端认为他们进行一个私密的连接与对方直接通话，而实际上数据可被中间人获取和篡改 ）。
2.Https协议
Https即Http协议+SSL/TSL协议，通过SSL/TLS协议来验证服务端身份，约定后继通信中的秘钥，这个过程使用非对称加密。然后后继利用这个秘钥使用对称加密来通信。
大概过程：1.开始时，客户端的请求到达服务器端， 服务端返回自己的公钥证书给客户端 ；（使用非对称加密算法生成公钥和私钥，可以向CA机构申请SSL证书，也可以用自签名方式自己生成。）2.客户端验证公钥证书可靠性，确认服务端身份无误后，生成后继通信用的key，用服务端公钥加密后发送给服务端。（因为只有服务端拥有对应的私钥，即使被截获，监听者也无法解密出这个key。 ）（如果公钥证书是CA机构签发的，可用CA的公钥来验证；如果是自签名的，就要客户端来选择是否信任了。）3.服务端用自己的私钥解密出这个key，后继使用这个key做秘钥，与客户端之间进行对称加密通信。 二者之间的数据都通过该key加密和解密。