7.5.3 SRT：弱网回传的 ARQ 路线（SRT & The ARQ Prescription）
7.5.2 的结尾留下了另一位 UDP 选手：它的目标不是双向互动，而是把高码率信号可靠地送过公网弱网。这位选手是 SRT（Secure Reliable Transport）——2013 年由 Haivision 推出、2017 年开源，如今以 IETF 草案（draft-sharabayko-srt，尚未成 RFC）加事实标准的双重身份运行在回传链路上 [11]。
出身与定位：UDT 的直播改造
SRT 的血缘来自 UDT——一个运行在用户态的 UDP 可靠传输协议。SRT 保留了其核心机制，针对直播场景做了三项关键改造：面向流的 pacing 流控、更精细的拥塞控制、内建加密 [11]。它的可靠性哲学与 TCP 截然不同：ARQ 选择性重传——只补真正丢失的包，可再叠加 FEC 前向纠错；没有字节流的全局保序承诺，也就没有队头阻塞的连锁反应。
场景定位同样鲜明：公网长距离、弱网环境下的信号贡献（contribution / first mile）——把赛场、演播室的高码率信号送回制作中心或云端。listener/caller 模型支持双向数据流，同一 UDP 端口还能复用多条 SRT 连接，内置多路复用与访问控制 [11]。相比 TCP 系的 RTMP，它在高丢包长途链路上的带宽利用率要高出一截——这恰是回传场景最痛的点。
TSBPD：用时间戳重放节奏
SRT 的核心机制叫 TSBPD（Timestamp-Based Packet Delivery，基于时间戳的包投递），目标说得极富画面感：在接收端的解码器入口，原样重放发送端编码器出口的包节奏 [11]。每个数据包携带一个微秒级时间戳（相对连接创建时刻），接收端按下面的公式决定每个包的放行时刻：
- TsbpdTimeBase：两端时钟的时基差，握手时即定初值（本端当前时刻减去对端握手时间戳），把对端时间戳换算进本地坐标系
- PKT_TIMESTAMP：包在发送端诞生的时刻——注意重传时沿用原戳、绝不重新盖戳；草案特意点明，若按重传时刻盖新戳，包在流中的位置就乱了 [11]
- TsbpdDelay：接收缓冲延迟，即配置的 "SRT 延迟"，要覆盖 RTT 波动加重传所需的时间；握手协商的最小值为 120 毫秒，推荐取 3~4 倍 RTT [11]
- Drift：双端时钟漂移的动态补偿
网络抖得越凶，包到得越没谱，但接收端一律按住、等齐节奏再放行——抖动被吸收进缓冲，换来恒定的端到端延迟。我们在 5.3.1 建立的时间戳概念，到此完成一次漂亮的升维：从 "帧内对齐" 变成 "端到端节奏重构"。而 TsbpdDelay 还兼任另一重角色：它给重传次数天然封顶——超过放行时刻还没补回来的包，追回来也没有意义了。
Too-Late Packet Drop：迟到的包不如丢弃
"追回来也没意义的包" 怎么处理？SRT 的回答是 Too-Late Packet Drop：超过播放时刻的包，宁可丢弃也不迟交 [11]。这个开关把直播取向写进了协议骨髓——对照 7.2.1 那句 "迟到等价于丢失"，RTP 靠接收方自己领悟的道理，SRT 把它做成了内建机制。直播流因此获得一份确定性：延迟恒定、节奏恒定，代价只是偶尔丢掉一个注定迟到的包。
握手与加密速览
SRT 的握手分两阶段 [11]：Induction 交换能力与版本（32 位版本号），Conclusion 确认配置参数（含 TsbpdDelay 的双向取值）。加密基于 AES（CTR 或 GCM 模式，后者附 128 位认证标签），密钥体系为 SEK/KEK 双层结构并支持周期性刷新——Secure Reliable Transport 的 S，不是白叫的。
小结：三条 UDP 路线的分工
把 7.2 与 7.5 连起来看，UDP 低延迟路线上站着三位分工明确的选手：RTP/WebRTC 管双向互动，SRT 管点到点回传，QUIC 时代的 HTTP/3 则把分发也搬上了 UDP。SRT 与 RTMP 的对位尤其工整——同是推流回传角色，一个抱 TCP 求稳，一个驾 UDP+ARQ 闯弱网。至此，第七章的协议群像全部登场完毕。下一节，让我们退后一步，用一幅编年长卷与一张对照表，看清这场四分之一个世纪的技术接力。