http1.x,http2.0,http3.0有什麼不同- 技術宅

詳細了解http的各個版本有什麼不同

http協議到底是什麼？為什麼要分http1.x,http2.0,http3.0，這三種有什麼不一樣，以下詳細介紹http協議各個版本中不同的地方，讓你進一步了解http協議。

什麼是HTTP？

超文本傳輸協定（英文：HyperText Transfer Protocol，縮寫：HTTP）是網路上應用最廣泛的一種網路協定。設計HTTP最初的目的是為了提供一種發佈和接收HTML頁面的方法。透過HTTP或HTTPS協定請求的資源由統一資源識別碼（URI）來識別。

HTTP是一個應用層協議，由請求和回應構成，是一個標準的客戶端伺服器模型。 HTTP是基於TCP/IP的無連接，無狀態的協定(每一個HTTP封包不依賴其前面的封包狀態)。 HTTP假定其下層協定提供可靠的傳輸。因此也就是其在TCP/IP協定族使用TCP作為其傳輸層。

HTTP協定的主要特性可概括如下：

簡單：客戶向伺服器要求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯繫的不同類型。
靈活：HTTP允許傳輸任意類型的資料物件。正在傳輸的類型由Content-Type加以標記。
請求-回應模式：客戶端每次向伺服器發起一個請求時都建立一個連接，伺服器處理完客戶的請求即斷開連接。
無狀態：HTTP協定是無狀態協定。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的訊息，則它必須重傳。

HTTP工作流程

HTTP由請求和回應構成，是一個標準的客戶端伺服器模型（B/S）。 HTTP協定永遠都是客戶端發起請求，伺服器回傳回應

1、客戶機（瀏覽器）主動向伺服器（web server)發出連線請求(此步驟可能需要DNS解析協定來取得伺服器的IP位址)。

2、伺服器接受連線請求並建立起連線。 (1,2步即我們所熟知的TCP三次握手)

3.客戶機透過此連線向伺服器發出GET等http命令，(“HTTP請求訊息”)。

4、伺服器接到指令並依指令向客戶機傳送對應的數據，(“HTTP回應封包”)。

5.客戶機接收從伺服器送過來的資料。

6.伺服器發送完資料後，主動關閉此連線。（”TCP四次分手“）。

概況起來就是客戶/伺服器傳輸過程可分為四個基本步驟：

1) 瀏覽器與伺服器建立連線; (TCP三次握手)

2) 瀏覽器向伺服器HTTP請求封包；

3) 伺服器回應瀏覽器請求；

4) 斷開連線。（”TCP四次分手“）

HTTP1.X 原理

在http1.0的工作過程中，http傳輸資料時都要經歷三次握手，四次揮手，增加了延時

在http1.1加入了keep-alive來保持tcp連線不斷開，減少了部分延遲

HTTP 1.x存在的問題

連線無法重複使用連線無法重複使用會導致每次請求都經歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對大量小檔案請求影響較大。
隊頭堵塞HOLB隊頭堵塞Head-Of-Line Blocking（HOLB）導致頻寬無法被充分利用，以及後續健康請求被阻塞。HOLB是指一系列套件（package）因為第一個套件被阻塞；當頁面中需要請求很多資源的時候，HOLB（隊頭阻塞）會導致在達到最大請求數量時，剩餘的資源需要等待其他資源請求完成後才能發起請求。針對隊頭阻塞,人們嘗試過以下辦法來解決:

HTTP 1.0：下個請求必須在前一個請求返回後才能發出，request-response對按序發生。顯然，如果某個請求長時間沒有返回，那麼接下來的請求就全部阻塞了。
HTTP 1.1：嘗試使用pipeling 來解決，即瀏覽器可以一次發出多個請求（同一個域名，同一條TCP 連結）。但pipeling 要求回傳是按序的，那麼前一個請求如果很耗時（例如處理大圖片），那麼後面的請求即使伺服器已經處理完，仍會等待前面的請求處理完才開始按序返回。所以，pipeling 只部分解決了HOLB。
引入雪碧圖、小圖內聯等

請求頭開銷大由於報文Header一般會攜帶”User Agent””Cookie””Accept””Server”等許多固定的頭字段（如下圖），多達幾百字節甚至上千字節,但Body卻經常只有幾十字節. Header 內容大在一定程度上增加了傳輸的成本.
安全因素HTTP 1.x在傳輸資料時，所有傳輸的內容都是明文，客戶端和伺服器端都無法驗證對方的身份，這在一定程度上無法保證資料的安全性。
不支援服務端推播訊息因為HTTP/1.x 並沒有推播機制。所以通常兩種做法，一是輪詢，客戶端定時輪詢，二是websocket

2.0 工作原理

2015年，HTTP/2 發布。 HTTP/2是現行HTTP協定（HTTP/1.x）的替代，但它不是重寫，HTTP方法/狀態碼/語意都與HTTP/1.x一樣。HTTP/2基於SPDY，專注於效能，最大的一個目標是在使用者和網站間只用一個連線（connection）。

HTTP2解決的問題

針對http1.x存在的問題，http2針對的解決方案如下：

二進位傳輸HTTP/2 採用二進位格式傳輸數據，而非HTTP 1.x 的文字格式，二進位協定解析起來更有效率。 HTTP / 1 的請求和回應封包，都是由起始行，首部和實體正文（可選）組成，各部分之間以文字換行符分隔。 HTTP/2 將請求和回應資料分割為更小的幀，並且它們採用二進位編碼。
在了解HTTP/2 之前，需要知道一些通用術語：
1. Stream：一個雙向流，一個連接可以有多個streams。
2. Message：也就是邏輯上面的request，response。
3. Frame:：資料傳輸的最小單位。每個Frame 都屬於一個特定的stream 或整個連結。一個message 可能有多個frame 組成。 Frame 是HTTP/2 裡面最小的資料傳輸單位，一個Frame 定義如下:
  Length：也就是Frame 的長度，預設最大長度是16KB，如果要發送更大的Frame，需要明確的設定max frame size。
  Type：Frame 的類型，譬如有DATA，HEADERS，PRIORITY 等。
  Flag 和R：保留位。
  Stream Identifier：標識所屬的stream，如果為0，則表示這個frame 屬於整個連接。
  Frame Payload：根據不同Type 有不同的格式。
Stream 有很多重要特色：
1. 一條連接可以包含多個streams，多個streams 發送的資料互相不影響。
2. Stream 可以被client 和server 單方面或共用使用。
3. Stream 可以被任意一段關閉。
4. Stream 會決定好發送frame 的順序，另一端會按照接受到的順序來處理
5. Stream 用一個唯一ID 來識別。如果是client 建立的stream，ID 就是奇數，如果是server 建立的，ID 就是偶數。

二元傳輸把TCP協議的部分特性挪到了應用層，把原來的”Header+Body”的消息”打散”為數個小片的二進制”幀”(Frame),用”HEADERS”幀存放頭數據、”DATA”幀存放實體數據。 HTP/2資料分幀後」Header+Body」的封包結構就完全消失了，協定看到的只是一個個的」碎片」。

HTTP/2 中，同域名下所有通訊都在單一連線上完成，該連線可以承載任意數量的雙向資料流。每個資料流都以訊息的形式發送，而訊息又由一個或多個訊框組成。多個幀之間可以亂序發送，根據幀首部的流標識可以重新組裝。

Header壓縮

在HTTP/1 中，由於使用文字的形式傳輸header，在header 攜帶cookie和user agent 的情況下，可能每次都需要重複傳輸數百到數千的位元組。 HTTP/2沒有使用傳統的壓縮演算法，而是開發了專門的”HPACK”演算法，在客戶端和伺服器兩端建立“字典”，用索引號表示重複的字串，採用哈夫曼編碼來壓縮整數和字串，可以達到50%~90%的高壓縮率。

具體如下：

HTTP/2 在客戶端和伺服器端使用「首部表」來追蹤和儲存先前傳送的鍵－值對，對於相同的數據，不再透過每次請求和回應傳送；
首部表在HTTP/2 的連線存續期內始終存在，由客戶端和伺服器共同漸進地更新;
每個新的首部鍵－值對要么被追加到當前表的末尾，要么替換表中先前的值

多路復用(請求和回應複用)同個網域只需要佔用一個TCP 連接，在一個TCP 連接上，我們可以向對方不斷發送幀，每幀的stream identifier 的標明這一幀屬於哪個流，然後在對方接收時，根據stream identifier 拼接每個流的所有幀組成一整塊數據。
上面協議解析中提到的stream id就是用作連接共享機制的.一個request對應一個stream並分配一個id，這樣一個連接上可以有多個stream，每個stream的frame可以隨機的混雜在一起，接收方可以根據stream id將frame再歸屬到各自不同的request裡面。請求和回應之間互相不影響
多路復用（MultiPlexing），這個功能相當於是長連接的增強，每個request可以隨機的混雜在一起，接收方可以根據request的id將request再歸屬到各自不同的服務端請求裡面。
多路復用中，支援流的優先權（Stream dependencies），讓客戶端告訴server哪些內容是更優先權的資源，可以優先傳輸。
伺服器端推送HTTP/2 新增的另一個強大的新功能是，伺服器可以對一個客戶端請求發送多個回應。換句話說，除了對最初請求的回應外，伺服器還可以向客戶端推送額外資源，而無需客戶端明確地請求。
服務端可以主動推送，客戶端也有權利選擇是否接收。如果服務端推送的資源已經被瀏覽器快取過，瀏覽器可以透過發送RST_STREAM幀來拒收。
主動推播遵守同源策略, 伺服器不能隨便將第三方資源推送到客戶端，而必須是經過雙方確認才行。
提高安全性HTTP/2延續了HTTP/1的「明文」特點，可以像以前一樣使用明文傳輸數據，不強制使用加密通信，不過格式還是二進制，只是不需要解密。
由於HTTPS已經是大勢所趨，而且主流的瀏覽器Chrome、Firefox等都公開宣布只支援加密的HTTP/2，所以「事實上」的HTTP/2是加密的。也就是說，網路上通常所能看到的HTTP/2都是使用」https」協定名，跑在TLS上面。 HTTP/2協定定義了兩個字串識別碼：「h2」表示加密的HTTP/2，「h2c」表示明文的HTTP/2。

HTTP2存在的問題

http1.x和http2都是基於tcp, tcp作為安全的可靠的傳輸協議，建立連線的延時還是有點高。主要是TCP 以及TCP+TLS建立連線的延遲。
無法解決tcp的隊頭堵塞問題，http2透過多路復用解決http層的對頭堵塞，tcp的失敗重傳的問題還是無解的

HTTP3.0 原理

因為TCP 存在的時間實在太長，已經充斥在各種裝置中，而這個協定是由作業系統實現的，更新起來不大現實。

基於這個原因，Google 就更起爐灶搞了一個基於UDP 協議的QUIC 協議，並且使用在了HTTP/3 上，HTTP/3 之前名為HTTP-over-QUIC，從這個名字中我們也可以發現，HTTP/3 最大的改造就是使用了QUIC。 QUIC（Quick UDP Internet Connections，快速UDP 網路連線）基於UDP, 正是看中了UDP 的速度與效率。同時QUIC 也整合了TCP、TLS 和HTTP/2 的優點，並加以最佳化。

QUIC的次要目標包括減少連線和傳輸延遲，在每個方向進行頻寬估計以避免擁塞。它還將擁塞控制演算法移動到用戶空間，而不是核心空間，此外使用前向糾錯（FEC）進行擴展，以在出現錯誤時進一步提高效能。

HTTP3實作的功能

實現快速握手功能HTTP/2 的連接需要3 RTT，如果考慮會話復用，即把第一次握手算出來的對稱密鑰緩存起來，那麼也需要2 RTT，更進一步的，如果TLS 升級到1.3，那麼HTTP/2 連接需要2 RTT，考慮會話復用則需要1 RTT。而HTTP/3 首次連接只需要1 RTT，後面的連接更是只需0 RTT。
使用QUIC協定的客戶端和服務端要使用1RTT進行密鑰交換，使用的交換演算法是DH(Diffie-Hellman)迪菲-赫爾曼演算法。
首次連線時客戶端和服務端的金鑰協商和資料傳輸過程，其中涉及了DH演算法的基本過程：
1. 客戶端對於首次連線的服務端先發送client hello請求。
2. 服務端產生一個質數p和一個整數g，同時產生一個隨機數為私鑰a，然後計算出公鑰A = mod p，服務端將A，p，g三個元素打包稱為config，後續發送給客戶端。
3. 客戶端隨機產生一個自己的私鑰b，再從config讀取g和p，計算客戶端公鑰B = mod p。然後客戶端根據A、p、b 算出初始金鑰K。 B 和K 算好後，客戶端會用K 加密HTTP 數據，連同B 一起傳送給服務端；
4. 用戶端使用自己的私鑰b和服務端發來的config中讀取的服務端公鑰，產生後續資料加密用的金鑰K = mod p。
5. 用戶端使用密鑰K加密業務數據，並追加自己的公鑰，都傳遞給服務端。
6. 服務端根據自己的私鑰a和客戶端公鑰B產生客戶端加密用的金鑰K = mod p。
7. 為了確保資料安全，上述產生的金鑰K只會產生使用1次，後續服務端會依照相同的規則產生一套全新的公鑰和私鑰，並使用這組公私鑰產生新的金鑰M。
8. 服務端將新公鑰和新金鑰M加密的資料發給客戶端，客戶端根據新的服務端公鑰和自己原來的私鑰計算出本次的金鑰M，進行解密。
9. 之後的客戶端和服務端資料互動都使用密鑰M來完成，密鑰K只使用1次。

客戶端和服務端首次連線時服務端傳遞了config套件，裡麵包含了服務端公鑰和兩個隨機數，客戶端會將config儲存下來，後續再連線時可以直接使用，從而跳過這個1RTT，實現0RTT的業務資料互動。

用戶端保存config是有時間期限的，在config失效後仍需進行首次連線時的金鑰交換。

整合TLS加密功能
1. 向前安全前向安全指的是金鑰洩漏也不會讓先前加密的資料被洩漏，影響的只有當前，對先前的資料無影響。
  QUIC使用config的有效期，後續產生了新金鑰，使用其進行加解密，當時完成互動時則銷毀，從而實現了前向安全。
2. 向前糾錯前向糾錯也叫前向糾錯碼Forward Error Correction 簡稱FEC 是增加資料通訊可信度的方法，在單向通訊頻道中，一旦錯誤被發現，其接收器將無權再請求傳輸。
  FEC 是利用資料進行傳輸冗餘資訊的方法，當傳輸中出現錯誤，將允許接收器再建置資料。
  QUIC每發送一組資料就對這組資料進行異或運算，並將結果作為一個FEC包發送出去，接收方收到這一組資料後根據資料包和FEC包即可進行校驗和糾錯。一段資料被切分為10 個包後，依次對每個包進行異或運算，運算結果會作為FEC 包與資料包一起被傳輸，如果不幸在傳輸過程中有一個資料包丟失，那麼就可以根據剩餘9 個包以及FEC 包推算出丟失的那個包的算出，這樣就大大增加了協議的容錯性。
多路復用，解決tcp中存在的隊頭堵塞問題HTTP2.0協定的多路復用機制解決了HTTP層的隊頭阻塞問題，但在TCP層仍然存在隊頭阻塞問題。
TCP協定在收到資料包之後，這部分資料可能是亂序到達的，但是TCP必須將所有資料收集排序整合後給上層使用，如果其中某個包遺失了，就必須等待重傳，從而出現某個丟包資料阻塞整個連線的資料使用。
QUIC協定是基於UDP協定實現的，在一條連結上可以有多個串流，流與流之間是互不影響的，當一個流出現丟包影響範圍非常小，從而解決隊頭阻塞問題。
實現類似TCP的流量控制(…這部分內容多，看參考)