SRT推流协议能取代RTMP，靠的是ARQ自动重传和端到端加密。在专线不稳、走公网的弱网环境，它把丢包自动补回来，延迟还能压在可控档位，比RTMP裸推稳得多，也更适合有保密要求的会议直播。我们现在的会务项目，走公网默认就上SRT。
SRT推流协议的定义：为不可靠网络设计的传输层
SRT推流协议是一套面向公网不可靠链路的流媒体传输协议，核心目标是把直播信号在丢包、抖动的网络里安全送到位。它和RTMP的本质区别，是RTMP假设网络基本可靠，而SRT一开始就按会丢包来设计。
摄行科技在走公网、没有专线的会务项目里，默认用SRT而不是RTMP，就是看中它在弱网下的自愈能力。内链：会务直播技术专栏 有更多传输选型对比。
机制一：ARQ自动重传，丢了的包补回来
SRT在接收端发现某个包丢了，会向发送端发起重传请求，发送端把丢失的包再发一次。这样即便公网实时丢包一两成，画面也能补全，不会出现RTMP常见的花屏或卡顿。
这个机制的关键在于重传要在延迟窗口内完成。我们一般现场先测链路丢包率，再定重传缓冲，让重传来得及又不拖累实时性，比盲目加码率管用。
机制二：端到端加密，流在公网里不被截
SRT支持端到端加密，信号从发送到接收全程加密，中间节点看不到内容。这对有保密要求的内部会议直播很关键，尤其跨公网传输时，比明文RTMP让人放心。
我们给金融、制造类客户的内部直播，几乎一律走加密SRT。密钥在两端配置，不进中转服务器，既满足合规，也不增加太多延迟，是性价比很高的安全选项。
延迟档位怎么选：别拍脑袋给固定值
- 公网一般给120到300毫秒缓冲，太小重传来不及时，太大延迟难接受
- 专线质量好可以压到80毫秒上下
- 加密和重传都会吃一点延迟，定档前先实测一轮
延迟档位不是越矮越好，太矮重传来不及，反而更卡。我们每个项目都先测一遍链路再定档，而不是套用别处的值，因为两条公网的质量可以差很远。
和RTMP的适用边界：什么时候还用RTMP
RTMP并非完全没用。它生态成熟、兼容性广，很多老平台只认RTMP入口。我们常在SRT把信号送到云端后，再用RTMP接进这些老平台，各取所长。
所以选型不是二选一，而是按链路分段用。源端到云走SRT保质量，云到平台入口走RTMP保兼容，这样既不牺牲弱网稳定性，也不卡在平台接口上。
现场避坑：三类SRT配置翻车点
第一类是延迟档设太小，弱网下重传追不上，反而比RTMP还卡；第二类是防火墙没开UDP端口，SRT走不通还以为是网络坏；第三类是两端密钥不一致，握手失败查半天。
这三类我们在进场前清单里都写明了，开播前逐项验证。SRT比RTMP多几道配置，但配对了，弱网下的稳定性提升是肉眼可见的。
SRT不是换了协议就完事
有人以为把推流地址改成SRT就稳了，结果延迟档设太小、防火墙没开UDP，照样卡。SRT比RTMP多几道配置，但配对了弱网稳定性提升肉眼可见。
我们每个项目先测链路再定档，把端口和密钥都验证过才开播。协议只是工具，配不对照样翻车，这点容易被低估。
SRT和普通推流的接入差异
SRT 在接入上比 RTMP 多一步握手和密钥协商，很多老编码器默认只吐 RTMP，要换 SRT 得先确认硬件固件支持。我们一般提前一周让客户提供设备型号，在实验室先跑通再带去现场，不把第一次握手留到开播当天。
另一个差异是端口，SRT 走 UDP，而不少场馆防火墙只开了 TCP 的 1935，结果 SRT 推不出去还查半天。这类坑我们会在进场清单里单列一项「UDP 端口放行」，开播前让网管确认，比现场抓瞎强。
核心要点速览
下面这几条是SRT推流协议这类项目里容易踩、也值得提前记下的点，可以直接照着排：
- SRT靠ARQ重传把公网丢包补回来，比RTMP裸推稳。
- 端到端加密让流在公网传输不被截，适合保密会议。
- 延迟档按链路质量定，太小重传来不及时、太大延迟难接受。
- 源端到云走SRT保质量，云到老平台入口走RTMP保兼容。
- UDP端口没开、两端密钥不一致，是SRT最常翻车的两点。
把 SRT 验证前置到实验室
我们把 SRT 的第一次握手放在实验室而不是现场。提前一周向客户要到编码器型号，先在本端跑通握手、密钥和端口，确认固件支持再带去场馆。现场最贵的那一小时，不该用来排障，这个前置习惯让我们在关键会议上少出意外。
另外，SRT 走 UDP，很多场馆防火墙只开了 1935 的 TCP，到了现场才发现推不出去。我们会在进场清单里单列一项 UDP 放行，开播前让网管确认。这类坑不前置就只能在直播里抓瞎，把验证做在前面，现场只剩按流程执行。
我们甚至把这一步写进项目启动清单的第一项，客户没给型号就先等型号，不拿现场赌兼容性。省下的排障时间，够多走一遍彩排，性价比远高于临时救火。
延伸阅读
常见问题
-
SRT比RTMP延迟更高吗？ 答：不一定。SRT的延迟主要来自你设的重传缓冲档，档设小延迟就小，80毫秒也能做到。RTMP看似低延迟，但弱网一丢包就卡或花，实际观感更差。我们按链路质量定档，不盲目比数字。
-
没有专线能用SRT推流吗？ 答：能，而且这正是SRT的强项。它本来就是为不可靠公网设计的，靠ARQ重传把丢包补回来。我们很多会场没专线，直接走SRT上云，比裸RTMP稳得多。
-
SRT需要平台支持吗？ 答：需要接收端也支持SRT，否则要用网关做协议转换。我们常在云端落一个SRT接收，再转RTMP接老平台。如果平台只认RTMP，分段用就行，不必强求端到端都SRT。
-
加密SRT影响画质吗？ 答：不影响画质，只多一层加解密计算，对现代设备几乎无感。我们给有保密要求的内部会议都用加密SRT，既满足合规也不牺牲清晰度，是划算的安全投入。
-
SRT推流协议适合所有活动吗？ 答：不是。链路质量好、平台又只认RTMP时，硬上SRT反而多配置。我们按链路分段用，源端到云走SRT保质量，云到老平台入口走RTMP保兼容，各取所长。
摄行科技在类似会务项目里，通常先把勘场和压测放在第一位，再谈设备和人员，这个顺序踩过几次坑才定下来。
关于摄行科技
如果你要把一场活动走公网推到云端，又担心丢包和泄密，把网络条件和平台入口发过来，摄行科技可以先测一遍链路再给SRT配置建议。也可以拨打直接聊需求。
#摄行科技
