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

拥塞会导致丢包，但是丢包却不一定拥塞导致的。事实上，丢包可以分为两类，一类是拥塞丢包，另一类是噪声丢包，特别是在无线网络环境中，数据以无线电的方式进行传递，无线路由器信号干扰、蜂窝信号不稳定等都会导致信号失真，最终数据链路层 CRC 校验失败将报文丢弃。
基于丢包的拥塞算法容易被噪声丢包干扰，在高丢包率高延迟的环境中带宽利用率较低。

基于带宽时延探测（如 BBR）

既然无法区分拥塞丢包和噪声丢包，那么就不以丢包作为拥塞信号，而是通过探测最大带宽和最小路径时延来确定路径的容量。抗丢包能力强，带宽利用率高。
三种类型的拥塞算法没有谁好谁坏，都是顺应当时的网络环境的产物，随着路由器、交换机缓存越来越大，无线网络的比例越来越高，基于路径时延和基于丢包的的拥塞算法就显得不合时宜了。对于流媒体、文件上传等对带宽需求比较大的场景， BBR 成为更优的选择。
秒开率优化加快握手包重传

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

本文插图

图 8. TCP 握手阶段出现丢包如图， TCP 在握手时，由于尚未收到对端的 ACK ，无法计算路径 RTT ，因此， RFC 定义了初始重传超时，当超过这个超时时间还未收到对端 ACK ，就重发 sync 报文。
TCP 秒开率上限：Linux 内核中的初始重传超时为 1s (RFC6298, June 2011) ， 3% 的丢包率意味着 TCP 秒开率理论上限为 97% ，调低初始重传时间可以有效提升秒开率。
同理，如果你有一个 RPC 接口超时时间为 1s ，那么在 3% 丢包率的环境下，接口成功率不会超过 97% 。

本文插图

图 9. TCP 和 QUIC 握手阶段 - 伪重传模拟另一方面，调低初始重传超时会引发伪重传，需要根据用户 RTT 分布进行取舍，比如初始重传超时调低到 500ms ，那么 RTT 大于 500ms 的用户在握手期间将会多发一个 sync 报文。
减少往返次数慢启动阶段 N 个 RTT 内的吞吐量（不考虑丢包）:
T = init_cwnd * (2^N-1) * MSS, N = ?t / RTT ?
Linux 内核初始拥塞窗口 =10（RFC 6928 ， April 2013）
首帧 100KB ，需要 4 个 RTT ，如果 RTT>250ms ，意味着必然无法秒开。在我们举的这个例子中，如果调整为 32 ，那么只需要 2 个 RTT 。