HTTP1、HTTP2、HTTP3
HTTP1.1 的缺陷
| 缺陷类型 | 具体表现 | 行业临时解决方案 |
|---|---|---|
| 队头阻塞 | 单 TCP 连接内请求串行执行，一个请求阻塞则后续全阻塞；浏览器单域名仅允许 6~8 个 TCP 连接 | 1. 多域名分片（如静态资源放不同域名）2. 合并小文件 / 精灵图 / 内联资源3. 减少请求数 |
| 无状态低效 | 1. 每次请求无上下文记忆，依赖 Cookie 补充状态2. Header 重复且体积大，传输成本高 | 1. 启用 Cookie/ Session2. 压缩 Header（非标准化）3. 减少重复 Header 字段 |
| 安全性差 | 明文传输，无身份验证，数据易被窃听 / 篡改 | 基于 HTTPS（HTTP+TLS）改造 |
| 功能局限 | 仅支持 "请求 - 应答" 模式，无服务端主动推送能力 | 前端预加载、长轮询模拟推送 |
记忆口诀：队头阻塞高延迟，无状态传参繁，明文传输不安全，服务推送不支持。
HTTP 1.1 排队问题
HTTP 1.1多个文件共用一个TCP，这样可以减少tcp握手，这样3个文件就不用握手9次，不过这样请求文件需要排队，请求和返回都需要排队， 如果第一个文件响应慢，会阻塞后面的文件，这样就产生了对头的等待问题。
有的网站可能会有很多文件，浏览器处于对机器性能的考虑，它不可能让你无限制的发请求建连接，因为建立连接需要占用资源，浏览器不想把用户的网络资源都占用了，所以浏览器最多会建立6个tcp连接；如果有上百个文件可能都需要排队，http2.0正在解决这个问题。
HTTP/1.1 有什么问题？
- 一个 TCP 连接，同一时间只能处理一个请求
- 想并发？只能开 多个 TCP 连接（浏览器一般 6～8 个）
- 队头阻塞：一个请求卡住，后面全卡住
SPDY 协议与 HTTP/2 简介
1、HTTP/2 简介
HTTP/2是现行HTTP协议（HTTP/1.x）的替代，但它不是重写。**HTTP/2基于SPDY，**单 TCP 连接支撑全量请求，最大化带宽利用率。
2、HTTP/2 新特性
| 特性 | 核心作用 | 技术细节 |
|---|---|---|
| 二进制帧传输 | 替代明文报文，解析效率提升，为多路复用铺路 | 将请求 / 响应拆分为 "帧（Frame）"，按帧编号识别归属，二进制编码更高效 |
| Header 压缩（HPACK） | 解决 Header 体积大、重复传输问题 | 1. 客户端 / 服务端共建 "静态字典 + 动态字典"，重复字段用索引号替代2. 哈夫曼编码压缩字符串 / 整数，压缩率 50%~90% |
| 多路复用 | 彻底解决 HTTP 层队头阻塞，单 TCP 连接并发多请求。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题，同时也更容易实现全速传输。 | 多请求的帧可乱序传输，接收端按帧编号重组，无需排队 |
| 服务器推送（Server Push） | 主动推送客户端需要的资源（如 CSS/JS），减少请求次数 | 服务端预判客户端需求，在响应主请求时主动推送关联资源，避免二次请求 |
| 兼容加密 | 不强制加密，但主流浏览器仅支持加密版，明文版几乎不用。HTTP/2协议定义了两个字符串标识符："h2"表示加密的HTTP/2，"h2c"表示明文的HTTP/2。 | 加密版基于 TLS 运行，延续 HTTPS 安全特性 |
HTTP/2 多路复用到底是什么？
同一个 TCP 连接里，同时并发传输多个 HTTP 请求 / 响应，互不阻塞、不用排队。 HTTP/2 多路复用让一条连接并发所有请求，大大减少握手次数。
HTTP/2多路复用原理图：
HTTP/2完整时序流程图：
HTTP/2 多路复用解决了什么？
- 只建立 1 条 TCP 连接
- 在这条连接里，把数据切成二进制帧（frame）
- 多个请求的帧乱序传输、同时发送
- 接收端再按编号重新组装
- 真正做到并发，不排队、不阻塞
HTTP/2 未解决的核心问题(主要是TCP协议造成)
- TCP 层队头阻塞：HTTP/2 仅解决 HTTP 层阻塞，若 TCP 数据包丢失，整个 TCP 连接需等待重传，所有流均阻塞；
- 连接建立延迟：仍需先 TCP 三次握手，再 TLS 握手（1~3RTT），首次连接耗时高；
- 服务器压力：多路复用易导致单连接承载过高请求，增加服务器资源调度压力。
补充：TC P 握手 和 TLS 握手会阻碍吗？
不会，是按照固定顺序：
- 先 TCP 三次握手建立可靠连接
- 再 TLS 握手加密协商、证书验证、生成 AES 密钥
- 最后才开始 HTTP 通信
拓展：TLS握手核心流程（混合加密流程）
- 客户端 → 服务端：我要连，给我你的加密套件、随机数 C
- 服务端 → 客户端：同意，给你证书、随机数 S
- 客户端验证证书合法
- 客户端生成「预主密钥 PMS」 用服务端公钥加密 PMS 发给服务端
- 两端都用 C + S + PMS 算出相同的 AES 会话密钥
- 之后所有通信：全部 AES 对称加密
TLS 就是：用非对称加密 + 证书，安全交换出一把临时 AES 密钥，之后全程 AES 加密。
HTTP/3 新特性：
1、HTTP/3简介
Google 在推SPDY的时候就搞了个基于 UDP 协议的"QUIC"协议，让HTTP跑在QUIC上而不是TCP上。而"HTTP over QUIC"就是HTTP/3，真正"完美"地解决了"队头阻塞"问题。
QUIC 基于 UDP重构传输层，解决 TCP 层队头阻塞，优化连接建立速度。并且在原本的基础上新增了很多功能。
2、QUIC新功能
QUIC基于UDP，而UDP是"无连接"的，不需要"握手"和"挥手"，所以就比TCP快。此外QUIC也实现了可靠传输，保证数据一定能够抵达目的地。它还引入了类似HTTP/2的"流"和"多路复用"，单个"流"是有序的，可能会因为丢包而阻塞，但其他"流"不会受到影响。具体来说QUIC协议有以下特点：
| 能力 | 核心作用 | 对比 TCP/TLS 优势 |
|---|---|---|
| 可靠传输 | 在 UDP 基础上实现 TCP 的核心能力（重传、拥塞控制、流量控制） | 保留 UDP 无连接的灵活性，同时保证数据可靠抵达 |
| 0-RTT/1-RTT 快速握手 | 首次连接 1-RTT 建立，复用连接 0-RTT 完成加密协商（由于QUIC是基于UDP的，所以QUIC可以实现使用0-RTT或者1-RTT来建立连接，即QUIC可以用最快的速度来发送和接收数据，大大提升首次打开页面的速度） | 对比 TCP+TLS 的 3~4RTT，首次连接延迟降低 60%+ |
| 集成 TLS 1.3加密功能 | 加密功能内置到 QUIC，无需单独 TLS 握手（TLS握手详述见上文） | 减少握手步骤，提升安全性（无明文握手阶段） |
| 真正的多路复用，解决TCP队头阻塞问题 | 每个流独立传输，单个流丢包仅影响自身，不阻塞其他流 | 彻底解决 TCP 层队头阻塞（HTTP/2 的核心痛点） |
| 连接迁移 | 用 Connection ID 标识连接，而非 IP + 端口（客户端的自动加密验证只要 Connection ID 不变，连接就不需要重新建立，即便是客户端的网络发生变化。由于迁移客户端继续使用相同的会话密钥来加密和解密数据包，QUIC 还提供了迁移客户端的自动加密验证） | 网络切换（如 WiFi→5G）时无需重建连接，保持会话连续性 |
HTTPS = TCP → TLS → HTTP/2 是一层层叠上去的。
三代核心对比：
| 特性 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 传输单元 | 明文报文 | 二进制帧 | QUIC 流（基于 UDP） |
| 队头阻塞 | HTTP 层严重 | 解决 HTTP 层，TCP 层仍存在 | 彻底解决（QUIC 流隔离） |
| 连接模型 | 多 开TCP 连接（6~8 个 / 域名）并行 | 单 TCP 连接并行 | 单 QUIC 连接（UDP） |
| 握手延迟 | TCP 3RTT | TCP 3RTT + TLS 1~3RTT | 0/1 RTT |
| Header 处理 | 明文、无标准化压缩 | HPACK 压缩 | HPACK 压缩（兼容） |
| 服务端推送 | 不支持 | 支持 | 支持 |
| 连接迁移 | 不支持 | 不支持 | 支持（Connection ID） |
总结回顾：
- HTTP/1.1：解决 HTTP/1.0 短连接问题，但性能瓶颈（队头阻塞、低效传输）和安全问题突出；
- HTTP/2完全兼容HTTP/1，是"更安全的HTTP、更快的HTTPS"，在 TCP 基础上优化 HTTP 层，解决 HTTP 层队头阻塞、低效传输问题，但受制于 TCP 协议本身；二进制传输、头部压缩、多路复用、服务器推送等技术可以充分利用带宽，降低延迟，从而大幅度提高上网体验；
- HTTP/2 的核心价值二进制传输 + HPACK 压缩 + HTTP 层多路复用，但未解决 TCP 层队头阻塞；
- QUIC 基于 UDP 实现，是 HTTP/3 中的底层支撑协议，该协议基于 UDP，又取了 TCP 中的精华，实现了即快又可靠的协议，彻底解决 TCP 层队头阻塞，优化连接速度和网络适应性，实现了 0-RTT 握手、真正的多路复用和连接迁移。
- 三代协议的演进核心逻辑：从解决应用层性能问题，到重构传输层彻底解决底层阻塞问题。