[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fZhu165AGgHeRY_98jHFxunexLUgNMRvYIurvZetBwDo":3},{"item":4,"related":34},{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":18,"sourceLabel":17,"sourceName":17,"sourceUrl":17,"status":27,"seoTitle":17,"seoDescription":17,"canonicalUrl":17,"isFeatured":28,"sno":29,"sortOrder":30,"publishedAt":31,"updatedAt":32,"createdAt":33},"88e5ea58-d373-46ae-8ed1-ba0abf2a11b2","article","HTTP\u002F3 与 QUIC：为什么互联网要把传输层重造一遍","http3-quic-explained","地铁里信号时好时坏，视频却还能续上——一部分功劳属于 HTTP\u002F3 和它脚下的 QUIC。","你在地铁里刷视频，信号时好时坏，画面却还能勉强续上；而几年前同样的网络下，网页可能直接卡死。\n\n这背后的一部分功劳，属于一个重造了互联网传输底层的协议——HTTP\u002F3，以及它脚下那块新地基 QUIC。本文用最直白的方式，讲清它们为什么要「重造轮子」，以及带来了什么。\n\n## 老协议的「队头阻塞」\n\n先说清概念。你访问网页时，数据要经过「传输层协议」来保证可靠送达。几十年来这一层用的是 TCP。TCP 很可靠，但有个老毛病叫「队头阻塞」（head-of-line blocking）：数据被拆成一个个包按顺序传，只要中间有一个包丢了，后面的包即使已经到了，也得排队等它重传——就像一列纵队里第一个人摔倒，后面所有人都得停下。\n\n在网络不稳定（丢包多）的移动场景下，这个问题尤其致命。HTTP\u002F2 虽然能在一个连接里并行传多个请求，但它仍然跑在 TCP 上，一个包丢失会拖累这个连接上的所有请求。\n\n## QUIC：在 UDP 上重建可靠传输\n\nHTTP\u002F3 的关键，是换掉了脚下的地基：它不再用 TCP，而是用一个叫 **QUIC** 的新协议，QUIC 建立在 UDP 之上。UDP 本身不保证可靠，但 QUIC 在它上面重新实现了可靠传输，并顺手解决了老问题：\n\n- **消除队头阻塞**：QUIC 把不同的请求放进各自独立的「流」（stream），一个流丢包只影响它自己，不拖累其它流。\n- **连接建立更快**：QUIC 把加密（TLS）和连接握手合并，减少往返次数，首次连接更快，重连甚至可以「0-RTT」几乎瞬间恢复。\n- **连接迁移**：连接由一个独立的「连接 ID」标识，而不绑定你的 IP。所以你从 Wi-Fi 切到 4G，连接不会断——这正是地铁里视频能续上的原因。\n\n```mermaid\nflowchart TD\n    A[HTTP\u002F3 请求] --> B[QUIC 协议]\n    B --> C[UDP]\n    B --> D[独立的多条 Stream]\n    D --> E[某条流丢包\u003Cbr\u002F>只重传该流]\n    D --> F[其它流照常推进\u003Cbr\u002F>无队头阻塞]\n    B --> G[连接 ID 标识\u003Cbr\u002F>Wi-Fi↔4G 不断线]\n```\n\n## 该怎么用\n\n好消息是：绝大多数情况下，你几乎不用改业务代码。HTTP\u002F3 主要在「基础设施层」启用——CDN、反向代理（如 Nginx、Caddy）、云负载均衡器开启支持即可，浏览器会自动协商使用。\n\n以 Caddy 为例，它默认就支持 HTTP\u002F3，几乎零配置：\n\n```caddyfile\nexample.com {\n    reverse_proxy localhost:8080\n    # Caddy 默认自动启用 HTTP\u002F3（基于 QUIC \u002F UDP 443）\n}\n```\n\n要让它生效，记得在防火墙\u002F安全组放行 **UDP 443**（而不只是 TCP 443）——这是最常见的「开了却没生效」的坑。浏览器首次仍可能走 HTTP\u002F2，随后通过 `Alt-Svc` 响应头得知服务端支持 HTTP\u002F3，再自动升级。\n\n## 取舍与边界\n\n- **UDP 可能被拦**：部分企业网络或老旧设备会限制 UDP，此时会自动回退到 HTTP\u002F2，属正常降级。\n- **CPU 开销**：QUIC 的加密和拥塞控制在用户态实现，早期 CPU 占用偏高，近年已大幅优化，但高流量服务仍要评估。\n- **收益看场景**：在稳定的有线网络里，HTTP\u002F3 相比 HTTP\u002F2 的提升未必明显；它的优势在**弱网、高丢包、移动**场景最突出。\n- **它是传输层升级**：解决的是「怎么把数据更快更稳地送到」，不改变你的应用逻辑。\n\n## Tips\n\n- 面向移动端或全球用户的服务，优先在 CDN \u002F 反向代理层开启 HTTP\u002F3。\n- 开启后务必放行 UDP 443，否则会「配置了却回退到 HTTP\u002F2」。\n- 别期待有线稳定网络下有巨大提升，它的主场是弱网和移动场景。\n- 保留 HTTP\u002F2 作为回退，兼容那些屏蔽 UDP 的网络环境。\n- 记住三大红利：消除队头阻塞、更快建连、Wi-Fi 与蜂窝切换不断线。","https:\u002F\u002Fimages.unsplash.com\u002Fphoto-1451187580459-43490279c0fa?w=1200",[],[],"Foundit AI","https:\u002F\u002Ffoundit.cn","f39339b1-aaa6-4e86-b0c2-a6e6a21113b5",null,[19,23],{"id":20,"name":21,"slug":22},"7c76bfc2-f80f-4ee0-a95d-27bd8708b434","技术","slug",{"id":24,"name":25,"slug":26},"4c2bbea6-eab7-40a8-8447-1de478ff7749","分析","analyse","published",false,76,0,"2026-07-19T00:00:00.000Z","2026-07-20T01:08:35.440Z","2026-07-19T17:10:58.328Z",[35,45,53],{"id":36,"type":6,"title":37,"slug":38,"summary":39,"coverUrl":40,"authorName":41,"sno":42,"publishedAt":43,"createdAt":44},"d6ff32b0-f499-453a-b1e3-c31a4a7a5b16","布隆过滤器：系统如何快速判断一个东西肯定不存在","bloom-filter-probabilistic-membership-explained","布隆过滤器用位数组和多个哈希函数，以极少内存快速筛掉肯定不存在的对象。本文讲清误报与漏报、误报率、删除难题，以及它在缓存、数据库和去重系统中的正确用法。","\u002Fuploads\u002F2026-08-06\u002F234915f6-2ef2-4820-8523-1a98544732f9.jpg","Foundit",61,"2026-08-06T00:00:00.000Z","2026-08-06T05:38:25.381Z",{"id":46,"type":6,"title":47,"slug":48,"summary":49,"coverUrl":50,"authorName":41,"sno":51,"publishedAt":43,"createdAt":52},"23cd6a50-6716-4620-99f3-d5307511c8ee","CRDT：两个人同时改同一段文字，为什么不会互相覆盖","crdt-collaborative-editing-explained","CRDT 允许多个副本先本地修改，再通过可合并的数据结构最终收敛。本文用计数器和协同编辑讲清 CvRDT、CmRDT、并发插入、删除标记、元数据成本与业务语义冲突。","\u002Fuploads\u002F2026-08-06\u002F50641649-08d8-4cac-94f0-647eabe9fc5f.jpg",62,"2026-08-06T05:38:23.928Z",{"id":54,"type":6,"title":55,"slug":56,"summary":57,"coverUrl":58,"authorName":41,"sno":51,"publishedAt":43,"createdAt":59},"a04c10a4-3fe8-4537-81bd-354103c1078f","WebGPU：浏览器为什么能跑 3D、滤镜和部分 AI","webgpu-browser-gpu-computing-explained","WebGPU 让网页能更直接地使用 GPU 做渲染与通用计算。本文从 CPU 与 GPU 的分工讲起，拆解适配器、设备、缓冲区、WGSL 着色器和命令队列，并说明什么时候并行计算真的值得。","\u002Fuploads\u002F2026-08-06\u002F05f26f06-cda2-4ed3-b1f2-5f26c82c2a37.jpg","2026-08-06T05:38:22.834Z"]