计算机网络-流媒体协议
参考文章：
RTSP、RTMP、HLS流媒体协议的区别与联系（视觉AI相关知识必备）
概念
推流、直播、点播
- 推流：主播将本地视频源和音频源推送到腾讯视频云服务器，在有些场景中也被称为“RTMP 发布”。
- 直播：直播的视频源是实时生成的，有人推流直播才有意义，一旦主播停播，直播 URL 也就失效了，而且由于是实时直播，所以播放器在播直播视频的时候是没有进度条的。
- 点播：点播的视频源是云端的一个文件，文件只要没有被提供方删除就随时可以播放（类似腾讯视频）， 而且由于整个视频都在服务器上，所以播放的时候是有进度条的。
RTSP
Real Time Streaming Protocol，即实时流传输协议，它是由Real Networks 和 Netscape2家公司共同创立。它本身并不传输数据，传输数据的动作可以让UDP/TCP协议完成，而且RTSP可以选择基于RTP协议传输。可以用来推送又可以用来直播。
特点
RTSP对流媒体提供了诸如暂停，快进等控制，它不仅提供了对于视频流的控制还定义了流格式，如TS、 mp4 格式。通常应用于安防视频监控等场景，如公安调查监控进行视频的查看、回放、快进、后退等操作，十分友好。
最大的特点除了控制视频操作外还具有低延时的特点，通常可实现毫秒级的延时，但是也存在一些弊端，如该视频流技术实现复杂，而且对浏览器很挑剔，且flash插件播不了，这也极大的限制了它的发展。
RTMP
Real Time Messaging Protocol，即实时消息传输协议，由Adobe公司创立。RTMP主要基于TCP协议传输，主要传输 flv， f4v 格式流，最大的特点是装个插件可以在各大浏览器进行播放，播放门槛相对不高，可在手机上得到充分的应用、推广，因此比较受欢迎，目前也是视频云服务的主推流协议。此外RTMP时延也比较低，目前常用于手机直播、语音通话等场景。
核心理念
将大块的视频帧和音频帧拆分，然后以小数据包的形式在互联网上进行传输，而且支持加密，因此隐私性相对比较理想，但拆包组包的过程比较复杂，所以在海量并发时也容易出现一些不可预期的稳定性问题。
视频流协议传输的数据主要包含2部分，第一，基本单元为Message（消息），第二，最小单元是Chunk（消息块），发送端会把需要传输的媒体数据封装成消息，然后把消息拆分成消息块，每一个消息具有特定的id号，后面将根据这个id号，将一个个零散的Chunk（消息块）又重新拼接成消息
特点
既可以推送也可以直播
FLV
FLV 协议由 Adobe 公司主推，格式极其简单，只是在大块的视频帧和音视频头部加入一些标记头信息，由于这种简洁，在延迟表现和大规模并发方面都很成熟，唯一的不足就是在手机浏览器上的支持非常有限，但是用作手机端 App 直播协议却异常合适。
HLS
苹果推出的解决方案，将视频分成5秒 - 10秒的视频小分片，然后用 m3u8 索引表进行管理，由于客户端下载到的视频都是5秒 - 10秒的完整数据，故视频的流畅性很好，但也同样引入了很大的延迟（HLS 的一般延迟在10秒 - 30秒左右）。相比于 FLV， HLS 在 iPhone 和大部分 Android 手机浏览器上的支持非常给力。
WebRTC
网页即时通信（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年06月01日开源并在 Google、Mozilla、Opera 支持下被纳入万维网联盟的 W3C 推荐标准。快直播正是用的 WebRTC 协议，它是标准直播在超低延迟播放场景下的延伸，比传统直播协议延迟更低，为观众提供毫秒级的极致直播观看体验。 能够满足一些对延迟性能要求更高的特定场景需求，例如在线教育、体育赛事直播、在线答题等。
总结
| 直播协议 | 优点 | 缺点 | 播放延迟 |
|---|---|---|---|
| FLV | 成熟度高、高并发无压力 | 需集成 SDK 才能播放 | 2s - 3s |
| RTMP | 延迟较低 | 高并发情况下表现不佳 | 1s - 3s |
| HLS(m3u8) | 手机浏览器支持度高 | 延迟非常高 | 10s - 30s |
| WebRTC | 延迟最低 | 需集成 SDK 才能播放 | < 1s |
播放前缀
- RTMP 播放协议：rtmp:// 。
- HTTP-FLV 播放协议：http:// 或者 https:// 。
- HLS 播放协议：http:// 或者 https:// 。
- WebRTC 播放协议：**webrtc://**。