直播协议基础

从网络上搜寻到的有关推流与拉流的示意图

从推拉流和协议入手来讲解直播

推流与拉流

推流与拉流示意图：

其实可以简要的理解为推流就是直播端，而拉流就是客户端哦。

推流

推流：将直播的内容推送至服务器的过程。即指的是把采集阶段封包好的内容传输到服务器的过程。其实就是将现场的视频信号传到网络的过程。“推流”对网络要求比较高，如果网络不稳定，直播效果就会很差，观众观看直播时就会发生卡顿等现象，观看体验很是糟糕。要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1–3秒，对于手机直播这种实时性要求非常高的场景，RTMP也成为手机直播中最常用的流传输协议。最后通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发。

拉流

拉流：指服务器已有直播内容，用指定地址进行拉取的过程。即是指服务器里面有流媒体视频文件，这些视频文件根据不同的网络协议类型（如RTMP、RTSP、HTTP等）被读取的过程，称之为拉流，说的简单点，你观看优酷视频就可以看成是拉流，视频文件存储在优酷的服务器上面，你通过HTTP（或者RTMP/RTSP）协议，也就是网页的形式去获取视频观看，这就是拉流的过程，在这个过程中有三个要素：

1. 服务器【提供视频文件存储的地方】
2. 传输协议【就是你要通过什么方式传输视频】
3. 读取终端【就是通过什么播放出来】

直播传输协议

流媒体中的传输协议有很多种，主要从开源流媒体协议与格式来说。（自定义不开源的直播协议，可以参考阿里云、腾讯云等云厂商的服务，如ARTC协议）

RTMP协议由Adobe公司开发，基于TCP协议，是Flash播放器和服务器之间音频、视频和数据传输的开放协议，目前主流的视频云服务都以RTMP为主要推流协议。
ARTC是阿里云提供的低延迟直播RTS（Real-time Streaming）解决方案使用的协议头。
SRT是一种基于UDT协议（一种基于UDP协议的变种）的开源低延迟视频传输协议，解决了TCP协议传输延迟高的问题。Haivision和Wowza合作成立SRT联盟，管理和支持SRT协议开源应用的组织。主要用于海外直播主流，是未来直播技术的主流协议。

RTMP传输协议 && HTTP-FLV协议

RTMP和HTTP-FLV都是建立在FLV封装之上的，主要区别是RTMP一般用作直播源推流，HTTP-FLV一般用作直播观看。

• RTMP: 一般用于直播源推流，直播系统内直播流数据传递
• HTTP-FLV: 一般用于客户端直播流观看
• RTMP、HTTP-FLV协议都是在FLV封装格式基础上的

RTMP是Real Time Messaging Protocol（实时消息传输协议）的首字母缩写。一种设计用来进行实时数据通信的网络协议。
该协议基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。

为什么RTMP做推流，反而很少做拉流？

但是由于浏览器摒弃了Flash播放器，而且据说高并发下可能会出现一些不稳定的问题，所以RTMP一般只用作直播源推流、推流到直播CDN等场景。

每一个推流码地址唯一指向单个的直播活动。它由rtmp：//开头，包含了上传服务器地址，上传目录名（应用app）和上传节点（房间），三部分组成。所有的rtmp地址都是这种结构组成，基本同一个平台不同直播的地址前两部分是不变的。

RTMP协议需要特定的流媒体服务软件，如SRS、加入了RTMP插件的Nginx等。
此类流媒体服务软件实际上就是音视频数据的中转站，数据一般只在内存中循环覆盖，不会写入磁盘。
如果要做直播回放，需要服务器自己开发音视频存储功能。
RTMP协议的延迟是比较低的，大概在1-3秒左右。
RTMP通信是建立在TCP长连接通道上的，在封装音视频数据时会强制切片，限制每个数据包的大小。
强制切片也一定程度保证了实时性。有一定的弱网抵抗能力，因为每个数据包都不会太大，所以当某个数据包校验失败时，重新发送的成本不会太大，但也由于合并数据包会加大CPU压力，所以是有一定的性能消耗的。

RTMP协议还有一些变种协议，如RTMPT、RTMPS等，这里不作展开讨论。

HTTP-FLV协议

地址是http://开头的，是基于HTTP协议的HTTP-FLV可以简单地理解为RTMP的HTTP协议版本。功能和工作原理上是相似的，上面提到的RTMP切片数据功能HTTP-FLV也是有的。
但是，HTTP-FLV协议一般只能用作拉流观看。
HTTP-FLV协议的延迟也是比较低的，大概在1-3秒左右，但实际体验下来 HTTP-FLV延迟会略高于RTMP，但是HTTP-FLV相对RTMP适配更多的播放场景。

• HTTP-FLV协议可以看作是RTMP的HTTP版本
• RTMP工作原理相似
• 延迟1-3秒(比RTMP协议延迟略高)
• HTTP-FLV一般只用作客户端拉流观看

HTTP-FLV直播流一般需要需加入插件才能播放，如网页需要引入flv.js后，浏览器才能播放。HTTP-FLV直播流，这里需要特别感谢B站开源的flv.js，它促进了HTTP-FLV在浏览器的普及。

HTTP-FLV协议需要特定的流媒体服务软件，如加入了HTTP-FLV插件的Nginx等。
值得一提的是，Nginx的HTTP-FLV插件是包含RTMP功能的，所以一般HTTP-FLV的流媒体服务，推流是以RTMP协议，拉流是用HTTP-FLV协议。

现在比较流行的方案是，直播源推流是RTMP协议，直播拉流观看是HTTP-FLV协议。

RTSP协议

RTSP（Real Time Streaming Protocol），RFC2326，实时流传输协议，是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。
RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。HTTP与RTSP相比，HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。因为与HTTP1.1的运作方式相似，所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

HLS协议

HTTP Live Streaming（缩写是HLS）是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。是 苹果公司 QuickTime X和iPhone软件系统的一部分。

• HLS协议一般只用作拉流观看，但是从严格意义上讲，HLS协议并不是流式协议。
• HLS协议的文件由两部分组成，一是多个只有几秒长度的.ts碎片视频文件，另一个是记录这些视频文件地址的.m3u8索引文件，且这些静态文件都是直接写入磁盘的。

它工作原理很简单，就是通过HTTP协议下载静态文件。不同的是，把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U (m3u8)playlist文件，用于寻找可用的媒体流。

具体的说，HLS观看地址是以http://开头、.m3u8结尾的，实际上这个地址就是索引文件的地址，客户端获取到索引文件后，就可以下载对应的碎片视频文件并开始播放了。

HLS只请求基本的HTTP报文，与实时传输协议（RTP)不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。

HTTP 协议一般指 HTTP（超文本传输协议）。超文本传输协议（英语：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议，是因特网上应用最为广泛的一种网络传输协议，所有的 WWW 文件都必须遵守这个标准。

• 由于HLS协议实际上是通过HTTP协议请求文件的，且HLS相关文件是直接写入磁盘的，所以并不需要特殊的流媒体服务软件，使用Nginx等HTTP服务就可以了。
• HLS协议可以用于点播和直播观看，其适配多种播放场景，一般加入插件就可以播放了，如网页加入HLS的js插件就可以播放了，苹果设备是原生支持HLS协议的。

点播的场景下，也就是普通网络视频观看的场景下。
.m3u8索引文件会记录所有的碎片视频文件地址，HLS在点播的场景下，优势是更加明显的。
由于HLS的相关文件是无状态的静态文件，且每个文件的大小是有限的，所以负载均衡、CDN加速的效果更佳明显。
HLS协议的点播视频，会比.mp4、.flv的视频更快地播放出来，且在加载中跳转视频也会更加顺滑。

直播的场景下，转码软件可以直接生成HLS相关文件到磁盘，客户端通过HTTP服务下载文件即可。
另外，也可以在Nginx加入RTMP插件，转码软件以RTMP协议推流到Nginx，再由Nginx生成HLS相关文件。
其中，后一种方案更加推荐，因为它对于前期研发和后期对接直播CDN的过度更加顺滑。

另外，直播场景下的HLS相关文件与点播是有些不同的。

• 视频流数据每几秒会打包成一个以.ts为后缀的碎片视频文件，每生成一个新的视频文件都会同步更新.m3u8索引文件。
• 且碎片视频文件的个数是有上限的，当达到上限后，默认会将最旧的视频文件删除且更新.m3u8索引文件。
• 所以在直播的场景下，客户端也需要不断定时重新获取.m3u8索引文件。
  
  HLS协议在直播的场景下是没什么优势的。
  虽然HLS协议的直播流也可以适配很多播放场景，但是由于需要生成静态文件，直播延迟很大，大概在5-30秒左右，使用直播CDN的话，由于边缘节点同步等问题，直播延迟甚至可能会达到1分钟左右。
  当然HLS协议也有一定的优势，在直播时移，也就是直播转点播，或者录播，也就是点播转直播的场景， 理论上只需要修改索引文件就可以了。
• HLS协议延迟5-30s，也可能会有1分钟延迟
• HLS的直播优势是ts视频碎片文件可以一直保留不删除
• 不需要花额外的性能保存录像
• 直播转点播、录播都是更加简单的，只需要修改m3u8索引文件即可(不需要重新花费性能编解码)

另外，HLS协议的.m3u8索引文件支持二级索引，就是高清、标清、流畅等多个观看地址可以整合到一个索引文件。播放器可以根据当前带宽自动切换不同的观看地址，大部分网页播放器的“自动”也是因为这个。

这里补充一个HLS协议的小知识点。
由于HLS协议的视频文件、索引文件都是直接写入磁盘的 ，所以如果长时间且多个直播流同时处理，会造成磁盘写入压力过大，机械磁盘可能会磁道会损坏，固态硬盘的寿命会加速衰减。
这种情况下，最好挂载一段内存空间作为HLS相关文件的写入位置，则不会造成磁盘写入压力过大的问题。

挂载一段内存空间作为写入位置
Linux命令: mount -t tmpfs -o size=10g tmpfs /data
把文件写入/data，即可写入内存，而非磁盘
重启数据会消失，但可以做一些定时保存的措施

补充说明一下，HLS协议是苹果推出的标准，与HLS协议类似的还有MPEG-DASH协议 HLS、MPEG-DASH的工作原理都是差不多的，只是局部标准不一样，这里不作展开。

• HLS是苹果公司发布的标准，MPEG-DASH是国际标准
• 两者大致相同，只是细节存在差异

SRT协议

SRT协议我也不太了解，自己也没有开发SRT服务相关经历，只知是新一代最优秀的直播协议。
目前阿里云也有SRT的服务产品可直接购买，以下是SRT协议链接，大家可底下自行研究。

WebRTC协议应用于直播

WebRTC协议其实并不是为了直播场景而设计的，WebRTC是一种点对点的视频/语音通话协议。
由于WebRTC是基于UDP的，建立通信后，会不断以流式发送数据，所以延迟会比RTMP还要低。
在一些交互性较高的直播场景，如直播带货等场景，会使用WebRTC作为推流和观看协议 WebRTC的延迟理论上可以达到1秒内。

• WebRTC协议支持推流和拉流，地址一般是以webrtc:// 开头的，且推流和拉流地址一般也是一样的。
• WebRTC虽然是点对点的协议，但是应用在直播场景的话，是需要搭建WebRTC服务器作为流媒体服务的，流媒体服务软件可以使用SRS。

SRS是一个比较流行的开源流媒体服务软件，目前4.0已经囊括了RTMP、HLS、WebRTC、HTTP-FLV等主流协议。