[{"data":1,"prerenderedAt":69},["ShallowReactive",2],{"article-158":3},{"code":4,"msg":5,"data":6,"count":14},200,"查询成功",{"id":7,"title":8,"keywords":9,"description":10,"category_id":11,"content":12,"body_html":13,"thumb_up":14,"clicks":15,"sort":14,"remark":13,"status":11,"is_open":11,"is_deleted":14,"is_top":11,"is_recommend":11,"create_time":16,"update_time":17,"image_id":18,"url":13,"member_id":14,"cate_name":19,"prev":20,"next":23,"tags":26,"words":40,"read_time":41,"comments":14,"cover":42,"relevant":43},158,"HTTP\u002F3 的 QUIC 基于 UDP，为什么仍然可靠？","HTTP\u002F3, QUIC, UDP, 可靠传输, 网络协议","QUIC 并不是裸用 UDP，而是在 UDP 之上实现确认、丢包恢复、流量控制、拥塞控制、加密握手、多路复用和连接迁移。理解这 7 点，才能把 HTTP\u002F3 的可靠性讲清楚。",1,"## 先说结论\n\n面试官问“HTTP\u002F3 的 QUIC 基于 UDP，那它是不是不可靠？”时，最危险的回答是直接说“UDP 不可靠，所以 QUIC 也不可靠”。\n\n更准确的回答是：QUIC 使用 UDP 作为承载层，但并不是把业务数据裸奔在 UDP 上。UDP 只负责尽力投递数据报，真正的连接管理、确认应答、丢包检测、重传、流量控制、拥塞控制、加密握手和连接迁移，都是 QUIC 自己在协议层实现的。\n\n所以 HTTP\u002F3 不是牺牲可靠性换性能，而是在保留可靠传输能力的前提下，减少连接建立延迟，并缓解 TCP 在多路复用场景下的队头阻塞。\n\n## 为什么“基于 UDP”不等于“不可靠”\n\nUDP 本身确实不保证可靠投递：它不保证数据一定到达，不保证顺序，也不负责重传。但协议栈的能力不是只能放在内核里的 TCP 层实现。QUIC 的设计思路是：把 UDP 当成一个更容易穿透网络设备的承载通道，然后在 QUIC 层重新定义可靠传输所需的状态机。\n\n这也是面试里应该讲清楚的第一层逻辑：\n\n- UDP 提供的是数据报承载能力。\n- QUIC 提供的是面向连接的可靠传输能力。\n- HTTP\u002F3 使用 QUIC 作为传输层，而不是直接使用裸 UDP。\n\n换句话说，QUIC 的可靠性不是 UDP 送的，而是 QUIC 自己补上的。\n\n## 保障一：包编号和 ACK，知道哪些包到了\n\nTCP 依靠序列号和 ACK 来判断字节流是否被对端确认。QUIC 也有自己的确认机制，但它用的是 packet number，也就是包编号。\n\n发送方发出的 QUIC 包会带有包编号。接收方收到后，通过 ACK frame 告诉发送方哪些包已经收到。这样即使底层 UDP 不提供确认，QUIC 仍然可以维护自己的发送状态和接收状态。\n\n这一步解决的是“可观测性”问题：发送方不能只管发，还要知道哪些数据已经被对端确认，哪些数据长时间没有确认。\n\n## 保障二：丢包检测和重传，丢了不会无声消失\n\n有了包编号和 ACK，QUIC 就可以判断丢包。比如发送方发出 1、2、3、4、5 号包，接收方确认了 1、2、4、5，却迟迟没有确认 3，发送方就可以根据包阈值、时间阈值和 RTT 估计判断 3 号包可能丢了。\n\n这里有一个很重要的细节：QUIC 重传的通常不是“原始 UDP 数据报本身”，而是丢失包里承载的可重传 frame 数据。它可以把这些 frame 重新装进新的 QUIC 包里再发送，并分配新的 packet number。\n\n这个设计比“把原包原样再发一遍”更灵活。因为网络状态、加密级别、拥塞窗口、发送队列都可能已经变化，重新打包能让 QUIC 更好地配合当前连接状态。\n\n![](https:\u002F\u002Ftp.myong.top\u002Fstorage\u002Fmarkdown\u002F20260630\u002F084184fb29d3e76bc89d0be4a39afb33.png)\n\n\n## 保障三：多 Stream 独立排序，缓解队头阻塞\n\nHTTP\u002F2 已经支持在一个连接里多路复用多个请求，但它底层仍然依赖 TCP。TCP 暴露给上层的是一个有序字节流，只要前面的 TCP 段丢了，后面的字节即使已经到达，也不能被上层越过使用。\n\n这就是 HTTP\u002F2 over TCP 很典型的传输层队头阻塞：一个包丢失，可能拖住同一条 TCP 连接上的多个 HTTP\u002F2 stream。\n\nQUIC 的处理方式不同。一个 QUIC connection 内可以承载多个 stream，每个 stream 有自己的偏移量、排序和重传逻辑。某个 stream 的数据丢了，主要影响这个 stream 自己；其他 stream 已经到达的数据，不必因为它停住。\n\n举个直观例子：同一条 QUIC 连接里，一个视频片段请求发生丢包，不应该拖住旁边一个接口请求的响应。QUIC 的多 stream 机制就是为这种场景降低相互影响。\n\n![](https:\u002F\u002Ftp.myong.top\u002Fstorage\u002Fmarkdown\u002F20260630\u002Fed37d1f96c90f0e3faa95e74cd54bcb3.png)\n\n## 保障四：连接级和 Stream 级流量控制，防止接收端被打爆\n\n可靠传输不只是“丢了重发”，还要防止发送方发得太快，把接收方缓冲区撑爆。QUIC 提供两层流量控制：\n\n- 连接级流量控制：限制整个 connection 上最多可以发送多少未被接收方允许的数据。\n- Stream 级流量控制：限制单个 stream 最多可以发送多少数据。\n\n这两层控制解决的问题不一样。连接级限制保护整个连接的接收资源；stream 级限制防止某一个大流量 stream 抢占所有缓冲区。\n\n面试时可以把它总结成一句话：QUIC 不仅要保证数据能到，还要保证发送方不能不受控地把接收方压垮。\n\n## 保障五：拥塞控制，防止把网络链路打爆\n\n流量控制保护的是接收端，拥塞控制保护的是网络链路。\n\nQUIC 会根据 ACK、丢包、RTT 等信号判断网络是否拥塞，并动态调整发送速率。网络状态好时，发送窗口可以扩大；出现丢包、延迟升高或拥塞信号时，发送方要收缩发送节奏。\n\n这点和 TCP 的工程目标相似：不能因为应用层想多发，就无限制地向网络灌数据。QUIC 的规范把丢包检测和拥塞控制独立成 RFC 9002，实际实现也可以采用不同算法，例如 Cubic、BBR 等。\n\n需要注意的是，拥塞控制不等于流量控制。前者看网络，后者看接收方，两者都属于 QUIC 可靠传输体验的一部分。\n\n## 保障六：默认集成 TLS 1.3，加密和握手合在一起\n\n传统 HTTPS 通常是先建立 TCP 连接，再进行 TLS 握手。QUIC 则把传输握手和 TLS 1.3 加密握手结合在一起，连接建立路径更短。\n\n这带来两个直接结果：\n\n第一，HTTP\u002F3 的连接建立延迟可以更低。尤其是在重复连接场景下，QUIC 可以利用 TLS 1.3 的能力缩短恢复连接所需的交互。\n\n第二，QUIC 默认加密，而且不只是加密业务数据。QUIC 的许多传输控制信息也受到保护，减少中间设备对协议行为的误判、篡改或僵化依赖。\n\n当然，加密本身不是“可靠投递”的同义词。它保障的是安全性、完整性和抗干扰能力；和 ACK、重传、流控、拥塞控制放在一起，才构成 HTTP\u002F3 更完整的传输体验。\n\n## 保障七：Connection ID，支持连接迁移\n\nTCP 连接通常依赖四元组识别：源 IP、源端口、目标 IP、目标端口。移动端从 Wi-Fi 切到蜂窝网络时，源 IP 和端口可能变化，原 TCP 连接往往就断了。\n\nQUIC 使用 connection ID 来识别连接。只要对端可以验证新的路径仍然属于同一个连接，IP 和端口变化并不必然导致连接中断。\n\n这就是 QUIC 连接迁移的价值。它不是让网络切换完全无感，也不是保证任何弱网都不会中断，而是给协议提供了“网络路径变化后继续复用原连接状态”的能力。对移动端、弱网和网络切换频繁的场景，这一点非常关键。\n\n![](https:\u002F\u002Ftp.myong.top\u002Fstorage\u002Fmarkdown\u002F20260630\u002F5d475ccf583485454c0f8671d11700f8.png)\n\n## 面试时怎么答\n\n如果面试官只要求一句话，可以这样回答：\n\n> QUIC 虽然基于 UDP，但它不是裸用 UDP，而是在 QUIC 层实现了可靠传输能力，包括 packet number 与 ACK 确认、丢包检测与 frame 重传、连接级和 stream 级流量控制、拥塞控制、多 stream 独立传输、TLS 1.3 默认加密，以及基于 connection ID 的连接迁移。\n\n如果面试官继续追问“那 QUIC 和 TCP 的可靠性有什么区别”，可以补一句：\n\n> TCP 保证的是单一有序字节流的可靠传输；QUIC 保证的是连接内多个 stream 的可靠传输，并把丢包恢复、加密握手和连接迁移做进了协议本身，所以它能在 HTTP\u002F3 场景下减少连接延迟和传输层队头阻塞。\n\n## 容易说错的点\n\n第一，不要说“QUIC 因为基于 UDP 所以不可靠”。UDP 不可靠，但 QUIC 自己实现了可靠传输机制。\n\n第二，不要说“QUIC 消灭了所有队头阻塞”。QUIC 缓解的是 TCP 传输层队头阻塞；单个 stream 内部仍然需要有序交付，应用层也可能有自己的依赖关系。\n\n第三，不要把流量控制和拥塞控制混为一谈。流量控制保护接收方，拥塞控制保护网络。\n\n第四，不要把 TLS 1.3 说成单纯的性能优化。它同时影响安全、握手、密钥派生和传输控制信息保护。\n\n第五，不要说“连接迁移只靠 connection ID 就一定成功”。Connection ID 是基础，真实迁移还需要路径验证、拥塞状态处理和实现层面的配合。\n\n## 最后记住这一句\n\nQUIC 的核心不是“UDP 比 TCP 快”，而是“用 UDP 承载，在 QUIC 层重新实现更适合 HTTP\u002F3 的可靠传输”：既保留确认、重传、流控和拥塞控制，又通过多 stream、TLS 1.3 和 connection ID 改善连接延迟、队头阻塞和移动网络切换体验。\n\n## 参考资料\n\n- [RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport](https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc9000.html)\n- [RFC 9001: Using TLS to Secure QUIC](https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc9001.html)\n- [RFC 9002: QUIC Loss Detection and Congestion Control](https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc9002.html)\n- [RFC 9114: HTTP\u002F3](https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc9114.html)\n",null,0,12,"2026-06-30 00:10:22","2026-06-30 00:10:23",215,"技术杂谈",{"id":21,"title":22},156,"Superpowers：把 AI 编程从提示词技巧升级成工程流程",{"id":24,"title":25},159,"百万在线 IM 已读未读怎么设计？",[27,29,31,34,37],{"id":7,"name":28},"计算机网络",{"id":24,"name":30},"程序员面试",{"id":32,"name":33},160,"HTTP3",{"id":35,"name":36},161,"QUIC协议",{"id":38,"name":39},162,"底层原理",3393,8,"https:\u002F\u002Ftp.myong.top\u002Fstorage\u002Farticle\u002F20260630\u002F79e6b956998d908a8e4c25b74722752f.png",[44,49,54,59,64],{"id":45,"title":46,"create_time":47,"description":48},89,"获取腾讯“邮我”的链接","2020-06-16 10:47:34","腾讯QQ邮箱提供了“邮我”组件，可以放在自己的网站上，让别人点击提供的图片或者链接就可以发Email过来，该文章分享的是如何获取到其中的链接。",{"id":50,"title":51,"create_time":52,"description":53},98,"本站点JavaScript相关特效使用方法整理","2021-04-22 18:38:53","本站的页面用的特效有，粒子线canvas-nest，动态彩带canvas-ribbon，鼠标点击特效以及音乐播放器，本文整理了特效的使用方法",{"id":55,"title":56,"create_time":57,"description":58},106,"阿里开源数据同步组件Canal","2023-10-26 22:43:32","最开始听说canal是从mysql与redis双写一致性解决方案，当时并没有太在意，最近由于需要实时同步数据，如果在代码对insert\u002Fupdate\u002Fdelete做拦截也可以实现，但对代码侵入性太大了，并且后期更改时容易有遗漏，风险太高，这时就又想到了canal，canal的好处在于对业务代码没有侵入，因为是基于监听binlog日志去进行同步数据，这个真的是太爽爽爽了。并且实时性也能做到准实时，这也是canal为什么这么流行，因为确实很多企业会用来做数据同步的方案。",{"id":60,"title":61,"create_time":62,"description":63},62,"内网使用Composer","2019-10-08 23:29:23","最近本地部署Laravel开发环境时，遇到公司的内网无法正常使用Composer下载Laravel，后来发现是要设置公司内网代理",{"id":65,"title":66,"create_time":67,"description":68},75,"Hexo-SEO优化开启静态文件压缩功能","2019-12-30 21:34:32","个人对HEXO搭建博客的SEO优化方案进行总结，从本地的文章结构到定期推送，再到SEO关键词优化做一个全面体系的汇总，如果有更好的方法可以私聊我。\n\n",1783431644619]