SRS5.0第一大炮：如何实现SRT协程化

1.Coroutine Native SRT

---

Written by John[1], Winlin[2]

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

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

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

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

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

2.Introduction

---

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

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

1. \1. TCP推流在长距离传输下，受丢包以及RTT抖动影响非常大，效果很差。

2. \2. RTMP协议不支持多音轨，以及H265、AV1等一系列新的编解码。

3. \3. Adobe已经放弃RTMP协议，很多年没有更新了，未来也不会更新。

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

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

4. \1. SRT在SRS上使用多线程+异步实现，某些异常导致的程序Crash，难以排查。

5. \2. SRT在SRS实现是异步方式，代码复杂，维护难度高。

6. \3. HTTP回调，SRT播放不生效；SRT推流依赖转RTMP后，RTMP触发的回调。

7. \4. SRT无法直接转WebRTC，而是先转RTMP再转WebRTC，导致延迟高。

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

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

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

3.Coroutine Native TCP

---

首先，非协程化的代码，也就是epoll驱动的异步代码，大概逻辑是这样：

int fd = accept(listen_fd); // Got a TCP