HTTP 1.0 和 2.0 的核心區別體現在性能優化、協議設計和功能擴展上，以下是具體對比：
一、核心區別對比
| 特性 | HTTP 1.0 | HTTP 2.0 |
|---|---|---|
| 連接方式 | 非持久連接（默認每次請求新建 TCP 連接） | 持久連接（默認保持連接，可復用） |
| 并行處理 | 瀏覽器限制單域名下 6 個并發連接 | 單連接多路復用（多個請求/響應在同一連接上同時傳輸） |
| 頭部處理 | 明文傳輸，重復冗余 | 二進制分幀 + HPACK 壓縮算法，減少頭部體積 |
| 資源加載順序 | 按請求順序串行處理 | 優先級排序 + 流量控制，靈活分配資源加載順序 |
| 服務器主動推送 | 不支持 | 支持（Server Push，主動向客戶端發送資源） |
| 協議格式 | 純文本格式 | 二進制格式（更高效解析，減少網絡延遲） |
二、HTTP 2.0 新增特性詳解
1. 二進制分幀（Binary Framing）
- 核心改進：將 HTTP 消息分解為獨立的“幀”（Frame），以二進制格式傳輸。
- 優勢：
- 客戶端和服務器可通過幀的標識（Stream ID）區分不同請求/響應，在單個 TCP 連接上并行處理多個數據流（多路復用）。
- 解決了 HTTP 1.x 中“隊頭阻塞”問題（某一請求阻塞不影響其他請求）。
2. 多路復用（Multiplexing）
- 機制：多個請求和響應可在同一個連接上同時交錯發送，無需為每個資源創建新連接。
- 效果：
- 減少 TCP 連接建立的開銷（三次握手、TLS 協商）。
- 提升帶寬利用率，尤其對加載大量小資源（如圖片、CSS、JS）的網頁效果顯著。
3. 頭部壓縮（HPACK 算法）
- 問題：HTTP 1.x 中頭部字段重復（如
User-Agent、Cookie），占用大量帶寬。 - 解決方案：
- 客戶端和服務器維護一份共享的頭部字段緩存（靜態 + 動態表），重復字段通過索引引用。
- 對未緩存的字段進行哈夫曼編碼壓縮，大幅減少頭部傳輸體積（通常壓縮率達 50%-90%）。
4. 服務器推送（Server Push）
- 功能：服務器可根據客戶端請求，主動推送其他相關資源（如 HTML 引用的 CSS/JS 文件），無需客戶端額外請求。
- 場景：
- 當客戶端請求首頁時，服務器預判并推送頁面依賴的靜態資源，減少客戶端等待時間。
- 支持“緩存推送”，資源可直接存入客戶端緩存，提升后續訪問速度。
5. 流量控制（Flow Control）
- 目的：避免某一數據流占用過多帶寬，影響其他數據流。
- 機制：
- 基于每個數據流（Stream）獨立控制，客戶端可告知服務器接收緩沖區大小。
- 精細調節資源傳輸速率，優化弱網絡環境下的性能。
6. 請求優先級（Request Prioritization）
- 功能：客戶端可通過設置請求優先級（如“高優先級先傳輸 HTML，低優先級后加載圖片”），告知服務器資源加載順序。
- 優勢：
- 瀏覽器可優先渲染關鍵內容（如首屏元素），提升用戶感知速度。
- 服務器根據優先級分配處理資源，優化整體加載效率。
三、性能提升總結
- 速度：多路復用減少連接開銷，頭部壓縮降低數據量，服務器推送減少往返次數，整體加載速度提升 30%-70%。
- 兼容性：基于 TCP 協議，支持 TLS（HTTPS 環境下默認啟用），需服務器和客戶端同時支持 HTTP 2.0。
- 應用場景：適用于高并發、多資源依賴的 Web 應用（如單頁應用、電商網站），尤其在移動網絡或弱帶寬環境下優勢明顯。
四、HTTP 2.0 的局限性
- 隊頭阻塞未完全消除：雖然單個連接內請求不阻塞，但 TCP 層的丟包會影響整個連接（HTTP 3.0 基于 UDP 的 QUIC 協議解決了這一問題）。
- 服務器推送的復雜性：過度推送可能導致緩存浪費或帶寬濫用，需合理配置策略。
通過這些改進，HTTP 2.0 顯著提升了 Web 性能，成為現代 Web 開發的標準協議之一。
