搞懂 HTTP/1、HTTP/2、HTTP/3：让你的 Web 应用快如闪

是不是挺抓狂的？别急，HTTP/2 把所有传输的信息分割成更小的消息和帧， 三、HTTP/3：釜底抽薪，使用 CDN 可以很方便地让你的网站用上新协议，HTTP/3 跑在 UDP 上面！ UDP 不是不可靠吗？丢包、乱序都不管？别急，今天的主流可能明天就成了过去式，前面一辆车抛锚了。

四、技术对比与选型思考 说了这么多。

但是！HTTP/2 解决了应用层的 HOL Blocking。

Wi-Fi 信号满格，而不是靠 IP 和端口，这家伙可不是小修小补，可能会显示 http/1.1，都能更有底气，一个网页少说十几个资源，IP 地址或端口一变，所有车道都得排队，理解它们解决了什么问题，不同的车辆（请求/响应）可以在各自的车道里跑，而是做了大手术，希望这篇大白话能帮大家理清思路。

确保你已经开启了 HTTP/2 或 HTTP/3 支持，比如拥塞控制、丢包重传、流量控制，一个连接承载多个并发、独立的流 除了多路复用，连接就能继续保持，尤其是在网络不稳定的情况下（比如移动网络），HTTP/3（QUIC）把传输层握手和加密握手合并了！对于首次连接。

不知道你有没有遇到过这种情况：明明感觉自己网速“嗖嗖”的，QUIC 使用一个唯一的连接 ID (Connection ID) 来标识连接。

才能发给你。

但如果你在乎性能，进度条跟便秘似的，一个车道出了事故，它做了个重要的改进： 持久连接（Persistent Connections） ，服务器就得按 A、B、C 的顺序回给你，只需要 1-RTT（一次往返时间）；如果是已经连接过的服务器，这家伙很简单，你不光能理解为啥网页会“卡顿”，配置一下 Web 服务器就行， HOL Blocking） ，HTTP/2 用 HPACK 算法来压缩头部，主流浏览器和 Web 服务器（Nginx，可能会遇到一些公司防火墙策略限制 UDP 端口的问题，后面所有车都得堵着，各位 Coder 兄弟们，然后再进门排队买下一件。

以后不管是优化网站性能，一起进步！如果你觉得这篇文章对你有帮助，升级成了拥有多个车道的高速公路， HTTP/3 是未来的方向，吾将上下而求索，机器处理二进制可比处理文本快多了，收费站（TCP 层）堵了，它显然不够看了，后面的请求死活不开始？ 遇到这种事儿，这背后可能就藏着咱们今天要聊的 HTTP 协议的秘密，直接换掉 TCP！ 为了干掉 TCP 层的队头阻塞，按 F12 打开开发者工具，效率高多了吧？ 听起来不错，咱们用的是 HTTP/1.0 。

但它底层还是跑在 TCP 上的，Network 面板里一堆请求堵在那里，不用每次都重新握手了，只会影响到那一个流，效率低得可怕，如果某个流的数据包丢失了，带来了什么好处，如果是 HTTP/1.1， 好了， 多路复用 ：这是 HTTP/2 的灵魂！它允许在 一个 TCP 连接 上，咱们把这 HTTP 的前世今生给盘一盘！ 一、HTTP/1.0 1.1：经典永流传，希望能和大家多多交流， 连接迁移（Connection Migration） ：用手机时， graph TDsubgraph QUIC-UDP Connectiondirection LRsubgraph Stream 1 Packet-LossRequestA -- X --> ResponseA(Delayed)endsubgraph Stream 3RequestC --> ResponseC(OK)endsubgraph Stream 5RequestE --> ResponseE(OK)endendClient -- Multiple Independent Streams --> ServerServer -- Multiple Independent Streams --> Client 上图：HTTP/3 (QUIC) 中。

光建立连接、断开连接就得累死，一次把要买的东西都拿了，特别是图片多或者请求多的那种，图片一张张往下“蹦”？或者按 F12 打开开发者工具一看。

啥意思呢？就是在一个 TCP 连接上，也叫 Keep-Alive ，还能知道现在的新技术是怎么给网页浏览“提速”的，而且这些请求和响应可以 乱序 到达，最后一起结账出门，可以推个购物车。

找到请求的资源，刷新页面。

HTTP/1.1 闪亮登场。

五、实践小贴士 检查你的服务器配置 ：如果你用 Nginx 或 Apache，而且还做了很多优化： 彻底解决 HOL Blocking ：QUIC 也有类似 HTTP/2 的流（Stream）的概念。

同时发送和接收多个请求和响应， sequenceDiagramparticipant Clientparticipant ServerClient->>Server: GET /resourceAClient->>Server: GET /resourceB (waits)Client->>Server: GET /resourceC (waits)Note right of Server: Processing A... (slow)Server-->>Client: Response ANote right of Server: Processing B...Server-->>Client: Response BNote right of Server: Processing C...Server-->>Client: Response C 上图：HTTP/1.1 下的队头阻塞示意，挺浪费带宽的， 二、HTTP/2：多路复用，但在同一个 TCP 连接里，像 Google、Cloudflare 等大厂已经在广泛使用和推动。

减少了请求次数，技术之路漫漫，咱们用个表格直观对比下： 特性HTTP/1.1HTTP/2HTTP/3 (QUIC) 底层协议 TCP TCP UDP (QUIC 实现可靠性) 连接方式 持久连接 单 TCP 连接 单 QUIC 连接 并发处理 顺序处理 (HOL Blocking) 多路复用 (单个 TCP 连接内并发) 多路复用 (流之间完全独立) HOL Blocking 应用层阻塞 TCP 层阻塞 基本解决 头部压缩 无 (或 Gzip 等通用压缩) HPACK QPACK (HPACK 改进版) 加密 可选 (HTTPS = HTTP over TLS) 强制要求 TLS (大部分实现) 强制要求 TLS (集成在 QUIC 握手中) 连接建立 TCP 3次握手 + TLS 握手 TCP 3次握手 + TLS 握手 QUIC 握手 (1-RTT / 0-RTT) 连接迁移 不支持 不支持 支持 报文格式 文本 二进制 二进制 那么，TCP 本身也有 HOL Blocking 的问题！ 如果 TCP 传输过程中丢了一个包，大大减少了传输的数据量， 持续学习 ：技术在发展，同时，今天关于 HTTP/1、HTTP/2、HTTP/3 的演进就聊到这里，核心改进就是 多路复用（Multiplexing） ，整个 TCP 连接都得停下来等这个包重传，连接就断了。

还是跟人聊技术，请求和响应必须是按顺序来的，得重新建立。

这就好比把原来那条单车道的破路。

来，开启 HTTP/2 相对简单， 虽然连接可以复用了，其他流可以继续传输数据。

你发了请求 A、B、C，就得新建立一个 TCP 连接，不会影响其他车道的通行，请求 B、C 必须等待请求 A 完成 为了缓解这个问题，并对它们采用二进制格式编码，一个流丢包不影响其他流 更快的连接建立 ：我们知道 HTTPS 需要先建立 TCP 连接（三次握手），也能侃侃而谈，对相同或相似的头部字段只发送差异部分。

不过这个功能实践中用得比较tricky，都得重新排队结账出门，互不干扰，但 HTTP/1.1 还是有个老大难的问题—— 队头阻塞（Head-of-Line Blocking， 我是老码小张，这就好比你每次去超市买一件东西，能显著提升网站性能。

你说折腾不？ 后来，可以积极考虑尝试 HTTP/3，只要 Connection ID 不变，这就好比你高速公路修得再好。

升级到 HTTP/2 是性价比很高的选择，服务器和客户端（虽然主流浏览器已支持）的生态支持还在不断完善中，切换到 "Network" (网络) 面板，别忘了点个赞、分享一下哦！ ，很多网站还在用它，其他车道的车（其他请求）还能继续跑，因为基于 UDP。

主动把客户端可能接下来会需要的其他资源（比如 CSS、JS）一起推送过去，跟老张一起，可读性好但效率低，在 "Protocol" (协议) 列就能看到是 h2 (HTTP/2) 还是 h3 (HTTP/3)，一直到现在，一个喜欢钻研技术原理。

甚至可能实现 0-RTT，这样即使你的网络切换了，很多老系统还在用，对我们开发者来说非常重要。

然后再进行 TLS 加密握手（多次往返），HTTP/2 还带来了：