InfoQ|阿里淘系自研标准化协议库 XQUIC 首次公开：直播高峰期卡顿可降低 30%( 五 )

为什么是 2.5s?

优化后 BBR 带宽利用率：(0.2s * 75% + 2.5s * 100%) / (0.2s+ 2.5s) = 98.1%
原生 BBR 带宽利用率：(0.2s * 0% + 10s * 100%) / (0.2s + 10s) = 98.0%
在整体带宽利用率不降低的情况下，调整到 2.5s 能达到更快感知网络变化的效果。
优化效果保证带宽利用率不低于原生 BBR 的前提下，使得发送更平滑，更快探测到 RTT 的变化。
BBR 带宽探测优化

InfoQ|阿里淘系自研标准化协议库 XQUIC 首次公开：直播高峰期卡顿可降低 30%

本文插图

图 12. BBR v1 示意图：StartUp 和 ProbeBW 阶段问题分析StartUp 阶段 2.89 和 ProbeBW 阶段 1.25 的增益系数导致拥塞丢包，引发卡顿和重传率升高（Cubic 重传率 3% ，BBR 重传率 4%）重传导致带宽成本增加 1% 。
优化策略

本文插图

图 13. 带宽变化示意图定义两个参数：
期望带宽：满足业务需要的最小带宽
最大期望带宽：能跑到的最大带宽
未达到期望带宽时采用较大的增益系数，较激进探测带宽。
达到期望带宽后采用较小的增益系数，较保守探测带宽。
优化效果成本角度：重传率由 4% 降到 3% ，与 Cubic 一致，在不增加成本的前提下降低卡顿率。
另外，该策略可以推广到限速场景，如 5G 视频下载限速，避免浪费过多用户流量。
卡顿、秒开优化效果在直播拉流场景下与 TCP 相比较，高峰期卡顿率降低 30%+ ，秒开率提升 2% 。
写在优化最后的思考最后，我们看看 TCP 初始重传超时和初始拥塞窗口的发展历程：

初始重传时间

RFC1122 (October 1989) 为 3s
RFC6298 (June 2011) 改为 1s ，理由为 97.5% 的连接 RTT<1s

初始拥塞窗口

RFC 3390 (October 2002) 为 min(4 * MSS, max(2 * MSS, 4380 bytes))（MSS=1460 时为 3）
RFC 6928 (April 2013) 改为 min (10 * MSS, max (2 * MSS, 14600))（MSS=1460 时为 10）—— 由 google 提出，理由为 90% of Google's search responses can fit in 10 segments (15KB).

首先 IETF RFC 是国际标准，需要考虑各个国家的网络情况，总会有一些网络较慢的地区。在 TCP 的 RFC 标准中，由于内核态实现不得不面临一刀切的参数选取方案，需要在考虑大盘分布的情况下兼顾长尾地区。
对比来看， QUIC 作为用户态协议栈，其灵活性相比内核态实现的 TCP 有很大优势。未来我们甚至有机会为每个用户训练出所在网络环境最合适的一套最优算法和参数，也许可以称之为千人千面的网络体验优化。
Multipath QUIC 技术Multipath QUIC（多路径 QUIC）是当前 XQUIC 内部正在研究和尝试落地的一项新技术。
MPQUIC 可以同时利用 cellular 和 wifi 双通道进行数据传输，不仅提升了数据的下载和上传速度，同时也加强了应用对抗弱网的能力，从而进一步提高用户的端到端体验。此外，由于 5G 比 4G 的无线信号频率更高， 5G 的信道衰落问题也会更严重。所以在 5G 部署初期，基站不够密集的情况下如何保证良好信号覆盖是未来 2-3 年内手机视频应用的重大挑战，而我们研发的 MPQUIC 将为这些挑战提供有效的解决方案。
Multipath QUIC 的前身是 MPTCP[6] 。 MPTCP 在 IETF 有相对成熟的一整套 RFC 标准，但同样由于其实现在内核态，导致落地成本高，规模化推广相对困难。业界也有对 MPTCP 的应用先例，例如苹果在 iOS 内核态实现了 MPTCP ，并将其应用在 Siri、Apple Push Notification Service 和 Apple Music 中，用来保障消息的送达率、降低音乐播放的卡顿次数和卡顿时间。