🌈个人主页:一条泥憨鱼(欢迎各位大佬莅临)
🎬精选专栏:数据结构与算法，Java ,AI与Agent
一、HTTP 是什么
浏览器怎么拿到网页的？
你打开 https://www.baidu.com，浏览器向百度服务器发一个请求，服务器把 HTML、CSS、JavaScript、图片这些东西传回来。这个一来一回的规则，就是 HTTP。
HTTP 是客户端和服务器之间约定的交流方式。
客户端想「我要首页」，HTTP 把它翻译成：
GET /index.html HTTP/1.1
Host: www.example.com
服务器回：
HTTP/1.1 200 OK
<html>
Hello World
</html>
二、版本演进概览
┌──────────┬──────────┬───────────────────────┐
│ 版本 │ 发布时间 │ 核心变化 │
├──────────┼──────────┼───────────────────────┤
│ HTTP/0.9 │ 1991 │ 只能传 HTML │
├──────────┼──────────┼───────────────────────┤
│ HTTP/1.0 │ 1996 │ 支持多种资源类型 │
├──────────┼──────────┼───────────────────────┤
│ HTTP/1.1 │ 1997 │ 长连接、Host 头、缓存 │
├──────────┼──────────┼───────────────────────┤
│ HTTP/2.0 │ 2015 │ 多路复用、二进制帧 │
├──────────┼──────────┼───────────────────────┤
│ HTTP/3.0 │ 2022 │ 基于 QUIC，不再用 TCP │
└──────────┴──────────┴───────────────────────┘
我们重点看 1.0 → 1.1 → 2.0 → 3.0 这条线。
三、HTTP/1.0：每个请求都得重新握手
HTTP/1.0 的最大毛病：一个请求一个 TCP 连接。
假设页面引用了 index.html、style.css、logo.png、main.js，浏览器的做法是：
建立 TCP 连接 → 请求 index.html → 关闭
建立 TCP 连接 → 请求 style.css → 关闭
建立 TCP 连接 → 请求 logo.png → 关闭
建立 TCP 连接 → 请求 main.js → 关闭
TCP 建立连接需要三次握手（SYN → SYN+ACK → ACK），每个文件都要走一遍这个流程。大量的时间不是花在传数据上，而是花在建立连接上。
HTTP/1.0 的贡献是让 HTTP 从只能传文字进化到能传图片、音频、视频、CSS、JS。它搭了个架子，但效率确实不行。
四、HTTP/1.1：一个连接可以复用
HTTP/1.1 最大的升级就一件事：长连接。
HTTP/1.0 的做法是请求一次、建一次连接、传完就关。HTTP/1.1 改成：建立一个 TCP 连接，在这个连接里连续发多个请求、收多个响应，最后再关。
建立 TCP 连接
请求 index.html → 响应
请求 style.css → 响应
请求 main.js → 响应
关闭
减少了握手次数、延迟和 CPU 消耗。
另一个重要新增是 Host 请求头。
一台物理服务器上可能挂了多个网站（www.a.com、www.b.com、www.c.com 都解析到同一个 IP），没有 Host 头服务器不知道你想访问哪个。有了 Host: www.a.com，虚拟主机技术才能跑起来。
HTTP/1.1 的队头阻塞
连接复用带来了新问题。在同一个连接里，请求是串行的——服务器必须按顺序响应。如果第一个请求（比如一张大图）处理很慢，后面的请求全得排队等着。这就是 HTTP/1.1 的队头阻塞。
五、HTTP/2.0：一个连接里并行干活
HTTP/2 的核心思路：让一个 TCP 连接同时处理多个请求。
二进制分帧
HTTP/1.x 是文本协议，请求长这样：
GET /index.html HTTP/1.1
Host: www.test.com
HTTP/2 把一切打成二进制帧，机器解析快得多。
多路复用
这是 HTTP/2 最重要的特性。在 HTTP/2 里，一个 TCP 连接上可以同时跑多个请求和响应，帧可以交错传输——请求 1 还没响应完，请求 2 的响应数据可能已经先到了。不存在排队等待的问题。
打个比方：HTTP/1.1 是单车道，HTTP/2 是多车道高速公路。
Header 压缩
HTTP 请求的头部在每次请求中大量重复——Cookie、User-Agent、Host 这些字段几乎不变但每次都传一遍。HTTP/2 用 HPACK 算法做头部压缩，后面的请求只传变化的部分。
Server Push
服务器可以主动推送。浏览器请求 index.html，服务器顺手把 style.css 和 main.js 也推过去，省了浏览器再发两次请求。
六、HTTP/3.0：甩掉 TCP
HTTP/2 已经很快了，问题出在哪儿？出在 TCP 本身。
HTTP/2 解决了 HTTP 层的队头阻塞，但 TCP 层的队头阻塞还在。TCP 要求数据按序交付——如果数据包 2 丢了，数据包 3 已经到了也得等着，直到包 2 重传成功。
HTTP/3 不再用 TCP，改用 QUIC 协议，跑在 UDP 之上。
结构对比：
HTTP/2: HTTP → TCP → IP
HTTP/3: HTTP → QUIC → UDP → IP
QUIC 做了什么：
连接建立更快。
首次连接后，后续可以 0-RTT 握手——省了一个往返。
连接可以迁移。
TCP 用「IP + 端口」识别连接，WiFi 切到移动数据，IP 变了，TCP 连接就断了。QUIC 用连接 ID 识别，网络切换连接不中断。对手机端非常重要。
七、四个版本一句话
┌─────────────┬──────────┬──────────┬────────┬────────────┐
│ │ HTTP/1.0 │ HTTP/1.1 │ HTTP/2 │ HTTP/3 │
├─────────────┼──────────┼──────────┼────────┼────────────┤
│ 连接 │ 短连接 │ 长连接 │ 长连接 │ QUIC 连接 │
├─────────────┼──────────┼──────────┼────────┼────────────┤
│ 协议格式 │ 文本 │ 文本 │ 二进制 │ 二进制 │
├─────────────┼──────────┼──────────┼────────┼────────────┤
│ 多路复用 │ 无 │ 无 │ 有 │ 有 │
├─────────────┼──────────┼──────────┼────────┼────────────┤
│ Header 压缩 │ 无 │ 无 │ 有 │ 有 │
├─────────────┼──────────┼──────────┼────────┼────────────┤
│ 底层协议 │ TCP │ TCP │ TCP │ UDP + QUIC │
└─────────────┴──────────┴──────────┴────────┴────────────┘
八、Java 后端开发需要关注什么
HTTP/1.1 是日常。
Spring Boot、Tomcat、Nginx 大量依赖它。GET/POST、Cookie、Session、状态码、Keep-Alive 这些是基本功，必须烂熟。
HTTP/2 要知道为什么快。
现在 CDN 普遍支持 HTTP/2，多路复用和头部压缩是网页加载变快的直接原因。面试常考。
HTTP/3 了解思路就好。
QUIC 怎么用 UDP 做可靠传输、怎么优化移动网络，知道大概逻辑就行。暂时不用深挖。
九、面试高频三问
Q: HTTP/1.1 比 1.0 好在哪里？
长连接（不用每次重新握手）、Host 头（支持虚拟主机）、分块传输、更好的缓存控制。
Q: HTTP/2 为什么更快？
二进制协议、多路复用（并行传输）、头部压缩、Server Push。
Q: HTTP/3 为什么放弃 TCP？
TCP 的队头阻塞、三次握手延迟、移动场景下连接迁移困难。QUIC 把这些问题都解决了。
HTTP/1.0 让网页能传，HTTP/1.1 让连接高效，HTTP/2 让并发不再排队，HTTP/3 把 TCP 的包袱甩掉了。
理解这几个版本为什么变，比你记住每个版本有什么特性重要得多。这也是你后面理解 Tomcat、Nginx、Netty、RPC 框架的基础。
