QUIC协议与传统TCP的差异
日常上网时，加载网页、看视频、刷短视频，背后都依赖网络传输协议。以前大多数场景用的是TCP，但近年来QUIC协议越来越常见。比如你在手机上用Chrome打开一个网站，浏览器开发者工具里可能就显示连接用的是QUIC。它最大的变化之一，就是把拥塞控制从操作系统内核移到了用户空间。
TCP的拥塞控制由操作系统实现，升级算法得等系统更新，非常麻烦。而QUIC基于UDP，把整个传输逻辑放到应用层，开发者可以自由调整拥塞策略，不用依赖系统版本。这就像是原本只能靠红绿灯指挥车流，现在每个司机都能根据路况实时调整速度，更灵活。
QUIC如何判断网络拥堵
拥塞机制的核心是“别发太快，别把网络堵死”。QUIC通过几个关键信号来判断：丢包、延迟变化、确认应答（ACK）的到达时间。比如你在家连Wi-Fi看直播，突然视频卡住开始转圈，很可能就是网络出现了丢包或延迟激增。
QUIC会持续测量数据包发出到收到ACK的时间差，这个叫RTT（往返时间）。如果RTT突然变长，说明路径上可能有排队，路由器缓存满了，数据在等。这时候QUIC就会主动降低发送速率，避免雪上加霜。
常用的拥塞控制算法
Google最初为QUIC设计了名为BBR（Bottleneck Bandwidth and RTT）的算法。它不像传统算法靠丢包来判断拥堵，而是建模网络路径的带宽和最小延迟，主动探测最大吞吐能力。就像开车时不是等到堵车才减速，而是提前根据道路宽度和限速设定合理车速。
另一种常见的算法是Cubic，它是Linux中TCP默认使用的拥塞控制方式，也被移植到了部分QUIC实现中。Cubic更依赖丢包作为信号，一旦发现丢包，立刻大幅降速，之后缓慢试探恢复。
开发者可以在客户端代码中指定使用哪种算法，例如：
<!-- 伪代码示意 -->
quic_config.set_congestion_control_algorithm(BBR);
// 或者
quic_config.set_congestion_control_algorithm(Cubic);实际体验中的好处
当你在地铁上切换基站，网络来回跳动，传统TCP可能要几百毫秒才能重新建立稳定连接，而QUIC因为连接迁移能力强，加上灵活的拥塞控制，能更快恢复传输。你看视频时少卡顿，上传照片也更稳。
再比如多个标签页同时加载资源，QUIC可以为每个流独立管理流量，不会因为一个请求慢而拖累全部。这背后也有拥塞机制的精细调节在起作用。
现在的HTTP/3默认用QUIC，越来越多网站开启支持。下次你看到浏览器地址栏旁出现一个小闪电图标，那很可能就是QUIC在默默优化你的网络体验。