大家好，欢迎来到停止重构的频道。

本期我们详细讨论直播的相关协议，包括：HTTP-FLV、HLS、RTMP、Web-RTC、RTSP等等。

我们将会详细介绍这些协议的工作原理、应用场景、及延迟的原因。

我们按这样的顺序讨论​

1、  RTMP、HTTP-FLV 

2、  HLS 

3、  Web-RTC 

4、  RTSP 

RTMP、HTTP-FLV协议

RTMP和HTTP-FLV都是建立在FLV封装之上的。

RTMP一般用作直播源推流，HTTP-FLV一般用作直播观看。

我们先讨论RTMP，RTMP协议是既可以推流、也可以拉流的协议。

RTMP地址是rtmp://开头的，且推流地址与播放地址是一样的。

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

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直播流一般需要需加入插件才能播放，如网页需要引入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协议。

HLS协议

HLS协议一般只用作拉流观看，但是从严格意义上讲，HLS协议并不是流式协议。

它工作原理很简单，就是通过HTTP协议下载静态文件。

不同的是，HLS协议的文件由两部分组成，一是多个只有几秒长度的.ts碎片视频文件，另一个是记录这些视频文件地址的.m3u8索引文件，且这些静态文件都是直接写入磁盘的。

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

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

 

这里补充一个HLS协议的小知识点。

由于HLS协议的视频文件、索引文件都是直接写入磁盘的 ，所以如果长时间且多个直播流同时处理，会造成磁盘写入压力过大，机械磁盘可能会磁道会损坏，固态硬盘的寿命会加速衰减。

这种情况下，最好挂载一段内存空间作为HLS相关文件的写入位置，则不会造成磁盘写入压力过大的问题。

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

 

WebRTC协议 

WebRTC协议其实并不是为了直播场景而设计的，WebRTC是一种点对点的视频/语音通话协议。

由于WebRTC是基于UDP的，建立通信后，会不断以流式发送数据，所以延迟会比RTMP还要低。

在一些交互性较高的直播场景，如直播带货等场景，会使用WebRTC作为推流和观看协议 WebRTC的延迟理论上可以达到1秒内。

WebRTC协议支持推流和拉流，地址一般是以webrtc://开头的，且推流和拉流地址一般也是一样的。

WebRTC虽然是点对点的协议，但是应用在直播场景的话，是需要搭建WebRTC服务器作为流媒体服务的，流媒体服务软件可以使用SRS。

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

RTSP协议 

RTSP一般不用作直播场景，RTSP一般用作摄像头、监控等硬件设备的实时视频流观看与推送上。

尽管RTSP协议也支持推流/拉流，且支持TCP、UDP切换以及其他诸多优点。

但是泛用性不足，特别是现在的浏览器都不支持RTSP的播放。

 

总结

以上是常用的直播协议的介绍，其中提到的延迟都是单纯的通信延迟，如果要放眼整个直播流程，延迟将会进一步放大。

因为直播延迟包括推流延迟、转码延迟、拉流延迟，即使使用WebRTC作为推流和拉流协议，最终的延迟也会有几秒的延迟。

至于直播延迟的问题，虽然以上协议起了关键作用，但是往往起不到绝对作用。

直播延迟的降低，会涉及到很多问题。如禁止B帧、GPU硬件加速、流媒体服务缓存I帧、码率限制等等细节问题，后续我们会出具体内容详细讨论。