【2025最新面試八股常問知識點】HTTP1.0，HTTP1.1，HTTP2.0,HTTP3.0，HTTP的進化之路。

HTTP

超文本傳輸協議（英文：HyperText Transfer Protocol，縮寫：HTTP）是一種用于分布式、協作式和超媒體信息系統的應用層協議。設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法。通過HTTP或者HTTPS協議請求的資源由統一資源標識符（Uniform Resource Identifiers，URI）來標識。

HTTP 協議是以 ASCII 碼傳輸，基于請求與響應模式的、無狀態的，建立在 TCP/IP 協議之上的應用層規范。。它不涉及數據包（packet）傳輸，主要規定了客戶端和服務器之間的通信格式，默認使用80端口。
?

HTTP協議主要的版本有4個，分別是HTTP/1.0、HTTP/1.1、HTTP/2和HTTP3.0HTTPS是另外一個協議，簡單講是HTTP的安全版。可以看我的另一篇博客

【2025計算機網絡-面試常問】http和https區別是什么，http的內容有哪些，https用的是對稱加密還是非對稱加密，流程是怎么樣的-CSDN博客https://blog.csdn.net/gwndjsh/article/details/147373157?spm=1001.2014.3001.5501

1. HTTP/1.0（1996年）

HTTP/1.0中瀏覽器與服務器只保持短暫的連接，連接無法復用。也就是說每個TCP連接只能發送一個請求。發送數據完畢，連接就關閉，如果還要請求其他資源，就必須再新建一個連接。

核心特點：
- 短連接：每個請求/響應后立即關閉TCP連接，導致高延遲（需頻繁三次握手）。
- 無狀態：服務器不記錄客戶端狀態（依賴Cookie等機制擴展）。
- 基礎功能：支持GET、POST、HEAD方法，通過Content-Type支持多種數據類型（如HTML、圖片）。
典型問題：
- TCP連接的建立需要三次握手，是很耗費時間的一個過程。所以，HTTP/1.0版本的性能比較差。現在，隨便打開一個網頁，上面都會有很多圖片、視頻等資源，HTTP/1.0顯然無法滿足性能要求。
  每個資源（如圖片、CSS）需單獨建立連接，頁面加載效率極低。

2. HTTP/1.1（1997年，主流版本）

最主要的改進就是引入了持久連接。所謂的持久連接就是：在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲。

核心改進：
- 持久連接（Keep-Alive）：默認復用TCP連接，減少握手開銷（通過Connection: keep-alive）。
- 管道化（Pipelining）：允許客戶端發送多個請求而不需等待響應（但服務器必須按順序返回，易隊頭阻塞）。
- 分塊傳輸（Chunked Transfer）：支持流式傳輸（Transfer-Encoding: chunked）。
- 緩存控制：引入Cache-Control、ETag等頭部優化緩存策略。
- Host頭：支持虛擬主機（單IP托管多域名）。
遺留問題：
- 隊頭阻塞（Head-of-Line Blocking）：一個慢請求會阻塞后續請求。對于管道連接還是有一定的限制和要求的，其中一個比較關鍵的就是服務端必須按照與請求相同的順序回送HTTP響應。這也就意味著，如果一個響應返回發生了延遲，那么其后續的響應都會被延遲，直到隊頭的響應送達。這就是所謂的HTTP隊頭阻塞。
- 頭部冗余：每次請求攜帶大量重復頭部（如Cookie）。

SPDY（過度時期）

雖然，HTTP/1.1在HTTP/1.0的基礎上提供了持久連接，提升了很大的效率，但是，還是有很大的提升空間。

正所謂時勢造英雄，正是因為HTTP存在著諸多不足，所以，才誕生了SPDY。2009年，谷歌公開了自行研發的 SPDY 協議，主要解決 HTTP/1.1 效率不高的問題。它的設計目標是降低 50% 的頁面加載時間。SPDY主要提供了以下功能（后文介紹HTTP2的時候再詳細介紹）：

●多路復用（multiplexing）。多個請求共享一個tcp連接。
●header壓縮。刪除或者壓縮HTTP頭
●服務端推送。提供服務方發起通信，并向客戶端推送數據的機制。

SPDY位于HTTP之下，TCP和SSL之上，這樣可以輕松兼容老版本的HTTP協議。

3. HTTP/2.0（2015年，革命性升級）

HTTP/2主要是解決HTTP中存在的效率問題。它主要引入了二進制分幀、多路復用、header壓縮、以及服務端推送的新特性，大大的提升了效率。

而且，在HTTP/2中還解決了一個重要的問題，那就是HTTP的隊頭阻塞問題。

核心改進：
- 二進制協議：替換文本格式，幀（Frames）和流（Streams）提高解析效率。主要是HTTP/2 會將所有傳輸的信息分割為更小的消息和幀（frame）,并對它們采用二進制格式的編碼。這種單連接多資源的方式，減少了服務端的壓力，使得內存占用更少，連接吞吐量更大。而且，TCP連接數的減少使得網絡擁塞狀況得以改善，同時慢啟動時間的減少，使擁塞和丟包恢復速度更快。
- 多路復用（Multiplexing）：單連接并行傳輸多個請求/響應，徹底解決隊HTTP頭阻塞。多路復用允許同時通過單一的HTTP/2.0連接發起多重的請求-響應消息。
- 頭部壓縮（HPACK）：減少冗余頭部體積（專為HTTP設計的壓縮算法）。HTTP/1.1的header帶有大量信息，而且每次都要重復發送。HTTP/2 為了減少這部分開銷，采用了HPACK 頭部壓縮算法對Header進行壓縮。
- 服務器推送（Server Push）：服務器可主動推送資源（如CSS/JS）到客戶端緩存。簡單來講就是當用戶的瀏覽器和服務器在建立連接后，服務器主動將一些資源推送給瀏覽器并緩存起來的機制。有了緩存，當瀏覽器想要訪問已緩存的資源的時候就可以直接從緩存中讀取了。
- 流優先級：允許設置請求優先級（如優先加載HTML而非圖片）。
局限：
- 仍基于TCP，可能受TCP隊頭阻塞影響（如丟包時重傳阻塞所有流）。只能說HTTP/2解決了HTTP的隊頭阻塞問題，但是并沒有解決TCP隊頭阻塞問題！
- 部署復雜度高（需TLS加密，依賴ALPN協商）。
關于怎么解決的HTTP頭阻塞為問題
- 在HTTP1.1中的HTTP頭阻塞是因為管道化的設計方式造成的。HTTP/2廢棄了管道化的方式，而是創新性的引入了幀、消息和數據流等概念。客戶端和服務器可以把 HTTP 消息分解為互不依賴的幀，然后亂序發送，最后再在另一端把它們重新組合起來。因為沒有順序了，所以就不需要阻塞了，就有效的解決了HTTP隊頭阻塞的問題。
關于TCP頭阻塞的問題（發生原因）
- 因為TCP傳輸過程中會把數據拆分為一個個按照順序排列的數據包，這些數據包通過網絡傳輸到了接收端，接收端再按照順序將這些數據包組合成原始數據，這樣就完成了數據傳輸。但是如果其中的某一個數據包沒有按照順序到達，接收端會一直保持連接等待數據包返回，這時候就會阻塞后續請求。這就發生了TCP隊頭阻塞。
  HTTP/1.1的管道化持久連接也是使得同一個TCP鏈接可以被多個HTTP使用，但是HTTP/1.1中規定一個域名可以有6個TCP連接。而HTTP/2中，同一個域名只是用一個TCP連接。
  所以，在HTTP/2中，TCP隊頭阻塞造成的影響會更大，因為HTTP/2的多路復用技術使得多個請求其實是基于同一個TCP連接的，那如果某一個請求造成了TCP隊頭阻塞，那么多個請求都會受到影響。
放棄TCP（推薦）或者升級TCP（不推薦）
- ?放棄TCP好理解和跟下面的HTTP3一樣，但是升級TCP的時候，這就涉及到一個”協議僵化“的問題。需要考慮中間層的問題，中間設備是指插入在數據終端和信號轉換設備之間，完成調制前或解調后某些附加功能的輔助設備。例如集線器、交換機和無線接入點、路由器、安全解調器、通信服務器等都是中間設備。一個網絡需要經過無數個中間設備的轉發才能到達終端用戶。操作系統也是一個重要的因素，因為TCP協議需要通過操作系統內核來實現，而操作系統的更新也是非常滯后的。所以，這種問題就被稱之為”中間設備僵化”，也是導致”協議僵化”的重要原因。這也是限制著TCP協議更新的一個重要原因。

4. HTTP/3.0（2022年正式標準，基于QUIC（應該是屬于傳輸層），這是一種完全基于UDP的協議）

我們知道，HTTP/2之所以"被棄用"，是因為他使用的傳輸層協議仍然是TCP，所以HTTP/3首要解決的問題就是繞開TCP，像上面所說如果改造TCP協議的話那么同樣還是會因為受到中間設備僵化的影響，導致無法被大規模應用。所以，研發人員們想到了一種基于UDP實現的方式

QUIC協議有以下特點：
●基于UDP的傳輸層協議：它使用UDP端口號來識別指定機器上的特定服務器。
●可靠性：雖然UDP是不可靠傳輸協議，但是QUIC在UDP的基礎上做了些改造，使得他提供了和TCP類似的可靠性。它提供了數據包重傳、擁塞控制、調整傳輸節奏以及其他一些TCP中存在的特性。
●實現了無序、并發字節流：QUIC的單個數據流可以保證有序交付，但多個數據流之間可能亂序，這意味著單個數據流的傳輸是按序的，但是多個數據流中接收方收到的順序可能與發送方的發送順序不同！
●快速握手：QUIC提供0-RTT（零往返時間）和1-RTT（單往返時間）的連接建立
●使用TLS 1.3傳輸層安全協議：與更早的TLS版本相比，TLS 1.3有著很多優點，但使用它的最主要原因是其握手所花費的往返次數更低，從而能降低協議的延遲。

優勢場景：
- 高延遲網絡（如移動端）、頻繁切換網絡的場景。
- 對實時性要求高的應用（如視頻會議、在線游戲）。

版本對比總結

特性	HTTP/1.0	HTTP/1.1	HTTP/2.0	HTTP/3.0
連接方式	短連接	持久連接	多路復用	QUIC多路復用
傳輸協議	TCP	TCP	TCP	UDP（QUIC）
頭部壓縮	無	無	HPACK	QPACK
隊頭阻塞	嚴重	管道化仍存在	TCP層存在	完全解決
服務器推送	不支持	不支持	支持	保留但使用率低
典型應用	早期靜態頁面	現代Web（兼容模式）	主流高性能Web	移動端/實時應用