直播协议的选择：RTMP vs. HLS

文章转自：直播协议的选择：RTMP vs. HLS

前言

随着直播业务的兴起，愈来愈多的直播平台开始涌现，这火热的程度好像一个应用不带上直播业务出来都很差意思跟人打招呼。想要作一个直播业务，主要包括三个部分：采集推流端、流媒体服务端、播放端。这里很少说，就主要结合 iOS 平台，从观看端出发，介绍一下对直播协议的选择。

一般在 iOS 平台作直播业务，会有两种协议可供选择：HLS 和 RMTP。

• HLS，是苹果公司实现的基于 HTTP 的流媒体传输协议，全称 HTTP Live Streaming，可支持流媒体的直播和点播，主要应用在 iOS 系统，为 iOS 设备（如 iPhone、iPad）提供音视频直播和点播方案。
• RTMP，实时消息传输协议，Real Time Messaging Protocol，是 Adobe Systems 公司为 Flash 播放器和服务器之间音频、视频和数据传输开发的开放协议。协议基于 TCP，是一个协议族，包括 RTMP 基本协议及 RTMPT/RTMPS/RTMPE 等多种变种。RTMP 是一种设计用来进行实时数据通讯的网络协议，主要用来在 Flash/AIR 平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通讯。

上面是这两种协议的简介，那它们在实际应用中会有什么差别呢？

HLS

先说说 HLS。HLS 的基本原理就是当采集推流端将视频流推送到流媒体服务器时，服务器将收到的流信息每缓存一段时间就封包成一个新的 ts 文件，同时服务器会创建一个 m3u8 的索引文件来维护最新几个 ts 片断的索引。当播放端获取直播时，它是从 m3u8 索引文件获取最新的 ts 视频文件片断来播放，从而保证用户在任什么时候候链接进来时都会看到较新的内容，实现近似直播的体验。相对于常见的流媒体直播协议，例如 RTMP 协议、RTSP 协议等，HLS 最大的不一样在于直播客户端获取到的并非一个完整的数据流，而是连续的、短时长的媒体文件，客户端不断的下载并播放这些小文件。这种方式的理论最小延时为一个 ts 文件的时长，通常状况为 2-3 个 ts 文件的时长。HLS 的分段策略，基本上推荐是 10 秒一个分片，这就看出了 HLS 的缺点：

• 一般 HLS 直播延时会达到 20-30s，而高延时对于须要实时互动体验的直播来讲是不可接受的。
• HLS 基于短链接 HTTP，HTTP 是基于 TCP 的，这就意味着 HLS 须要不断地与服务器创建链接，TCP 每次创建链接时的三次握手、慢启动过程、断开链接时的四次挥手都会产生消耗。

不过 HLS 也有它的优势：

• 数据经过 HTTP 协议传输，因此采用 HLS 时不用考虑防火墙或者代理的问题。
• 使用短时长的分片文件来播放，客户端能够平滑的切换码率，以适应不一样带宽条件下的播放。
• HLS 是苹果推出的流媒体协议，在 iOS 平台上能够得到自然的支持，采用系统提供的 AVPlayer 就能直接播放，不用本身开发播放器。

RTMP

相对于 HLS 来讲，采用 RTMP 协议时，从采集推流端到流媒体服务器再到播放端是一条数据流，所以在服务器不会有落地文件。这样 RTMP 相对来讲就有这些优势：

• 延时较小，一般为 1-3s。
• 基于 TCP 长链接，不须要屡次建连。

所以业界大部分直播业务都会选择用 RTMP 做为流媒体协议。一般会将数据流封装成 FLV 经过 HTTP 提供出去。可是这样也有一些问题须要解决：

• iOS 平台没有提供原生支持 RTMP 或 HTTP-FLV 的播放器，这就须要开发支持相关协议的播放器。