基于 HTTP-FLV 的自适应码率直播流：一种实用系统视角
内容提要
TikTok Live 研究 HTTP-FLV 直播的自适应码率实现。由于 HTTP-FLV 是连续流而非分段协议，客户端切换码率会导致新旧流争抢带宽。论文提出客户端决定码率、服务器执行切换的分工，并引入服务端拥塞反馈（CCTK）和一致性哈希优化。基于数十亿会话的 A/B 测试显示，服务器执行切换使切换期卡顿时长降低 13%，ABR 整体降低卡顿率 4.7%，人均日观看时长提升 0.2%。
延伸解读
连续流协议下的切换难题
HTTP-FLV 不像 HLS/DASH 那样有天然分段边界，客户端切换码率时新旧流会同时传输，在弱网下争抢同一瓶颈带宽，导致卡顿。文章指出，传统客户端 ABR 控制逻辑在连续流协议中会引发带宽争抢，因为旧流需继续发送直到新流关键帧到达，而新流请求又立即发起，两者重叠传输。
服务器执行切换的收益与代价
将切换执行移到服务器侧，由边缘服务器统一决定新流起点和旧流终点，能缩短带宽争抢窗口。A/B 测试显示，服务器执行切换使切换期卡顿时长降低 13%，弱网下卡顿率下降 28.7%。但代价是边缘服务器需维护会话 token、识别关键帧、处理超时重试，从无状态分发节点变为切换控制环的一部分，工程复杂度增加。
ABR 整体收益与评价维度
启用 ABR 后，整体卡顿率下降 4.7%，平均码率提升 10.8%，人均日观看时长增加 0.2%。但收益并非单纯提高码率：网络良好时 ABR 提升码率 14.5%，弱网时则降低码率 6.6% 以换取卡顿率下降 9.8%。评价 ABR 应关注其在不同网络区间是否做出合理交换，而非只看码率高低。
辅助优化与适用边界
CCTK 提供服务器拥塞控制反馈作为客户端带宽估计输入，一致性哈希减少跨集群请求并提高边缘缓存命中率。缓存命中时卡顿率比未命中低 35.9%。但结论基于 TikTok Live 单一平台，QoE 数据归一化，且需第三方 CDN 配合改造，不能直接外推到所有直播业务。
Q&A
HTTP-FLV 直播为什么不能直接照搬 HLS/DASH 的客户端 ABR 切换？
因为 HTTP-FLV 是连续流协议，一个 URL 对应一条持续产生的码率流，没有天然的分段边界。客户端发起新码率请求时，旧流可能仍在发送，新旧流会在同一条受限接入链路上争抢带宽，导致切换期间卡顿。
TikTok Live 提出的服务器执行 ABR 切换具体是怎么工作的？
客户端仍负责决定目标码率，但切换动作交给边缘服务器。服务器通过 session token 关联观看会话，在发送旧版本关键帧前检查新版本缓存，满足条件时执行切换，使新版本起点和旧版本终点合并为一个决定，从而缩短带宽争抢窗口。
服务器执行 ABR 切换相比客户端执行，在线上 A/B 测试中效果如何？
在数十亿会话的 A/B 测试中，服务器执行切换使每次切换期间的平均视频卡顿时长降低 13%，降码率时切换成功率提高 1.6%，平滑切换率提高 35.5%；弱网子集中卡顿率下降 28.7%。
在 HTTP-FLV 上启用 ABR 整体能带来哪些 QoE 和用户收益？
与关闭 ABR 相比，整体视频卡顿率下降 4.7%，卡顿频次下降 3.3%，平均码率提升 10.8%；人均日观看时长增加 0.2%，达到 95% 置信水平。
CCTK 是什么？它在 HTTP-FLV ABR 中起什么作用？
CCTK 是 QUIC 中定义的一种拥塞控制反馈控制帧。边缘服务器通过它向客户端 ABR 算法提供更细粒度的带宽估计，并可选反馈 RTT、丢包率等传输层指标，降低客户端网络估计复杂度，已成为默认带宽估计来源。
一致性哈希在 TikTok Live 的 HTTP-FLV 系统中解决了什么问题？
一致性哈希用于集群内代理节点选择，使同一集群不会同时向上游请求同一个码率版本，减少跨集群链路流量，提高边缘缓存命中率，并改善小型集群的入口负载均衡。
服务器执行 ABR 切换有哪些工程复杂度和适用边界？
边缘服务器需要支持会话 token、媒体时间戳、关键帧识别、超时重试与跨 CDN 处理，第三方 CDN 也要配合改造；结论来自 TikTok Live 单一平台，QoE 数据经归一化，不能直接外推到所有直播业务。
