QUIC 协议旨在解决 TCP 在复合 Web 事务中的头阻塞与会话开销问题，通过将传输功能下沉至用户态实现多路复用与加密协同。
协议演进与标准化进程：
QUIC 由 Google 于 2012 年启动开发，2013 年 8 月随 Chromium 29 版本首次公开发布。2021 年 5 月经 IETF 标准化为 RFC 9000。该协议不改变流控与流管理的基本逻辑，而是将传输层功能从操作系统内核移至应用层实现，使应用程序直接掌握变更控制权。原文未给出具体部署规模数据。
TCP 多路复用的固有缺陷：
现代网页包含图像、脚本、样式表等多个独立对象。早期 HTTP 为每个对象建立新 TCP 会话并叠加 TLS 握手，开销显著。后续复用单一 TCP 会话虽减少握手，但多路复用的逻辑流在同一 TCP 连接中共享拥塞窗口与丢包重传队列，任一流阻塞会导致同连接内所有排队流被阻塞，即头阻塞问题。TCP 为此类场景提供了较差的支撑。
QUIC 的架构取舍：
QUIC 在单一 UDP 连接上承载多路复用流，每条流独立流控与重传，消除头阻塞。同时将 TLS 1.3 集成至握手过程，实现 0-RTT 恢复与加密保护的统一。代价是需在用户态实现可靠传输、拥塞控制与丢包恢复，增加应用层复杂度，且依赖 UDP 穿透中间设备的能力。原文未给出具体性能对比数据。
对运维与网络工程师而言，QUIC 将传输特性从内核剥离意味着协议迭代不再依赖操作系统升级周期，排查时需关注 UDP 443 端口的流量特征而非传统 TCP 状态机，防火墙与 QoS 策略需同步适配基于连接 ID 的会话识别。
原文: APNIC Blog（2022-07-11）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog