TL;DR | 面試情境模擬 #
👴 面試官：HTTP/1.1、HTTP/2、HTTP/3 各自解決了什麼問題？
🧑💻 你：HTTP/1.1 一條連線同時只能處理一個請求，瀏覽器靠開多條 TCP 連線繞過這個限制，但效率差。HTTP/2 引入多路復用，同一條連線可以並行傳多個請求，但底層 TCP 的 Head-of-line blocking 問題沒解決。HTTP/3 把 TCP 換成 QUIC（基於 UDP），從根本解決封包卡隊問題，而且切換網路不斷線。
比喻：高速公路的演進 #
- HTTP/1.1：只有一線道，每次只能過一台車，後面的全部等。解法是多開幾條路（多條 TCP），但每條路都要收過路費（3-way handshake）。
- HTTP/2：變成多線道，多台車可以同時走，但如果最前面有車拋錨，後面所有車道都卡住了。
- HTTP/3：換成無軌電車（QUIC），每個乘客（資料流）獨立，一個人出問題不影響其他人。而且換站不用重新買票。
各版本核心對比 #
| 特性 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 底層協定 | TCP | TCP | QUIC（UDP） |
| 多路復用 | 無 | 有 | 有 |
| Header 壓縮 | 無 | HPACK | QPACK |
| Head-of-line blocking | 有 | 應用層解決，TCP 層仍有 | 解決 |
| 連線遷移 | 無 | 無 | 有（換 IP 不斷線） |
| 0-RTT 重連 | 無 | 無 | 有 |
三代演進細節 #
HTTP/1.1 的問題：HOL Blocking #
請求 1 ─── 等待回應 ──────────────── 完成
請求 2 ─── 等待請求1完成 ─── 開始
請求 3 ─ 等更久
瀏覽器的解法：一個域名最多開 6 條 TCP 連線，但每條建立時都要付 handshake 的成本。
HTTP/2 的改進：多路復用（Multiplexing） #
Stream 1 ─── 資料 ─── 資料 ─── 完成
Stream 2 ─── 資料 ─────────── 完成 ← 同一條 TCP 連線
Stream 3 ───────── 資料 ───── 完成
但如果 TCP 有一個封包遺失，所有 Stream 都要等那個封包重傳，這是 TCP 協定層的問題，HTTP/2 無法解決。
HTTP/3 的改進：QUIC 協定 #
QUIC 建立在 UDP 上，但自己實作了可靠傳輸邏輯：
- 每個 Stream 獨立，一個封包遺失只影響那個 Stream
- 連線用 Connection ID 識別，換 Wi-Fi 到 4G 不用重新握手
- TLS 1.3 整合進 QUIC，首次連線 1-RTT，重連 0-RTT
💡 面試官可能會追問 #
Q1：現在大多數網站用哪個版本？ #
HTTP/2 已是主流（2024 年超過 60% 網站支援），HTTP/3 採用率快速增長（YouTube、Google、Facebook 已全面啟用）。HTTP/1.1 仍存在，但新網站不應該只用它。
Q2：HTTP/3 為什麼用 UDP？UDP 不是不可靠嗎？ #
UDP 本身不提供可靠傳輸，但 QUIC 在 UDP 之上自己實作了重傳、順序保證等機制。選 UDP 的原因是可以在使用者空間（user space）而非 OS 核心實作協定，更容易更新和優化，不用等 OS 支援新版 TCP。