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 | 移動端/實時應用 |
演進背后的核心目標
-
性能優化:減少延遲(從短連接到QUIC)、提高吞吐量(多路復用)。
-
安全性:從明文(HTTP/1.0)到強制HTTPS(HTTP/2+)。
-
適應新場景:從靜態頁面到動態應用(SPA)、實時流媒體。
實際建議
-
兼容性優先:多數服務仍支持HTTP/1.1(如CDN回源)。
-
性能敏感場景:啟用HTTP/2(需TLS)或HTTP/3(如Cloudflare、Google服務已支持)。
-
未來趨勢:HTTP/3將逐步普及,但需客戶端/服務器/網絡設備全面支持。