一条完整链路：推流接入（RTMP/SRT）、服务端转码、多端分发（HTTP-FLV/HLS/WebRTC）、互动层（弹幕连麦礼物）、风控层（审核鉴权巡检）。重点不是功能清单，是各段之间的容量匹配。详见直播方案总览。
分三档：单路推流加网页播放约 2 周；加转码档位、HLS 多端和CDN分发 4-6 周；再上 WebRTC 低延迟和连麦，2 个月起。跳步做低延迟大概率返工。
HLS 调优后 4-6 秒，HTTP-FLV 2-4 秒，WebRTC 可到 0.2-0.5 秒。互动场次用 WebRTC，普通场次 HTTP-FLV 就够。全站 WebRTC 的成本约是 HTTP-FLV 的 2.5-3 倍。
机房内网或网络稳定用 RTMP，生态最全；跨公网弱网推流选 SRT，抗丢包强、延迟 0.5-1 秒，但播放端要转回 RTMP 分发。多数平台两者都留。
原型验证用 MediaMTX（部署极简），长期承载用 SRS（协议全、集群成熟），纯转发小场景 Nginx-RTMP 够用。单机拉流并发压测别信理论值，4 核 8G 转发型 2000-5000 路是常见区间。
出口带宽 = 峰值并发观看数 × 码率 ÷ 1000。1 万人看 720p 约 20 Gbps，必须靠CDN分发边缘节点分摊。码率上限和并发上限的防护规则要在上线前配好。
两招：连接层按房间分片，同房间观众连同一组 WebSocket 节点，广播节点内完成；下发按 200 毫秒合并批量推送，消息量能砍到十分之一。万人房间每秒 500 条弹幕是这个架构的舒适区。
四层：内容审核（截帧机审加人审，人审时效 60 秒内）、推流鉴权（临时签名 5 分钟有效）、带宽防护（码率与并发上限）、房间巡检（15 分钟一轮自动扫描）。上线前四层的配置清单逐项过。
不承接。本站是直播技术服务领域的资讯站，只做方案与技术内容整理，不参与任何平台的实际运营，不涉及支付通道类业务。内容交流欢迎联系。
注明出处和链接可以转载。内容有修订更新，建议引用时注明版本日期。