传统音视频传输协议
RTP(Real-time Transport Protocol)
RTP（Real-time Transport Protocol，实时传输协议）是一种在实时应用程序中传输多媒体数据的网络协议。
协议类型
传输层协议
RTP、TCP、UDP都属于传输层协议; RTP也可以认为是介于应用层与传输层之间（5层模型）。
从图中可以看出，RTP被划分在传输层，它建立在UDP上。同UDP协议一样，为了实现其实时传输功能，RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步，但并不保证服务质量。服务质量由RTCP来提供。
不少人也把RTP归为应用层的一部分，这是从应用开发者的角度来说的。操作系统中的TCP/IP等协议栈所提供的是我们最常用的服务，而RTP的实现还是要靠开发者自己。因此从开发的角度来说，RTP的实现和应用层协议的实现没不同，所以可将RTP看成应用层协议。
帧格式
| 字段 | 位数 | 说明 |
|---|---|---|
| Version (V) | 2 | 表示RTP的版本。当前版本是2。 |
| Padding (P) | 1 | 如果需要填充，则设置此位。 |
| Extension (X) | 1 | 如果使用了扩展头，则设置此位。 |
| CSRC Count (CC) | 4 | 表示后续CSRC标识符的数量。 |
| Marker (M) | 1 | 通常用于标记帧的边界。 |
| Payload Type (PT) | 7 | 指示负载的类型（例如，音频或视频编码）。 |
| Sequence Number | 16 | 用于检测丢包和排序。 |
| Timestamp | 32 | 表示数据生成的时间戳。 |
| SSRC | 32 | 标识同步源的唯一标识符。 |
| CSRC | 0-15 | 0到15个32位字段，用于标识贡献源。 |
| Header Extension (可选) | 可变 | 如果X位被设置，可能包含额外的头部扩展。 |
| Payload | 可变 | 实际的数据部分，可能包含音频、视频或其他媒体数据。 |
| Padding | 可变 | 可选填充，以确保帧的字节对齐。 |
应用场景
- 视频会议：在视频会议应用中，RTP 用于传输实时音视频数据，并确保顺序和时间同步。
- 网络电话 (VoIP)：RTP 负责传输语音数据，并与 SIP（Session Initiation Protocol）等协议配合使用。
- 实时流媒体：RTP 在实时流媒体应用中，用于传输音视频内容，并支持对传输质量的监控。
其他问题
为何光有 UDP 不够，还需要 RTP
传输媒体流对网络的要求：IP 网络的不可预知性，数据包可能存在丢失、错序等问题
因此，接收端需要能正确还原音频或视频信号，需要：
- 检测出错序，并保持采样和播放之间的同步关系（解决方案：时间戳）
- 需要在接收端能够检测出分组丢失（解决方案：序列号）
那就只有用 RTP 了，UDP 没这功能
RTCP(Real-time Transport Control Protocol)
传输协议
RTCP为RTP提供流量控制和拥塞控制。在RTP会话期间,各参与者周期性地传送RTCP包。
RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料.因此,服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。
RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化。因而特别适合传送网上的实时数据。
RTSP（Real-time Streaming Protocol）
协议类型
应用层协议
RTSP在体系结构上位于应用层，在RTP和RTCP之上, 它使用TCP或RTP完成数据传输。
工作机制
当应用程序提供RTSP协议建立一个RTP会话时，应用程序将确定一对目的传输地址（一个网络地址和两个端口号），其中两个端口号中的偶数端口是分配给RTP进行裸码流数据传输的，奇数端口则是分配给RTCP进行传输控制的。
RTP的发送过程如下：
- 从上层接收流媒体信息码流（如H.264），封装成RTP数据包；RTCP从上层接收控制信息，封装成RTCP控制包。
- 将RTP 数据包发往UDP端口对中偶数端口；RTCP将RTCP控制包发往UDP端口对中的接收端口。
应用场景
- 实时流媒体应用：
RTSP被广泛用于实时流媒体应用，包括在线广播、网络摄像头、监控摄像头、IPTV、视频会议、VoIP等。这些应用需要灵活控制流媒体会话，例如播放、暂停、停止、快进、快退等。 - 网络摄像头和监控系统（安防领域）：
RTSP在网络摄像头和监控系统中应用广泛。它允许客户端在需要时连接到摄像头，开始流媒体传输，实时查看视频监控，并可以在不同时间点暂停或停止传输。 - IPTV（互联网电视）：
RTSP在IPTV中用于控制和传输电视流。用户可以通过RTSP控制收看特定的频道、录制节目、调节播放参数等。RTSP的灵活性使其能够处理按需点播和直播内容。 - 多媒体内容点播：
在多媒体内容点播服务中，RTSP用于提供类似VCR的功能，包括快进、快退、跳转到特定位置等。它支持按需内容流传输和控制。 - 视频会议：
RTSP可以用于视频会议系统，提供会议中音频和视频流的控制。它允许用户加入会议、离开会议、调整传输参数等。 - 远程教育和在线学习：
RTSP在远程教育和在线学习环境中用于实时流媒体传输，帮助教师和学生进行互动。它可以用于播放课程视频、实时课堂、教学演示等。 - 企业内网广播：
企业可以使用RTSP进行内部广播，例如公司公告、培训课程、员工会议等。RTSP的灵活控制能力使其适用于内部流媒体传输。
其他问题
RTSP有握手过程吗？
RTSP（Real-Time Streaming Protocol，实时流媒体传输协议）没有传统意义上的握手过程，如TCP的三次握手或类似于RTMP的握手机制。RTSP主要用于控制多媒体流的传输，提供了类似于HTTP的客户端-服务器交互机制，允许客户端发出控制命令来启动、停止或操纵媒体流。
尽管没有典型的握手过程，但RTSP的会话控制过程中涉及建立和维护会话，这包括发送初始请求（如SETUP）来创建一个会话，并使用会话标识符（Session ID）来跟踪会话状态。这一过程类似于HTTP的请求-响应模式，以下是一些常见的RTSP请求：
- OPTIONS：用于查询服务器支持的RTSP方法。
- DESCRIBE：请求流媒体描述信息（如SDP，Session Description Protocol）。
- SETUP：请求在特定的传输通道（如RTP/UDP）上建立会话。
- PLAY：启动媒体流的播放。
- PAUSE：暂停媒体流的播放。
- TEARDOWN：结束会话，释放资源。
在这个过程中，RTSP会通过Session ID来维持会话的状态和唯一性，而不是通过类似握手的同步机制。RTSP的会话是无状态的，这意味着每个请求需要携带足够的上下文信息，以便服务器能够理解客户端的意图。
RTMP
协议类型
应用层协议
工作机制
RTMP协议规定，播放一个流媒体有两个前提步骤：
- 建立一个网络连接（NetConnection）；
- 建立一个网络流（NetStream）。
其中，网络连接代表服务器端应用程序和客户端之间基础的连通关系。网络流代表了发送多媒体数据的通道。服务器和客户端之间只能建立一个网络连接，但是基于该连接可以创建很多网络流。
播放一个RTMP协议的流媒体需要经过以下几个步骤：握手，建立连接，建立流，播放。RTMP连接都是以握手作为开始的。建立连接阶段用于建立客户端与服务器之间的“网络连接”；建立流阶段用于建立客户端与服务器之间的“网络流”；播放阶段用于传输视音频数据。
握手过程：
- 客户端握手 C0：
客户端发送 C0 消息，它包含协议版本（通常是 3）。 - 服务器响应 S0：
服务器接收 C0 后，发送 S0 消息，包含协议版本，通常与客户端的协议版本相同。 - 客户端握手 C1：
客户端发送 C1 消息，包含一个 1536 字节的随机数据和一个 4 字节的时间戳。这段随机数据用于后续的握手验证。 - 服务器响应 S1：
服务器接收 C1 后，发送 S1 消息。该消息也包含 1536 字节的随机数据和一个 4 字节的时间戳。服务器的随机数据是不同于客户端的，用于确保握手的随机性。 - 客户端握手 C2：
客户端发送 C2 消息，它包含 1536 字节的数据，这是之前服务器 S1 消息中的随机数据。通过这种方式，客户端表明它收到了服务器的响应，并且验证了握手的一致性。 - 服务器确认 S2：
服务器接收 C2 后，发送 S2 消息，该消息包含 1536 字节的数据，与客户端 C1 消息中的随机数据相同。通过这种方式，服务器验证了客户端的响应。
应用场景
- 直播流媒体：
RTMP 是一种流行的流媒体协议，广泛用于直播视频、音频流和实时聊天应用程序。其低延迟特性使其成为直播场景的热门选择，尤其是网络视频平台和直播节目。 - 实时互动：
由于 RTMP 的低延迟和可靠性，它在实时互动应用中被广泛使用，如在线游戏直播、视频通话、在线教学和网络研讨会。 - 内容分发网络 (CDN)：
RTMP 是许多内容分发网络用来在服务器之间传输实时流媒体的协议。CDN 使用 RTMP 将直播流分发到边缘节点，并通过其他协议（如 HLS 或 DASH）向客户端分发内容。 - 广播行业：
在广播行业，RTMP 仍然是流行的协议，用于将现场视频源传输到中央服务器，然后广播或流式传输给观众。 - 媒体制作与管理：
RTMP 通常用于将实时流媒体从摄像机或媒体制作工作站发送到视频制作软件和平台。这使得现场拍摄和实时编辑成为可能。 - 在线教育和网络研讨会：
RTMP 被用于实时传输视频和音频流，用于在线教育和网络研讨会。它的低延迟特性使其适合这种需要即时互动的场景。 - 社交媒体直播：
一些社交媒体平台支持 RTMP 协议，允许用户使用直播软件或硬件进行实时直播。
其他问题
HTTP-FLV (HTTP-Flash Video)
协议类型
应用层协议
基于HTTP协议
工作机制
HTTP 协议中有个约定：content-length字段，http 的 body 部分的长度。
- 服务器回复 http 请求的时候如果有这个字段，客户端就接收这个长度的数据然后就认为数据传输完成了。
- 如果服务器回复 http 请求中没有这个字段，客户端就一直接收数据，直到服务器跟客户端的 socket 连接断开。 (流式传输)
http-flv 直播就是利用第二个原理，服务器回复客户端请求的时候不加 content-length 字段，在回复了 http 内容之后，紧接着发送 flv 数据，客户端就一直接收数据了。
应用场景
网络直播：
HTTP-FLV 适合实时网络直播，因为它可以在客户端与服务器之间保持持续的连接，并即时传输数据。这种机制有助于减少延迟，实现实时直播。视频点播：
HTTP-FLV 也可以用于点播内容的播放。通过 HTTP 的灵活性，服务器可以根据客户端的需求提供流媒体数据。Web 视频播放：
HTTP-FLV 的兼容性使其适用于 Web 上的嵌入式视频播放，特别是在 Flash 时代流行的各种嵌入式视频播放器。
其他问题
HLS (HTTP Live Streaming)
HLS 是一种基于 HTTP 的流媒体传输协议，最初由苹果公司开发，现在是流媒体领域的一个广泛采用的协议。下面是对 HLS 协议的详解，包括其类型、工作机制、应用场景和其他常见问题。
协议类型
应用层协议
基于HTTP协议
工作机制
HLS 的核心机制是将音视频内容分段，然后通过 HTTP 请求进行传输和播放。其工作流程大致如下：
- 内容分段：
源视频文件或直播流被切割成较小的段（segments），每个段通常几秒钟长，通常为 10 秒。 - 创建索引文件：
同时，生成一个索引文件（或称为清单文件、播放列表），通常是 .m3u8 文件。这个索引文件列出所有视频段的 URL，以及其他元数据，如时间戳、码率、分辨率等。 - 客户端播放：
客户端（通常是视频播放器或媒体播放软件）首先请求索引文件，然后根据索引文件中的信息，按顺序请求视频段，并进行播放。 - 可自适应的质量：
HLS 支持多种比特率和分辨率的视频段，客户端可以根据网络状况选择最佳的段以实现自适应流媒体（Adaptive Bitrate Streaming）。这种特性使 HLS 在不同带宽下都能保持较好的播放体验。 - 缓存和 CDN 支持：
由于 HLS 基于 HTTP 协议，网络基础设施中的缓存和 CDN（内容分发网络）可以有效地支持 HLS，从而提高流媒体传输的效率和可靠性。
应用场景
- 直播和广播：
HLS 被广泛用于直播活动、赛事转播等。 - 点播和回放：
HLS 也可用于点播内容或流媒体服务中的内容回放。 - 多平台兼容性：
由于 HLS 的 HTTP 基础，它在各种平台和设备上都可以使用，特别是在苹果生态系统中广泛支持。
其他问题
几种传统协议的不同点
HTTP将所有的数据作为文件做处理。http协议不是流媒体协议。
RTMP和RTSP协议是流媒体协议。
RTMP协议是Adobe的私有协议,未完全公开，RTSP协议和HTTP协议是共有协议，并有专门机构做维护。
RTMP协议一般传输的是flv，f4v格式流，RTSP协议一般传输的是ts, h264, h265, mp4格式的流,HTTP没有特定的流。
RTSP传输一般需要2-3个通道，命令和数据通道分离，HTTP和RTMP一般在TCP一个通道上传输命令和数据。RTSP实时流协议 作为一个应用层协议，RTSP提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来，RTSP是一个流媒体表示协议，主要用来控制具有实时特性的数据发送，但它本身并不传输数据，而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与RTP间的交互操作（RFC2326）。
新兴流媒体协议
基于浏览器插件的老牌直播协议RTMP终于寿钟正寝，虽然各大CDN厂商还在坚持使用RTMP协议，但是也难逃被各大浏览器厂商淘汰的趋势和事实；RTSP主要应用于安防领域，而随之兴起流行的HTTP-FLV、HLS直播技术也因为延迟大，平台依赖性强，网络自适应差等问题饱受诟病。
而新兴的WEBRTC协议是专门基于网页js设计的即时音视频通信协议，其无插件的直播性能完全能满足流媒体直播的要求，而新兴的互联网90%的浏览流量都在浏览器上，所以WEBRTC是目前互联网直播协议中一种比较优质是选择。
GB28181
见 GB28181 专栏
WebRTC
见 WebRTC 专栏
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 1430797759@qq.com