什么是RTMP协议,RTMPT协议,RTMPS协议？
RTMP 是什么？一句话说清
RTMP 全称 Real-Time Messaging Protocol（实时消息传输协议）。它是 Adobe 为 Flash 播放器与服务器之间传输音频、视频和数据而设计的协议，建立在 TCP 之上，默认使用 1935 端口。
可以把它理解成一个"固定尺寸的数据包容器"：容器里装的既可以是 AMF 格式的控制数据，也可以是 FLV 封装的音视频数据。一个连接内部可以划分出多条通道，同时传输多路流，每条通道里的包按固定大小传送。
RTMP、RTMPT、RTMPS 有什么区别
这三个名字经常被混用，其实是"一个协议加两个变种"：
| 协议 | 全称 | 传输方式 | 特点 |
|---|---|---|---|
| RTMP | Real-Time Messaging Protocol | TCP，默认 1935 端口 | 原生形态，延迟低、开销小 |
| RTMPT | RTMP Tunneling | 把 RTMP 封装进 HTTP，走 80 端口 | 用于穿过只放行 HTTP 的防火墙 |
| RTMPS | RTMP over SSL/TLS | RTMP 加 TLS，走 443 端口 | 传输加密，安全性更高 |
简单记：RTMPT 解决"能不能连上"，RTMPS 解决"传得安不安全"。
一次推流过程中，RTMP 做了什么
以编码器推流到直播平台为例，大致经历四步：
- 握手：客户端与服务器交换基本信息，确认版本与时间基准；
- 建立连接：协商应用名与各项能力参数；
- 创建流：声明接下来要发布的流标识；
- 推流：音视频数据被打包后持续上传，平台侧再把这一路流分发给观众。
对使用者来说，需要关心的通常只有两个字段：推流地址和串流密钥——它们由直播平台生成，填进编码器的推流设置里即可。
Flash 早就退场了，为什么 RTMP 还在用
这里要纠正一个常见的过时说法。Adobe 已于 2020 年 12 月 31 日停止对 Flash Player 的支持，浏览器端不再用 Flash 播放视频，播放环节已经转向 HLS、HTTP-FLV、WebRTC 等方案。
但 RTMP 并没有随之消失，原因是它在整条链路上承担的是另一段职责：
- 推流上行（采集端 → 平台）：OBS 等主流推流软件、以及各大直播平台提供的推流地址，至今仍以 RTMP/RTMPS 为主。这一段 RTMP 依旧是事实标准。
- 播放下行（平台 → 观众）：已基本不用 RTMP，改用 HLS 或 HTTP-FLV。
所以今天讨论"要不要用 RTMP"，问的其实是推流上行这一段要不要用 RTMP——而答案通常是：要，除非你在弱网环境。
RTMP、RTMPS、SRT、RTSP 到底怎么选
这几种协议不是互相替代的关系，而是各管一段：
| 使用场景 | 推荐协议 | 原因 |
|---|---|---|
| 推流到抖音、视频号、快手等公网平台 | RTMP / RTMPS | 平台官方推流地址就是它，兼容性最好 |
| 网络质量差、丢包明显的现场（户外、移动网络） | SRT | 带丢包重传与前向纠错，弱网下更稳 |
| 对接安防摄像机、NVR、监控平台 | RTSP、ONVIF、GB28181 | 安防生态的通用接口 |
| 局域网内一路信号分发给多块屏 | UDP 组播 | 发送端只发一份，网络层负责复制，节省带宽 |
| 局域网内单点监看、低延迟预览 | RTSP / UDP 单播 | 建立简单，延迟低 |
实际项目里更常见的是组合使用：一台编码器以 UDP 组播在局域网内分发，同时以 RTMP 推到公网平台做直播。
编码器里填 RTMP 参数，容易踩的四个坑
- 地址与密钥粘错位：平台给的推流地址常写成"地址+流名称"一整串，填进编码器时要按它的字段拆分，多一个斜杠或少一个斜杠都会推不上去。
- 分辨率或码率超出平台限制：平台对分辨率、码率、关键帧间隔都有上限，超限通常表现为推流被拒或频繁中断。
- RTMPS 端口不通：RTMPS 走 443，现场防火墙若只放行了 1935，需要改回 RTMP 或单独放行。
- 先公网后本地验证：建议先用局域网内的播放器（如 VLC）拉流确认编码器本身出流正常，再去排查平台侧问题——这样能快速区分是设备问题还是平台配置问题。
常见问题
问：RTMP 的延迟大概是多少？
答：取决于平台侧的缓冲策略和编码关键帧间隔，通常是秒级。不同平台差异较大，以实测为准，不建议按固定数字预期。
问：RTMPS 和 HTTPS 是一回事吗？
答：不是。两者都用 TLS 加密，但承载的协议不同：RTMPS 传输的是 RTMP 流，HTTPS 传输的是 HTTP 请求。
问：提示推流成功，但平台显示"未收到流"，先查什么？
答：按顺序查三处——串流密钥是否完整、编码器是否有实际信号输入、平台侧该场直播是否已开始。多数情况是密钥或输入信号问题。
问：一台编码器能同时推多个平台吗？
答：多数支持多路输出的编码器可以同时向多个地址推流。需要注意上行带宽要按"路数×每路码率"预留余量。
问：RTMP 支持 H.265 编码吗？
答：RTMP 通常以 FLV 封装传输，而 FLV 对 H.265 的支持并不普遍，多数直播平台要求上行使用 H.264。若计划用 H.265 推流，务必先与平台确认是否接受，不要默认可用。
小结
RTMP 是推流上行的成熟选择：协议简单、生态完整、平台普遍支持；RTMPS 在它的基础上补上加密。若现场网络条件差，再考虑用 SRT 替代上行；局域网内的大规模分发，则交给 UDP 组播更划算。
支持 RTMP 推流的相关产品
- H.265 VGA 高清视频编码器（带本地环出）——支持 HTTP、RTSP、RTMP、RTMPS、SRT、RTP、UDP 组播、UDP 单播、FLV、HLS 等协议
- H.265 HDMI 小尺寸高清编码器——支持 RTMP、RTMPS、SRT、ONVIF、GB28181、UDP 组播/单播、HLS
- H.265 SRT 高清同编同解编解码器——支持 SRT、RTSP、RTMP、HTTP、ONVIF、UDP/Multicast
- H.265 4K 高清转码器（内嵌 RTMP 服务器）——支持 RTSP/HTTP/UDP/HTTPS/SRT 转 RTMP/RTMPS，可做组播转发
- H.264 五种输入源高清编码器——支持 RTSP、RTMP、UDP/Multicast，支持单播与组播传输
选型不确定时，可对照编码器产品页面的协议列表核对，或直接联系我们确认现场方案。
