互联网直播的发展大致可分为 4 个阶段：创新期、演进期、量产期和瓶颈期，分别对应着不同的直播场景、实现技术，相应地会有不同的延迟及用户体验。
综上可以看到，直播技术的发展和直播场景是相辅相成的。场景驱动技术发展，技术反过来支撑更多的直播场景。当前我司已经支持的连麦技术，在「主播-主播」之间的延迟已经较低了，但还是存在两个问题：
因此对下一代超低延迟直播技术的探索，成了我们当前不得不做的一项工作。
当前业界的主流直播实现方案为 rtmp + http-flv + hls。存在以下问题：
因此，大部分基于 TCP 的协议无法满足低延迟直播的需求，需在 UDP 方案中进行调研。
纵观业界当前比较领先的低延迟直播技术实现，大体上有 WebRTC、QUIC、SRT、CMAF、LLHLS 等方案。这里做一简单对比：
| 指标 | WebRTC | QUIC | SRT | CMAF | LLHLS |
|---|---|---|---|---|---|
| 提出时间 | 2010 | 2012 | 2012，2017 | 2016 | 2019 |
| 覆盖链路 | 采集、编解码、传输、渲染 | 传输 | 编码、传输 | 封装、传输 | 封装、传输 |
| 传输层协议 | UDP | UDP | UDP | TCP | TCP |
| 类型 | 流式、不可靠 | 流式、可靠 | 流式、可靠+不可靠 | ABR切片式、可靠 | ABR切片式、可靠 |
| 针对场景 | 端到端音视频通信 | 通用协议 | 媒体远程制作 | 下行分发、CDN友好 | 下行分发、CDN友好 |
| 标准化 | RFC/W3C | RFC Draft | Halvision SRT联盟 | ISO MPEG | Apple |
| 延时 | 端到端 250ms | >2s | >2s | >3s | >2s |
| 终端 | H5、iOS、Android | Chrome | FFmpeg | H5 | iOS |
这里简要介绍一下 WebRTC、QUIC 及 LLHLS：
WebRTC，即 Web Real-Time Communication，web实时通信技术。实现了基于网页的语音对话或视频通话，目的是无插件地实现 web 端的实时通信能力。
WebRTC 提供了音视频的核心技术，包括音视频采集、编解码、网络传输、终端展示等，覆盖了流媒体的大部分环节，且支持跨平台，通过简单调用 API 即可使用。
从延迟上看，WebRTC 由于采用了 UDP 的传输协议，端到端延迟一般在毫秒级别，极限情况下可达到 100ms 以内。
QUIC，即 Quick UDP Internet Connection，是 Google 开发的一种基于 UDP 协议的低延迟互联网传输协议。解决了 TCP 的头部阻塞、握手/挥手延迟、切换网络断线重连等问题。可在一定程度上降低端到端的延迟。
但由于 QUIC 的设计目标是成为一个通用的传输协议，也并没有针对多媒体数据进行优化，因此其应用在音视频传输上的延迟是秒级的。
苹果于 2019 年提出了低延迟 hls 的草案，旨在通过降低切片发布延时、优化客户端发现新分片的方式、消除额外 rtt、减小传输开销等方式，进一步降低 hls 的直播延迟。具体可见：低延迟 hls 调研
降低发布延时是通过允许服务器在主分片准备好之前，先发布其中部分内容的方式来实现的。假设当前一个分片时长为 6s，可将其切成 30 个小分片，每个小分片包含 200ms，可独立被客户端获取并播放。且当一个分片被全部生成后，其小分片会被删除，以避免播放列表的膨胀。
可以通过如下标签启用部分分片功能：
#EXT-X-PART-INF:PART-TARGET=0.33334
#EXT-X-PART:DURATION=0.33334,URI="filePart271.0.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.1.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.2.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.3.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.4.mp4",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.33334,URI="filePart271.5.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.6.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.7.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.8.mp4",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.33334,URI="filePart271.9.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.10.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.11.mp4"
#EXTINF:4.00008,
fileSequence271.mp4
EXP-X-PART-INF 标签的 PART-TARGET 属性标识每个部分片段的持续时间，该值为十进制浮点数。
EXT-X-PART 标签表示每一个具体的部分片段，DURATION 属性标识持续时长，URI 为该部分片段的标识符，INDEPENDENT=YES 表示该部分片段包含一个独立的帧，以此来提高客户端切入的效率。
客户端第一次请求 m3u8 时，服务器会返回全量分片列表。此后客户端只会关心 m3u8 的增量部分，因此发起的是增量请求，以便客户端更频繁地获取播放列表，从而降低延迟。返回数据相比原始全量数据会大大减少，以便于放在一个 MTU 数据包内返回。
增量更新可以减少每次传输的数据量，可通过以下标签予以支持：
#EXT-X-SERVER-CONTROL:CAN-SKIP-UNTIL=12.0
#EXT-X-SKIP:SKIPPED-SEGMENTS=3
EXT-X-SERVER-CONTROL 标签使服务器指示对传递指令的支持，CAN-SKIP-UNTIL 指示服务器可以响应 HLSskip 指令来生成播放列表增量更新。它的值是需要跳过的秒的十进制浮点数。
EXT-X-SKIP 标签的 SKIPPED-SEGMENTS 属性表示需要被跳过的分片数。
为了在生成新媒体段和部分段后及时通知到客户端，低延迟 HLS 引入了阻塞客户端加载请求的功能。当客户端发出 HTTP GET 请求更新媒体播放列表时，可以带上 HLSmsn 这个参数，以表明其希望播放列表里包括将来的片段。然后，服务器阻塞请求，直到包含该片段的播放列表版本可用为止。此特性可以消除客户端对播放列表的轮询。
服务器使用新标签 EXT-X-PRELOAD-HINT 来通知客户端即将出现的部分段和媒体初始化段。客户端可以提前发出对提示资源的 GET 请求；只要媒体可用，服务器就会响应该请求。具体来说，就是在服务器上还没有新分片之前，客户端就已经发起对该分片的请求。一旦服务器上生成了该分片，就可以立即推送给客户端。此种方式可以在小于 1rtt 的时间内发现新分片。
#EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=20000@0
#EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=23000@20000
#EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=18000@43000
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs271.mp4",BYTERANGE-START=61000
该 m3u8 文件表明，当前已经生成了三个分片，EXT-X-PRELOAD-HINT 标签表示第四个分片虽然还未生成，但可以提前推送给客户端。
客户端第一次请求到全量播放列表后，会和服务器建立起一条连接。此后当有新分片生成时，服务器会主动将 m3u8 和 ts 分片推送给客户端，减少了一次轮询的 rtt 时间。
由于服务器推送方式需要 HTTP/2 的支持，在 CDN 场景下不友好，因此该方案已被废除。
由于是增量更新 m3u8，当 CDN 上有两种码率的流时，每次返回时可以携带额外信息。因此当客户端需要切换到不同码率时，就可以直接切换。
当前业界比较成熟的低延迟直播系统有腾讯云的快直播、阿里云的 RTS，均采用 WebRTC 作为底层流媒体框架。简要介绍如下：
快直播方案改造的就是从CDN分发节点到SDK、再到观众端播放这部分，这样的好处在于主播推流中间的录制、截图、转码等都可以复用，接入简单，可以同时出flv、rtmp、hls、WebRTC的数据流。
此外，快直播从五个方面对标准WebRTC进行升级，包括支持aac（同时支持adts、latm两种封装）、视频支持H265和B帧、通过STP协商精简了信令交互、可以关闭gtrs以及支持透传metadata。
在接入方面，快直播的接入其实非常简单，只需要一步就可以从标准直播升级为快直播——升级播放端、其余全部复用。Web/H5端调用浏览器WebRTC接入快直播，App接入需要集成SDK。
在直播效果上，快直播能做到的延迟一般是300ms左右，极限延迟可以做到43ms。并且首帧在 100ms 左右，质量和flv相当，而延迟从10秒降低到300ms，并且可以抗30%+丢包。
RTS 是由阿里云和淘宝直播共建的低延迟直播系统，此系统分两大块：
RTS拥有四个技术特性：
RTS 底层依赖阿里云 GRTN 网络，GRTN的定位是基于中心云和边缘云的异构节点，构建超低延时、全分布式下沉的通信级流媒体传输网络。目前融合了互联网直播和RTC等多种业务场景的音视频流传输和交换。基于GRTN的短延时直播RTS可以支持标准H5 WebRTC推播，在千万级并发情况下延时可以控制在1s以内；RTC端到端延时可以控制在250ms左右。