当前位置：首页 > news >正文

谈谈最近学习的低延迟直播架构的一些收获

news 2026/5/13 1:21:10

最近一直在深耕低延迟直播平台的开发，从协议选型到实现，踩过不少坑，也积累了很多经验。分享一下这段旅程中的思考和收获～

一、直播核心协议选型：从认知到决策

我对核心协议的整理与分析：就是编写的第一步，是理清主流直播协议的特性，找到适配场景的技术方向。以下

1. HTTP-FLV：兼容性之王

核心特点：基于 HTTP 分块编码传输 FLV 容器格式，轻量化、易部署。

封装与传输：FLV 仅支持 H.264/H.265（视频）、AAC/MP3（音频），封装简单（头部 + 音视频 Tag），解码延迟低；借助 HTTP 分块编码实现 “边传边播”，默认 80/443 端口可穿透防火墙。
传输流程：
1. 播放端发送GET /live/stream.flv请求，携带Accept: */*；
2. 服务端响应Transfer-Encoding: chunked，按 1-8KB 拆分 FLV 流并实时推送。
延迟构成：
- 编码延迟（50ms-300ms）：依赖推流端低延迟设置（无 B 帧、短 GOP）；
- 服务端延迟（300ms-2s）：GOP 缓存 / 转码是主因（优化后可压至 300ms 内）；
- 传输 + 播放端延迟（400ms-1.9s）：HTTP 封装开销 + 播放器缓冲（优化后可至 0.3-1s）。
优缺点：✅ 兼容性极强（浏览器 / APP / 机顶盒）、配备简单、拥护 HTTPS；❌ 协议开销略高、依赖 GOP 缓存、Web 端需 FLV.js 解析。

2. RTMP：低延迟直播老将

核心特点：基于 TCP 的实时消息传输协议，专为音视频设计。

传输机制：分层结构（应用层 / 消息层 / 协议层），Chunk 分块传输大帧，滑动窗口控流。
延迟优势：优化后全链路延迟 0.8-2s，比 HTTP-FLV 低 20%-30%，服务端无转码时延迟可忽略。
优缺点：✅ 延迟低、配置直接、兼容性广；❌ 弱网 TCP 重传易卡顿、无默认加密、Web 端需 Flash 替代方案。

3. HLS/LL-HLS：跨平台兼容首选

核心特点：切片传输 + 自适应码率，原生支持全平台。

原生痛点：切片机制导致延迟 10-30s（切片生成 + 缓存 + 播放缓冲）；
LL-HLS 优化：缩短切片至 0.5-2s、分片传输 Chunk、实时更新 m3u8，延迟降至 3-5s。
优缺点：✅ 极致兼容、自适应码率、易部署；❌ 原生延迟高、切片开销大、实时性差。

4. WebRTC：实时互动利器

核心特点：浏览器原生实时通信，毫秒级延迟（50-300ms）。

技术栈：集成采集 / 编码 / 传输 / 渲染，UDP 传输 + P2P 直连，内置回声消除等互动功能。
延迟构成：采集编码（30-80ms）+ 传输（20-150ms）+ 解码渲染（10-30ms）。
优缺点：✅ 延迟最低、互动性强、无插件依赖；❌ 部署复杂（需 STUN/TURN/SFU）、带宽占用高。

5. SRT：专业级低延迟传输

核心特点：UDP 可靠传输 + 加密，延迟 10-150ms，抗丢包（10% 丢包仍稳定）。

技术优势：ARQ 重传 + FEC 纠错，原生 AES 加密，适配 4K/8K 高码率传输。
优缺点：✅ 延迟极低、可靠性强、加密安全；❌ Web 端兼容性差、CDN 支持有限、调整精细。

协议特性对比表

特性	SRT	WebRTC	HTTP-FLV（优化后）	RTMP（优化后）
原生延迟	10-150ms	50-300ms	1-2.5s	0.8-2s
传输协议	UDP（可靠传输）	UDP（为主）	TCP（HTTP/HTTP3）	TCP
丢包容忍性	强（10% 丢包）	中（5% 丢包）	强（TCP 重传）	中（TCP 重传阻塞）
加密支持	原生 AES	需 DTLS	依赖 HTTPS	需 RTMPS
高并发支持	中（需媒体服务器）	低（P2P 带宽受限）	高（CDN 分发）	中（CDN 支持）
部署复杂度	中	高	低	中

二、开发实践

1. 初期选型：WebRTC 的尝试与碰壁

最开始选择 WebRTC 作为核心协议（一是初期对 SRT 认知不足，二是看中其浏览器原生兼容性）：

手动封装信令服务器 + WebRTC 推拉流组件，实现基础功能后发现并发极低；
转向 MediaSoup（SFU 框架）优化并发，但全英文文档 + 拓展复杂度高，最终放弃。

这段经历虽未落地，但吃透了 WebRTC 的信令交互、NAT 穿透、媒体流处理逻辑。

2. 最终选型：SRS 的救赎

开源实时视频服务器，支持多协议转换，成为我的最终选择：就是SRS（Simple Real-Time Server）

拥护 RTMP/WebRTC/HTTP-FLV/SRT 等协议，开箱即用；
解决了 WebRTC 并发问题，且支持协议转换（如 RTMP 转 WebRTC）。

SRS 配置（6.0 版本）

# main config for srs.
listen              1935;          # RTMP端口
max_connections     1000;          # 最大连接数
daemon              on;            # 守护进程模式
# HTTP API：用于控制和查询SRS状态
http_api {enabled         on;listen          1985;
}
# HTTP服务器：提供HLS/HTTP-FLV访问
http_server {enabled         on;listen          8080;dir             ./objs/nginx/html; # 静态文件目录
}
# WebRTC配置：UDP端口+公网候选地址
rtc_server {enabled on;listen  8000; # WebRTC的UDP端口candidate 0.0.0.0; # 公网服务器需替换为实际IP
}
vhost __defaultVhost__ {# HLS配置：低延迟切片hls {enabled         on;hls_path        ./objs/nginx/html/hls;hls_m3u8_file   [app]/[stream].m3u8;hls_ts_file     [app]/[stream]-[seq].ts;hls_fragment    1; # 1秒切片，降低延迟}# HTTP-FLV挂载http_remux {enabled     on;mount       [vhost]/[app]/[stream].flv;}# WebRTC与RTMP互转rtc {enabled     on;rtmp_to_rtc on; # RTMP推流转WebRTC播放rtc_to_rtmp on; # WebRTC推流转RTMP播放}# 播放优化：GOP缓存+队列控制play {gop_cache_max_frames 2500;gop_cache on; # 缓存GOP实现秒开queue_length 10; # 播放队列长度（缓存10帧）}
}