RTMP / RTMPT / RTMPS 是什么？现在还该不该用

一句话区分三个名字

名称	本质	当前用途
RTMP	Real-Time Messaging Protocol，Adobe 为 Flash 播放器与服务器之间传输音视频和数据开发的协议，建立在 TCP 之上	推流（编码器 → 服务器），仍是主流
RTMPT	RTMP 用 HTTP 封装的变体，用于穿越防火墙	历史产物，现已基本不用
RTMPS	经 SSL/TLS 加密的 RTMP，相当于 RTMP over TLS	对推流链路有加密要求时用

RTMP 到底在做什么

RTMP 像一个用来装数据的容器：里面可以是 AMF 格式的控制数据，也可以是 FLV 中的音视频数据。它在一条连接上通过不同通道传输多路网络流，包按固定大小分片传输。

早期它的典型用途是"视频点播 + 直播"两端都走 RTMP：服务端装 FMS，客户端用 Flash 播放器。今天这个结构只剩一半还成立。

Flash 停用后，RTMP 为什么还在用

现在一套典型直播链路是这样的分层：

• 第一段（推流）：编码器 → 服务器，走 RTMP 或 SRT。这一段要求低延时、稳定、兼容性好。
• 第二段（分发）：服务器 → 观众，走 HLS、DASH 或 HTTP-FLV。这一段走 HTTP，能穿透 CDN 和各种网络环境。

所以"RTMP 过时了"这个说法只对了一半：作为播放协议它确实已经退出，作为推流协议它仍是事实标准。

三个变体的实际差别

• RTMP：明文传输，默认端口 1935。配置最简单，兼容性最好。
• RTMPT：把 RTMP 包在 HTTP 里以便穿越只开放 80 端口的防火墙，代价是额外开销和更高延时。随着防火墙普遍放行 1935、以及 HTTPS 隧道方案成熟，它已基本退出实际使用。
• RTMPS：在 RTMP 上加 TLS 加密，安全性明显更高，适合跨公网、对内容传输有保密要求的场景。代价是握手与加解密带来少量开销，且需服务端支持。

顺带一提源站旧文里提到的一个优势——"RTMP 是直接在服务器上交互、不像 HTTP 那样本地缓存"——这个说法在防盗链意义上曾经成立，但今天防下载更多依赖鉴权、Token 与 DRM，不建议把它当选型依据。

什么时候该用 RTMP，什么时候不该

场景	建议	原因
推到云直播平台、CDN	✅ RTMP	支持面最广，平台文档默认方案
局域网内稳定专线	✅ RTMP	链路质量好，无需额外抗丢包机制
跨公网、丢包或抖动明显	❌ 改用 SRT	RTMP 基于 TCP，丢包时延时会被放大甚至卡死
需要传输链路加密	✅ RTMPS / SRT	明文 RTMP 不适合跨公网传敏感内容
做观众端播放	❌ 用 HLS / HTTP-FLV	Flash 已停用，浏览器不再支持 RTMP 播放
要传 4K 高码率且网络一般	⚠️ 先测	瓶颈常在带宽与丢包，不在协议

与 SRT、HLS 的分工

• SRT：在不可靠网络上做安全可靠传输，抗丢包能力强。公网回传、跨城、移动网络下明显优于 RTMP。它替代的是 RTMP 在第一段的位置。
• HLS：基于 HTTP 的分片分发协议，穿透性最好、CDN 支持最好，代价是延时较大（通常数秒到十几秒，低延时 HLS 可压到 2–5 秒）。它管的是第二段。
• HTTP-FLV：国内常见的低延时分发方案，延时小于 HLS，穿透性也还行。

配置 RTMP 推流时的常见坑

1. 地址填错层级：RTMP 推流地址由"服务器地址 + 端口 + 目录名 + 节点名"组成。目录名与节点名由平台分配，填错会连上服务器但推不进去，报错信息往往不直白。
2. DNS 没配：用域名推流时，编码器网络设置里必须填正确的 DNS，不同运营商的 DNS 不同。DNS 解析失败的表现是"网络正常但推不出去"。
3. 编码格式不匹配：RTMP 承载 H.264 是稳妥选择。若编码器设置为 H.265，很多服务器与播放器处理不了，表现为黑屏或有声音无画面。
4. 码率超过实际上行带宽：这是最常见的"卡顿"根因。按实际上行带宽的 60–70% 设码率，留余量。
5. 防火墙只拦了 1935：企业网络里常见。确认出方向 1935 放行，或改用 RTMPS/443。

排查顺序建议：先用 VLC 在局域网内直接拉编码器的 RTSP 或 HTTP 流确认编码正常 → 再确认网络与 DNS → 最后查平台侧地址与鉴权。这样能把"设备问题"和"网络/平台问题"分开。