SRT协议简介

eijs

协程是现代服务器的核心技术，能极大简化逻辑和提升维护性；SRT是逐渐在取代RTMP推流的新协议，但它有自己的IO框架；只有实现了SRT的协程化，才能成为SRS的核心的成熟的协议，这是SRS 5.0迈出的第一步，也是至关重要的一步。

SRS 5.0从2022年初启动以来，经过摸索和探讨，确定了以媒体网关作为核心方向，详细请看[color=var(--ifm-link-color)]SRS 5.0核心问题定义和解法。

SRT作为主播/广播推流领域广泛采用的协议，而Web浏览器却不支持播放SRT流，这恰恰是媒体网关的核心价值，可以将SRT转成RTMP/HLS/WebRTC后，实现广播领域的Web超低延迟方案，还可以把SRT强大的跨国传输能力用起来。

而这些美好愿景的基础，就是这次要介绍的：改造SRT支持协程化(Coroutine Native SRT)。这是SRS 5.0至关重要的一步，也是具备深远影响的一步，详细代码请参考[color=var(--ifm-link-color)]PR#3010。

我们先了解下详细的背景介绍。

在直播推流领域，RTMP是事实上的工业标准，广泛使用，也是直播源站之间兼容性最好的协议。

随着场景的丰富和直播的发展， 几个比较严重的问题逐渐暴露出来：

• TCP推流在长距离传输下，受丢包以及RTT抖动影响非常大，效果很差。
• RTMP协议不支持多音轨，以及H265、AV1等一系列新的编解码。
• Adobe已经放弃RTMP协议，很多年没有更新了，未来也不会更新。
  

为了解决这些问题，2018年左右，广播电视领域开始广泛应用SRT协议推流，越来越多的推流设备和平台都支持了SRT协议。

SRS在2019年底，SRS 4.0支持了SRT推流，目前存在以下的问题：

• SRT在SRS上使用多线程+异步实现，某些异常导致的程序Crash，难以排查。
• SRT在SRS实现是异步方式，代码复杂，维护难度高。
• HTTP回调，SRT播放不生效；SRT推流依赖转RTMP后，RTMP触发的回调。
• SRT无法直接转WebRTC，而是先转RTMP再转WebRTC，导致延迟高。
  

这些问题的核心原因，是由于SRT使用了独立的异步IO和多线程，无法和SRS已有的ST协程结合起来。

要彻底解决这个问题，必须将SRT协程化，和SRS使用同一套ST协程框架。SRS 5.0已经完成，详细代码请参考[color=var(--ifm-link-color)]PR#3010，这是非常重要的一个功能。

在介绍SRT协程化之前，先介绍下什么是协程化，我们看下ST的TCP协程化(Coroutine Native)，这是最好的例子。