HTTP 版本演進史：從 0.9 到 3 的進化之路
HTTP 協定從 1991 年誕生至今已經歷四個主要版本。每一次版本演進都是為了解決上一代的痛點，同時適應不斷變化的網路環境。本篇將帶你走過這段精彩的進化之路。
一、 版本總覽
| 版本 | 年份 | 核心改進 |
|---|---|---|
| HTTP/0.9 | 1991 | 最初版本，只有 GET |
| HTTP/1.0 | 1996 | 加入 Headers、狀態碼 |
| HTTP/1.1 | 1997 | 持久連線、Pipeline |
| HTTP/2 | 2015 | 多路複用、二進位 |
| HTTP/3 | 2022 | 基於 QUIC/UDP |
二、 HTTP/0.9：一切的起點（1991）
HTTP/0.9 是 Tim Berners-Lee 在 CERN 設計的最初版本，極其簡單。
特點
- 只有 GET 方法
- 沒有 Headers
- 沒有狀態碼
- 只能傳輸 HTML
- 每次請求都開新連線
請求格式
GET /index.html就這樣，一行搞定。沒有版本號、沒有 Headers。
回應格式
<html>
<body>
Hello World
</body>
</html>直接回傳 HTML 內容，沒有任何元資料。
NOTE
HTTP/0.9 有時被稱為「單行協定」(The One-Line Protocol)，因為請求真的只有一行。
三、 HTTP/1.0：成熟的開始（1996）
HTTP/1.0 加入了許多我們今天熟悉的特性。
核心改進
- 版本號：請求行加入
HTTP/1.0 - Headers：可以傳遞元資料
- 狀態碼：伺服器可以告知請求結果
- Content-Type：不再只限 HTML
- POST/HEAD 方法
請求範例
GET /index.html HTTP/1.0
User-Agent: Mozilla/1.0
Accept: text/html回應範例
HTTP/1.0 200 OK
Date: Tue, 15 Nov 1996 08:12:31 GMT
Content-Type: text/html
Content-Length: 1234
<html>...</html>主要問題：短連線
問題：每個請求都需要新建 TCP 連線，開銷巨大。
四、 HTTP/1.1：堅實的標準（1997）
HTTP/1.1 是使用時間最長、最穩定的版本，至今仍被廣泛使用。
核心改進
1. 持久連線（Keep-Alive）
預設不關閉連線，可復用同一個 TCP 連線：
Connection: keep-alive2. 管線化（Pipelining）
可以連續發送多個請求，不用等待回應：
WARNING
管線化有「隊頭阻塞」(Head-of-Line Blocking) 問題：如果第一個請求很慢，後面的都要等。因此實際上瀏覽器很少使用。
3. Host 標頭（必填）
支援虛擬主機：
GET /page HTTP/1.1
Host: www.example.com4. 分塊傳輸（Chunked Transfer）
Transfer-Encoding: chunked允許伺服器在不知道內容長度的情況下開始回應。
5. 更多方法
- PUT、DELETE、OPTIONS、TRACE
HTTP/1.1 的問題
| 問題 | 說明 |
|---|---|
| 隊頭阻塞 | 必須按順序處理請求 |
| Headers 冗餘 | 每次都傳完整 Headers |
| 無優先級 | 無法指定資源重要性 |
| 文字協定 | 解析效率低 |
为了繞過這些限制，瀏覽器的做法是：開多個連線（通常 6 個）。
五、 HTTP/2：效能革命（2015）
HTTP/2 基於 Google 的 SPDY 協定，是一次重大的效能升級。
核心改進
1. 二進位協定
從文字變成二進位幀（Frame）：
HTTP/1.1: GET /index.html HTTP/1.1\r\n
HTTP/2: [HEADERS Frame][DATA Frame]優點：
- 解析更快
- 更緊湊
- 更少錯誤
2. 多路複用（Multiplexing）
一個連線同時處理多個請求，徹底解決隊頭阻塞：
3. Header 壓縮（HPACK）
使用 HPACK 演算法壓縮重複的 Headers：
# HTTP/1.1 每次都傳完整 Headers
User-Agent: Mozilla/5.0 (很長的字串)...
Accept: text/html,application/xhtml+xml...
# HTTP/2 使用索引
User-Agent: [index: 62]
Accept: [index: 19]壓縮率可達 85% 以上。
4. 伺服器推送（Server Push）
伺服器可以主動推送資源：
NOTE
Server Push 實際使用較少，因為難以控制且可能浪費頻寬。Chrome 已在 2022 年移除支援。
5. 流優先級
可以指定資源的優先順序：
Stream 1 (HTML): 權重 256
Stream 3 (CSS): 權重 128
Stream 5 (圖片): 權重 32HTTP/2 的問題
雖然解決了應用層的隊頭阻塞，但 TCP 層的隊頭阻塞仍然存在：
一個封包丟失，整個 TCP 連線都要等待重傳。
六、 HTTP/3：QUIC 革命（2022）
HTTP/3 徹底拋棄 TCP，改用基於 UDP 的 QUIC 協定。
為什麼要放棄 TCP？
| TCP 的問題 | HTTP/3 的解決方案 |
|---|---|
| 隊頭阻塞 | QUIC 獨立流 |
| 握手延遲 | 0-RTT 連線 |
| 中間設備僵化 | UDP 穿透 |
| 連線遷移困難 | Connection ID |
核心特性
1. 基於 UDP + QUIC
2. 零隊頭阻塞
每個 Stream 獨立，一個流丟包不影響其他流：
Stream 2 丟包，Stream 1 和 3 不受影響，繼續傳輸。
3. 0-RTT 連線建立
首次連線：1 RTT（同時完成加密握手） 重連：0 RTT（直接發送資料）
4. 連線遷移
使用 Connection ID 而非 IP:Port 識別連線：
# TCP: IP 變了就斷線
192.168.1.1:12345 → 斷線 → 重連
# QUIC: Connection ID 不變就不斷線
手機 WiFi → 4G → 無縫切換HTTP/3 採用現狀
主流網站支援情況（2024）：
✅ Google
✅ Facebook
✅ Cloudflare
✅ YouTube七、 版本比較
效能對比
| 特性 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 連線數量 | 多個 | 1 個 | 1 個 |
| 隊頭阻塞 | 存在 | 應用層解決 | 完全解決 |
| Header 壓縮 | 無 | HPACK | QPACK |
| 加密 | 可選 | 實際必須 | 內建 |
| 握手延遲 | 2-3 RTT | 2-3 RTT | 0-1 RTT |
協定棧對比
HTTP/1.1 HTTP/2 HTTP/3
┌─────────┐ ┌─────────┐ ┌─────────┐
│ HTTP │ │ HTTP/2 │ │ HTTP/3 │
├─────────┤ ├─────────┤ ├─────────┤
│ TLS │ │ TLS │ │ QUIC │
├─────────┤ ├─────────┤ │ (含 TLS)│
│ TCP │ │ TCP │ ├─────────┤
├─────────┤ ├─────────┤ │ UDP │
│ IP │ │ IP │ ├─────────┤
└─────────┘ └─────────┘ │ IP │
└─────────┘總結
| 版本 | 一句話總結 |
|---|---|
| HTTP/0.9 | 能用就好 |
| HTTP/1.0 | 有模有樣 |
| HTTP/1.1 | 穩定可靠 |
| HTTP/2 | 效能飛躍 |
| HTTP/3 | 未來已來 |
> **選擇建議**：
- 新專案：直接上 HTTP/2，搭配 CDN 支援 HTTP/3
- 現有專案：確保至少使用 HTTP/1.1 with TLS
- API 服務：HTTP/2 是最佳選擇
進階挑戰
- 使用 Chrome DevTools 的 Network 面板，觀察你常用網站使用的 HTTP 版本（Protocol 欄位）。
- 使用
curl --http2和curl --http3測試不同版本的差異。 - 思考：為什麼 HTTP/3 選擇基於 UDP 而不是改進 TCP？改進 TCP 會遇到什麼困難？