ACM IMC 2017 年会论文实测显示，QUIC 在多数网络条件下的页面加载时间优于 TCP，但在出现包乱序时表现显著劣于 TCP，根因是 QUIC 误判乱序为丢包；引入 NACK 阈值机制后可扭转劣势。
部署现状与既有评测局限：
QUIC 由 Google 提出，基于 UDP 实现类 TCP 特性，已迭代至版本 43。Google、Akamai 等已部署，Microsoft、Mozilla、Verizon、Facebook 等 20 余家厂商在研实现。Google 最大规模部署显示：Chrome 对 Google 服务请求 85% 走 QUIC，接收字节 90% 经 QUIC，占互联网流量 7%。Google 自报搜索页加载提升 3%、YouTube 缓冲降 18%，但为聚合统计、不可复现；独立评测多受限于环境与网络，缺乏根因分析。
页面加载时间实测与乱序影响：
实测在三组网络参数下对比：RTT 36ms/无丢包、RTT 26ms/丢包 1%、RTT 112ms/无丢包。结果显 QUIC 在常规场景普遍快于 TCP（图 1）。但引入包乱序后，QUIC 性能大幅落后（图 2）。代码分析揭示：QUIC 将乱序误判为丢包触发重传，而 TCP 能检测乱序并提高 NACK 阈值。实验证实，将 QUIC 的 NACK 阈值提升至 30 以上，即可在乱序场景反超 TCP（图 3）。
测试平台与方法：
原文未给出具体数据，仅提及图 4 展示测试平台拓扑。论文采用受控实验环境，通过调整链路容量、对象大小、RTT 与丢包率组合，系统量化 QUIC 与 TCP 的页面加载时间差异，并结合源码定位性能瓶颈。完整测试细节见 ACM IMC 2017 原文。
对运维与网络工程师而言，QUIC 在常规部署可降低延迟，但移动网络、无线回程等易发乱序场景需警惕误判丢包导致的性能倒挂；调大 NACK 阈值或引入乱序检测机制是关键优化方向。
原文: APNIC Blog（2018-01-29）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog