HTTP是浏览器和服务器之间的“对话”规则。你在地址栏输入一个网址，浏览器按照 HTTP 发起请求。服务器按照一样的规则返回响应。

浏览器：「我要 /index.html」 → 请求
说到服务器。「给你，OK，内容如下，」 ← 响应

从诞生至今HTTP 已经经历了 5 个大版本。每一次升级都是为了解决前一代的痛点——加载慢、连接浪费、安全风险等。其实，

二、HTTP/0.9 —— 最原始的版本

特点

• 仅支持 GET 方法
• 没有请求头、响应头
• 只能传输 HTML 文本
• 响应完即断开连接

一次对话示例

请求：GET /hello.html
响应的观点是。Hello World

出现的问题

• 功能受限：只能展示文字，图片、CSS、JS 完全无法加载。
• 缺少元数据：没有 Content-Type、Content-Length 等信息，浏览器不知道资源大小和类型。
• 每次请求都要新建 TCP 连接：导致大量握手开销，页面加载极慢。

三、HTTP/1.0 —— 有模有样了

解决了哪些痛点

新增能力	说明
请求头 & 响应头	携带 Content-Type、Content-Length 等元数据，让浏览器知道资源类型和大小。
多种方法	支持表单提交和资源检查。
Status Code	明确告知请求成功与否，便于错误处理。
MIME 类型支持	图片、音频、视频等多媒体可以传输。
协议版本号在请求行中声明	为后续升级奠定基础。

请求：
GET /logo.png HTTP/1.0
至于Host，www.example.com
从Accept来看，image/png
从响应来看。HTTP/1.0 200 OK
Content-Type: image/png
Content-Length: 12345

仍然存在的痛点：短连接

每个资源都要走一次 TCP 三次握手 + 四次挥手。

假设一个页面包含 a 个 HTML + b 张图片 + c 个 CSS + d 个 JS = n 个资源 。那么就会产生 a+b+c+d = n 次 TCP 建立与关闭 ,每一次都消耗时间和程序资源。按理说，

连接1： → GET /index.html → →
至于连接2，→ GET /style.css → →
...
重复 n 次...

This “握手‑挥手”循环是导致页面渲染缓慢的根本原因之一。即使有些实现加入了非标准的 Connection: keep-alive,也不是规范行为，兼容性差。怎么说呢，

四、HTTP/1.1 —— 主流二十多年版

主要改进的观点是。 持久连接

默认开启 TCP 长连接复用，同一条链路上可以连续发送多个请求/响应。

HTTP/1.0:
请求① → 响应① → 关闭
请求② → 响应② → 关闭
HTTP/1.1:
请求① → 响应① →
请求② → 响应② →
请求③ → 响应③ → 最终关闭

管线化

Theoretically you could send several requests without waiting for each response,but in practice browsers rarely use it because of head‑of‑line blocking issues .

分块传输

No need to know total size beforehand;server can stream data as it becomes available – perfect for things like ChatGPT’s incremental output.

其它新增特性

能力	说明
Hello Host Header	A single IP can host multiple domains .
Caching 控制	Smoor cache policies replace vague Expires.
Status Code 系列	Easier error handling for developers.
Pseudo‑methods Makes RESTful APIs possible.
...更多细节略...

未解决掉的痛点

问题一这方面，队头阻塞

If request #1 is slow,all subsequent responses must wait even if y’re already ready.

请求顺序的观点是。① 慢查询 → ② 静态图片 → ③ CSS
从实际情况来看，① ████████████
② ░░░░░░░░░░
③ ░░░░░░░░░░

This is like a single‑lane road where a truck blocks all following cars.

再看问题二，并发限制妥协

Browsers open up to N=6~8 parallel TCP connections per domain** to sidestep head‑of‑line blocking,leading to:

• Poor resource utilization – each connection still incurs handshake overhead.
• "Domain sharding" s – splitting assets across multiple subdomains just to increase parallelism.
• Saturation of server connection tables.

问题三的观点是，头部冗余

The same large Cookie or User-Agent header is sent with every request on a persistent connection,wasting bandwidth .

至于问题四，只能客户端主动发起通信

No server push capability;real‑time updates require long polling or WebSocket workarounds.

五、HTTP/2 —— 二进制分帧 & 多路复用时代

主要思想

A single TCP connection can carry many interleaved streams in parallel,eliminating application‑layer head‑of‑line blocking.

二进制分帧

# 文本协议示例
GET /index.html HTTP/1.1\r
再看Host，example.com\r
\r
# 二进制帧示例
┌─────────┬───────┬───────────┐
│ Length │ Type │ Stream ID │ HEADERS 帧
├─────────┴───────┴───────────┤
│ :method = GET。:path = /index.html │
└─────────────────────────────────────┘

多路复用 # HTTP/1.x : 多条串行连接，每条排队 再看conn1，conn2: ... # HTTP/2 : 单条宽带道，多流交错传输 说到conn，... ↑stream1 ↑stream2 ↑stream3 ...

This completely solves application‑layer queue problem and removes need for domain sharding.

头部压缩

• 说到静态表，常见 Header 用索引代替完整字符串。
• 至于动态表。运行时记录已出现过的 Header，下次只发送索引。其实，
• Huffman 编码进一步压缩值。

至于第一次请求，Cookie: session=abc123def456...
从第二次请求来看。Header Index #42

压缩后 Header 大小可下降 **70%+**，尤其在移动网络上收益显著。

服务器推送

服务器可主动将页面可能需要的资源提前发送给客户端，例如在返回 index.html 时直接推送 CSS 与 JS。虽被 Chrome 于202x 移除，但仍展示了 “服务端主动” 的思路。

流优先级

可以为关键资源如 CSS 设置更高优先级。让它们抢占带宽，加快首屏渲染。

仍未解决掉的痛点

• TCP 层仍有队头阻塞：若一个 TCP 包丢失。所有流都会被迫等待重传，即使其他流已准备好数据。
• TLS 握手额外 RTT：HTTPS 必须走 TLS。而 TLS 本身又基于 TCP，需要额外往返时间。
• 协议实现复杂度：二进制分帧与 HPACK 的同步要求严格，对调试和中间件兼容性提出挑战。

---

---