表格匯總
| 對比維度 | HTTP/1.0 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|---|
| 傳輸協議 | TCP | TCP | TCP/TLS（默認加密） | UDP（基于 QUIC 協議） |
| 連接方式 | 短連接（每次請求/響應后斷開） | 引入持久連接（Persistent Connection），默認長連接 | 多路復用（同一連接處理多個請求） | 多路復用（基于 UDP，減少連接建立延遲） |
| 頭部處理 | 純文本，無壓縮 | 純文本，部分緩存優化（如條件請求） | 二進制分幀，HPACK 算法壓縮頭部 | 二進制格式，QPACK 算法進一步壓縮頭部 |
| 性能問題 | 線頭阻塞嚴重；連接頻繁創建銷毀開銷大 | 緩解線頭阻塞（管道化技術，但未完全解決）；同一域名并發連接數有限（6-8 個） | 解決線頭阻塞；單連接承載所有請求，減少連接開銷 | 更低延遲；減少 TCP 握手和 TLS 協商時間 |
| 安全特性 | 無內置加密 | 無內置加密，需依賴 SSL/TLS | 強制 TLS 加密，安全性高 | 基于 TLS 1.3，安全性進一步提升 |
| 特性匯總 | 簡單請求/響應模式，每次請求需建立新連接，性能低、安全性差 | 支持長連接，減少連接開銷；引入緩存控制、斷點續傳等優化，但仍存在線頭阻塞 | 基于二進制分幀和多路復用，解決線頭阻塞；默認加密，性能與安全性顯著提升 | 基于 UDP 和 QUIC，進一步降低延遲，抗網絡擁塞能力強，安全性更高 |
一句話版本，及常見追問分析
- HTTP/1.0：采用短連接，每次請求都需重新建立和斷開 TCP 連接，純文本頭部無壓縮，性能較低且存在嚴重線頭阻塞問題。
HTTP/1.0
追問：HTTP/1.0 的短連接機制，具體會帶來哪些性能損耗？
回答：短連接每次請求都需經歷 TCP 的三次握手建立連接，請求完成后通過四次揮手斷開連接。這個過程涉及多次網絡往返（RTT），會消耗額外的時間和資源。特別是對于包含大量資源請求的網頁，頻繁創建和銷毀連接會導致明顯的延遲，同時增加服務器的連接管理開銷，降低整體傳輸效率。
- HTTP/1.1：默認使用持久連接減少連接開銷，支持管道化部分緩解線頭阻塞，引入緩存控制和斷點續傳，但純文本頭部和有限的并發連接仍制約性能。
HTTP/1.1
追問：HTTP/1.1 的管道化技術為什么沒有徹底解決線頭阻塞問題？
回答：管道化允許客戶端在一個 TCP 連接上連續發送多個請求而無需等待響應，但服務器仍需按順序處理和返回響應。如果前面的請求因處理復雜或網絡問題耗時較長，后續請求的響應就會被阻塞，依然存在線頭阻塞。并且，由于不同瀏覽器對管道化的支持程度不一，實際應用中很多瀏覽器出于兼容性和穩定性考慮，默認關閉該功能。
- HTTP/2：基于 TCP，通過二進制分幀、多路復用徹底解決線頭阻塞，利用 HPACK 算法壓縮頭部，支持服務器推送，默認強制 TLS 加密，顯著提升性能與安全性 。
HTTP/2
追問：HTTP/2 的二進制分幀和多路復用如何配合解決線頭阻塞？
回答：二進制分幀將數據分割為更小的二進制幀，每個幀帶有唯一標識，可在連接中獨立傳輸；多路復用則允許這些幀在同一 TCP 連接上混合交錯傳輸。這樣一來，多個請求和響應的幀能同時在連接中流動，服務器可以并行處理請求，按任意順序返回幀，客戶端再根據幀標識重新組裝數據。即使某個請求的處理耗時較長，也不會影響其他請求幀的傳輸和響應，從而徹底解決線頭阻塞問題。
- HTTP/3：基于 UDP 的 QUIC 協議，進一步降低連接建立延遲，減少 TCP 握手和 TLS 協商時間，具備更強的抗網絡擁塞能力，結合 QPACK 頭部壓縮和 TLS 1.3，實現低延遲與高安全性。
HTTP/3
追問：HTTP/3 選擇 UDP 替代 TCP 作為傳輸層協議，主要解決了哪些 TCP 的固有問題？
回答：TCP 存在握手延遲（至少 1 個 RTT 完成三次握手）、隊頭阻塞（單個數據包丟失會阻塞整個連接）以及擁塞控制策略復雜(慢開始、擁塞避免、快速重傳、快速恢復)等問題擁塞控制四大算法精簡總結可看我的這篇文章【計算機網絡】高頻計網面試總結。HTTP/3 基于 UDP 的 QUIC 協議，通過 0-RTT（零往返時間）連接恢復減少握手延遲，利用流級別的多路復用，避免單個流阻塞影響其他流，同時集成了更高效的擁塞控制算法和加密機制，在弱網環境下能顯著降低延遲，提升傳輸性能和抗網絡抖動能力。
https://github.com/0voice
)
)