常见流媒体协议介绍

技术帖 , , 评论

本文 主要整理自 https://zhuanlan.zhihu.com/p/496823042

前置

整理下常见 流媒体协议 RTP、RTSP、RTMP、HLS、FLV、SRT、WebRTC

一图胜千言，但是注意，图中 的 MP4/FLV指的是 http-flv 和 http-mp4。 这里说的还是流媒体协议，不是封装格式。

network_architecture.jpg

从上面我们知道：

  • 基于 UDP 的 流媒体协议 有 RTP、RTCP
  • 基于 TCP 的 流媒体协议 有 RTSP、RTMP、HTTP、HLS、http-flv、http-mp4

HLS、http-flv、http-mp4 本身就是基于 http协议的。 后面会说到

从网络协议说起

但是说流媒体协议就绕不开网络协议。我们要建立网络分层模型的概念，所有流媒体协议都有归属的层级，这个是理解、区分协议的基础。

network_architecture.jpg

流媒体协议需要根据目标场景，选择TCP/UDP，再进行应用层协议开发，这里就出现第一个概念，如何选择TCP/UDP？

TCP和UDP特点

TCP 传输的特点：面向连接，保序，可靠

  • TCP的协议栈完成了拥塞控制，流量控制，乱序重排，丢包重传等工作。
  • 保证数据是有序可靠的。
  • 适合强调数据完整性 的场景：如:文件下载，网页浏览，信令传输。

UDP 传输特点：面向无连接，不保序，不可靠连接

  • UDP协议 面向无连接，只是简单向对方发送数据，哪怕对方不存在。
  • 协议简单，所以传输效率高，实时高、延迟低。
  • 适合强调实时性高的场景。如: 音视频传输，游戏等。

关于组播与广播，单播

TCP 面向连接，一定是点对点的，一定是两个主机来建立连接的，TCP肯定是单播。
只有UDP才会使用广播和组播
一个主机要向网上的所有其它主机发送帧，这就是广播，
多播（组播）属于单播和广播之间，帧仅传送给属于多播组的多个主机。
在广播电视领域为了减少服务器压力，通常使用组播跟用户推流。如: IPTV，通常机顶盒通过光猫加入某个组播地址，接收 某个CDN的组播流。

从流媒体角度看
  • TCP自身的拥塞控制机制、传输数据延时大，队头阻塞等问题，音视频的 实时传输 造成一定的困扰。
  • UDP自身设计原因，公网传输丢包、乱序等极端情况，会导致客户端无法解码。

所以对于流媒体传输，需要对运输层TCP/UDP协议进行高层次的开发，以适应流媒体传输时的应用需求。

常见流媒体协议

RTP 实时传输协议 与 RTCP

RTP (Real-time Transport Protocol) 和RTCP(Real-time Transport Control Protocol) 都是 传输层协议
RTCP是RTP的控制部分,通常一起配合使用

应用程序启动一个RTP会话时，将占用两个端口，分别供RTP和RTCP使用

  • RTP 使用 偶数端口号 收发数据,负责数据传输
    • 通常创建在UDP上，但也能够在TCP或ATM等其余协议之上工作
    • 基于UDP时，和UDP一样，并不提供任何传输可靠性的保证和流量的拥塞控制机制，无法保证实时性
    • RTP 在 UDP 基础上增加了 Header 头，包含 CSRC标识、时间戳、序列号等信息（用于配合完成 按序传输数据包提供可靠的保证）。
  • RTCP 使用 相邻的下一位奇数端口号,负责管理传输质量。
    • 负责 收集相关连接信息，实时监控数据传输和服务质量(控制辅助)
    • RTCP来负责 完成 RTP 按序传输数据包提供可靠的保证，流量控制和拥塞控制
    • 在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送包的数量、丢失包的数量等统计信息。服务器利用这些信息动态地改变传输速率，甚至改变有效载荷类型。

network_architecture.jpg

RTSP 实时流协议

  • 比RTP多了一个S的RTSP是RealTime Streaming Potocol 实时流协议。
  • 基于RTP和RTCP之上的应用层协议。可选择UDP、组播UDP、TCP、RTP为传输机制。
  • 双向实时数据传输协议，它允许客户端向服务器端发送请求, 进行 回放、快进、倒退等操作
  • 充当多媒体服务器的网络远程控制，使实时数据的远程控制成为可能。 比如，音频与视频的快进快退、中止、播放。
  • 一般用作摄像头、监控等硬件设备的实时视频流观看与推送上
  • 泛用性不足，现在的 浏览器都不支持RTSP的播放

network_architecture.jpg

RSVP (Resource Reserve Protocol)资源预订协议

  • 主要作用: 预留带宽,提升QoS(服务质量)
  • 音频和视频数据流比传统数据对网络的延时更敏感，要在网络中传输高质量的音频、视频信息，除带宽要求以外，还需其余更多的条件。
  • 使用RSVP预留一部分网络资源，能在一定程度上为流媒体的传输提供QoS保障。

network_architecture.jpg

RTP\RTCP\RTSP小结

  1. RTP提供时间标志，序列号以及其余可以保证在实时数据传输时处理时间的方法。
  2. RTCP是RTP的控制部分，用来保证服务质量和成员管理。
  3. RTSP具体数据传输交给RTP,提供对流的远程控制。
  4. RSVP预留带宽,提升QoS。

RTMP（Real Time Messaging Protocol）实时消息传输协议

  • Adobe公司为Flash播放器和服务器之间开发的音视频数据传输的开放协议
  • 传输flv或f4v封装格式 的 媒体流。
  • 基于TCP协议，使用端口1935，能够保持长连接*，并提供低延时**(1-3秒)通信。【通常占用一个通道传输数据和指令，就能保证传输质量】
  • RTMP是目前低延时直播应用最普遍的协议，几乎全部编码器标准输出协议（H.265 不支持）
  • 全部CDN支持的最好的直播分发协议
  • 实际直播场景中： 由于浏览器摒弃了Flash播放器，所以一般只用作直播源推流、推流到直播CDN等场景。

缺点

  • 协议太老: HEVC/H.265/AV1等视频格式都没有官方定义
  • 连接过程较长，需要 TCP三次握手 和 本身的C0/S0到C2/S2的三次握手，再加上 建立连接 > 建立流 > 播放, 完成一次建连9次会话
  • 无法提供带宽自适应的算法: 拥塞控制完全依赖传输层TCP的拥塞控制算法来进行拥塞管理

因为RTMP是基于TCP之上的，所以也存在三次握手的要求，
另外RTMP还增加了C0/S0到C2/S2的三次握手。
播放RTMP协议的流媒体需要经过：握手 > 建立连接 > 建立流 > 播放 [connection，createstream，play/publish]。

RTMP包括: RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种

  • RTMPT： 封装在HTTP请求之上，可穿透防火墙；
  • RTMPS： 在RTMPT基础上 增加了TLS/SSL的安全功能；
  • RTMPE： 在RTMP的基础上 增加了加密功能。

落地

需要流媒体服务软件

RTMP协议需要特定的流媒体服务软件，如SRS、加入了RTMP插件的Nginx等。此类流媒体服务软件实际上就是音视频数据的中转站，数据一般只在内存中循环覆盖，不会写入磁盘。

强制切片机制

RTMP，在封装音视频数据时会强制切片，限制每个数据包的大小。
强制切片也一定程度保证了实时性。
有一定的弱网抵抗能力，因为数据包都不大，当失败时，重新成本小，但也 由于合并数据包会加大CPU压力，所以是有一定的性能消耗的。

HTTP-FLV

  • 可以简单地理解为HTTP协议版本的RTMP
  • HTTP-FLV 与 RTMP基本一样，都是建立在FLV封装之上的。
  • 功能和工作原理上是相似,也有 类似 RTMP切片数据功能
  • 注意: HTTP-FLV 虽然是基于HTTP协议的，但是 是长链接

不同点

  • RTMP一般用作直播源推流
  • HTTP-FLV一般用作直播拉流观看(相对略高于RTMP)；

优点在于: 在浏览器中 借助 flvjs 可以在浏览器中实现播放。

落地

HTTP-FLV协议 同样需要特定的流媒体服务软件，如加入了HTTP-FLV插件的Nginx等。

Nginx的HTTP-FLV插件是包含 RTMP功能的，所以一般HTTP-FLV的流媒体服务，推流是以RTMP协议，拉流是用HTTP-FLV协议。

HLS（HTTP Live Streaming）

  • 由Apple公司提出的基于短连接HTTP的媒体流传输协议
  • 严格意义上讲，HLS协议并不是流式协议: 本质是 通过HTTP协议下载静态文件
  • 网络兼容好： 基于HTTP协议，能方便穿透防火墙或代理服务器，CDN支持良好
  • 平台播放兼容好： ios 安卓都支持，PC web safari 都支持, 其他浏览器 可以使用 hls.js 播放

HLS协议实现播放的过程

  • HLS协议 包含.m3u8索引文件 和 多个很短的.ts媒体文件。
  • 客户端获取到索引文件后，通过http请求获取到.ts文件，下载到本地磁盘，再根据索引顺序播放。
一个 m3u8文件的内容如下

m3u8示例

1
2
3
4
5
6
7
8
9
10
11
12
13
#EXTM3U # 每个M3U8文件第一行必须是这个tag。
#EXT-X-VERSION:3 # 表示 HLS 的协议版本号，该标签与流媒体的兼容性相关
#EXT-X-MEDIA-SEQUENCE:0 # 表示播放列表第一个 URL 片段文件的序列号。
#EXT-X-ALLOW-CACHE:YES
#EXT-X-TARGETDURATION:6 # 表示每个视频分段最大的时长（单位秒）
#EXTINF:3.000 #表示其后 URL 指定的媒体片段时长（单位为秒）
alilive-E_2_3-1507867721-471441600-1920x1080-1165-3000.ts # 表示媒体片段的 URL
#EXTINF:3.000
alilive-E_2_3-1507867721-471711600-1920x1080-1165-3000.ts
#EXTINF:3.000
alilive-E_2_3-1507867721-471981600-1920x1080-1165-3000.ts
#EXTINF:3.000
alilive-E_2_3-1507867721-472251600-1920x1080-1165-3000.ts

此外 HLS协议的.m3u8索引文件支持二级索引，就是高清、标清、流畅等多个观看地址可以整合到一个索引文件
m3u8 文件格式详解

与HLS协议类似的还有MPEG-DASH协议工作原理都是差不多的，只是局部标准不一样

缺点

  • 延时较高：因为使用HTTP短连接，不断的与server建立连接，TCP的三次握手，四次挥手，交互耗时长。难以用到时延要求更严格的直播场景。
  • 海量碎片：HLS切片一般较小，海量碎片在文件分发、一致性缓存都有较大挑战。

落地-点播

不需要特殊的流媒体服务软件，使用Nginx等HTTP服务就可以了

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

落地-直播

  • 转码软件可以直接生成HLS相关文件到磁盘，客户端 通过HTTP服务下载文件即可。
  • 在Nginx加入RTMP插件，转码软件以RTMP协议推流到Nginx，再由Nginx生成HLS相关文件。推荐：前期研发 和 后期对接直播CDN的过度更加顺滑。

http-mp4

  • 是一种 HTTP 伪流媒体,其实不算是流媒体协议，而是基于HTTP协议的点播协议。
  • 本质是需要 特殊的MP4-fMP4 格式的文件，通过HTTP协议下载到进行播放，只是客户端可以边下边播。
  • 这点 通常用于 网站的 视频播放的优化。

实现的条件

  1. 必须将 moov 放在 mdat 前面。可以通过 ffmpeg 指定参数 -movflags faststart 进行移动。
  2. HTTP 请求返回的 Content-Type 必须是 video/mp4 。
  3. 服务器必须支持 HTTP 1.1 的 Range 。
  4. 确保服务器没有对 MP4 文件进行 gzip 压缩，不然怎么读取 moov 啊。

使用HTTP流播放MP4
Nginx 中实现 MP4 视频的边下边播

特殊的MP4-fMP4

MP4 的基本组成单位是 box

box类型有很多
  • ftyp：File Type Box，描述文件遵从的MP4规范与版本；
  • moov：Movie Box，媒体的metadata信息（包含的 trak 记录着视频播放数据的时间和空间信息），有且仅有一个。
  • mdat：Media Data Box，存放实际的媒体数据(保存着视频音频信息)，一般有多个；

播放MP4的过程：

  • 播放器在播放MP4 的时候，需要先读取metadata，然后再读取媒体数据。才可以播放
  • 视频的拖动，快进，都是需要根据 moov metadata 和拖动至的时间。
  • 但是 MP4文件，不一定 moov 就在文件开头，也有可能在文件末尾。
  • 本地MP4文件，可以快速读取整个文件，找到metadata后，开始播放，
  • 但是 网络上的MP4文件 如果开头找不到 moov metadata ，就只能等下载完毕，才能播放。

要实现 网络上的MP4文件边下边播，就需要将moov metadata 放在文件开头。

使用HTTP流播放MP4

WebRTC（Web Real-Time Communication）

WebRTC是网页 实时通信

  • 一个支持网页浏览器 进行实时语音对话或视频对话的技术而无需任何插件。
  • 兼容性好： WebRTC已经不仅仅局限于PC的网页浏览器，Android、iOS平台上很多应用都已经采用了这样技术。
  • 使用是RTP分装码流，建立通信后，会不断以流式发送数据，所以延迟会比RTMP还要低。可以达到1秒内
  • WebRTC协议 支持 推流 和 拉流，地址一般是以 webrtc://开头的，且 推流和拉流地址一般也是一样的。
  • 应用在直播场景的话，是需要搭建 WebRTC服务器作为 流媒体服务的，流媒体服务软件可以使用SRS。

SRS是国内研发的一个比较流行的开源流媒体服务软件:
https://ossrs.io
https://ossrs.net
https://github.com/ossrs/srs

WebRTC跟视频监控，IPTV，会议电视一样都是RTP承载媒体流，
WebRTC的码流采用SRTP进行加密，WebRTC优先使用VP9、VP8、H.264，不支持H.265。
WebRTC信令遵守ICE框架，使用 自定义信令

IPTV领域 使用RTSP信令
视频监控走GB28181或者onvif信令，
会议电视走h323或SIP协议。

SRT

UDT协议

  • 基于UDP的传输协议，具有非常良好的丢包重传机制，丢包重传的控制消息非常丰富，同时支持ACK、ACKACK、NACK。
  • 引入新的拥塞控制和数据可靠性控制机制
  • 是面向连接的双向的应用层协议

SRT是基于UDT的协议,针对音视频实时性提出的协议。
SRT拥有三大特点，安全，可靠，低延迟。

  • 安全方面，SRT支持AES加密，保障端到端的视频传输安全。
  • 可靠性方面，SRT通过前向纠正技术(FEC)保证传输的稳定性。
  • 低延迟方面，由于SRT建立在UDT协议之上，解决了UDT协议传输延迟高和复杂的传输时序问题，可以做到支持高吞吐量文件和超清视频的实时传输。

network_architecture.jpg

SRT协议具有抗丢包、抗拥塞、抗抖动等特性
SRT基于时间的报文发送，使其具有良好的防止流量突发的能力。
音视频流经过网络传输，帧间隔和码率特性会被完全改变，解码这样的信号容易出现故障。
而SRT增加了纠错协议，在封装中包含精准的时间戳，解码接收端可以通过该时间戳重现固定的帧间隔。
还能通过规定延时量，同时划定send buffer（发送端缓冲区）与receive buffer（接收端缓冲区），来自接收端的反馈信号（可以理解为后向纠错）通过一系列的设置、纠错、流量控制，使编码后的视音频码流拥有与原码流几乎一样的码率特性。

推荐阅读：
流媒体传输协议浅析
HLS、FLV、RTMP三种协议快速对比
直播协议详解 RTMP、HLS、HTTP-FLV、WebRTC、RTSP
直播原理解析

mcdowellWeb 前端 & 90后

一线前端从业人员。