直接回答：HTTP/2 的多路复用跑在单条 TCP 上，传输层队头阻塞未解——一个 TCP 段丢失，所有流等重传。QUIC 把传输层搬进用户态（UDP 之上）：流独立排序与重传（单流丢包不阻塞他流）、内建 TLS 1.3（握手与传输握手合一，1-RTT 建连，会话复用可 0-RTT）、连接以 Connection ID 标识（IP 切换不断连——WiFi 切 4G 无感迁移）。
展开解析：展开三个机制：流独立性——QUIC 的可靠性与排序按流维护，丢包重传只影响所属流，页面里慢资源不再拖累全站（H2 时代为规避队头阻塞反而拆多连接的畸形优化终结）；0-RTT——首次连接缓存服务器配置与会话票据，二次连接首包即带加密应用数据，省一整个 RTT（移动网络 100ms+ 场景体感明显），代价是重放风险——0-RTT 数据无防重放保护，服务端要限制只放幂等请求（GET）并做应用层去重；连接迁移——QUIC 包不绑定四元组而绑定 CID，NAT 重绑定或网络切换后客户端继续发包即无缝迁移，服务器按 CID 找会话状态——移动场景的核心卖点，也带来负载均衡难题（四元组哈希失效，LB 要按 CID 路由或用一致哈希前缀）。代价与现实：用户态协议栈吃 CPU（内核旁路的 UDP GRO/GSO 优化在追赶）、运营商 UDP 限速与封锁的历史包袱（QUIC 回落 H2 的 happy eyeballs 策略）、抓包调试困难（全加密，qlog 工具链）。部署现状：Google/Meta/Cloudflare 大流量入口已默认开 H3，收益集中在弱网与移动端——桌面好网络下提升有限，这是“面向长尾体验”的优化。
追问方向：QUIC 为什么在用户态实现而不是改内核 TCP？0-RTT 的重放攻击场景与防御？
（约 500 字）