初識——HTTP3

貝貝子發表於2022-03-12
HTTP

目錄

初識——HTTP3

想了解HTTP3？？那我們就得先知道為啥會出現HTTP3，因此我們需要知道HTTP1.0，HTTP1.1，HTTP2及HTTP3的演變過程。

HTTP

HTTP 是超⽂本傳輸協議，也就是HyperText Transfer Protocol。

HTTP 端⼝號：80

HTTP 由於是明⽂傳輸，所以安全上存在以下三個⻛險： 竊聽⻛險， 篡改⻛險，冒充⻛險。

HTTP1.0和HTTP1.1的主要區別

長連線

HTTP 1.0需要使用keep-alive引數來告知伺服器端要建立一個長連線，而HTTP1.1預設支援長連線。

節約頻寬

HTTP 1.1支援只傳送header資訊(不帶任何body資訊)，如果伺服器認為客戶端有許可權請求伺服器，則返回100，否則返回401。客戶端如果接受到100，才開始把請求body傳送到伺服器。

這樣當伺服器返回401的時候，客戶端就可以不用傳送請求body了，節約了頻寬。

另外HTTP還支援傳送內容的一部分。這樣當客戶端已經有一部分的資源後，只需要跟伺服器請求另外的部分資源即可。這是支援檔案斷點續傳的基礎。

HOST域

現在可以web server例如tomat，設定虛擬站點是非常常見的，也即是說，web server上的多個虛擬站點可以共享同一個ip和埠。

HTTP1.0是沒有host域的，HTTP1.1才支援這個引數

HTTP1.1 相比 HTTP1.0 效能上的改進：

使⽤ TCP ⻓連線的⽅式改善了 HTTP1.0 短連線造成的效能開銷。

⽀持管道（pipeline）⽹絡傳輸，只要第⼀個請求發出去了，不必等其回來，就可以發第⼆個請求出去，可以 減少整體的響應時間。

但 HTTP1.1 還是有效能瓶頸：

  1. 請求響應頭部（Header）未經壓縮就傳送，⾸部資訊越多延遲越⼤。只能壓縮 Body 的部分；

  2. 傳送冗⻓的⾸部。每次互相傳送相同的⾸部造成的浪費較多；

  3. 伺服器是按請求的順序響應的，如果伺服器響應慢，會招致客戶端⼀直請求不到資料，也就是隊頭阻塞；

    管道（ pipeline）傳輸中如果有⼀個請求阻塞了，那麼佇列後請求也統統被阻塞住了

  4. 沒有請求優先順序控制；

  5. 請求只能從客戶端開始，伺服器只能被動響應。

根據HTTP1.1 的效能瓶頸，HTTP2 做了什麼優化？

HTTP2

HTTP2 協議是基於 HTTPS 的，所以 HTTP2 的安全性也是有保障的。

那 HTTP2 相⽐ HTTP1.1 效能上的改進：

  1. 頭部壓縮

HTTP2 會壓縮頭（Header）如果你同時發出多個請求，他們的頭是⼀樣的或是相似的，那麼，協議會幫你消除重複的部分。

這就是所謂的 HPACK演算法：在客戶端和伺服器同時維護⼀張頭資訊表，所有欄位都會存⼊這個表，⽣成⼀個索 引號，以後就不傳送同樣欄位了，只傳送索引號，這樣就提⾼速度了。

  1. ⼆進位制格式

HTTP2 不再像 HTTP1.1⾥的純⽂本形式的報⽂，⽽是全⾯採⽤了⼆進位制格式，頭資訊和資料體都是⼆進位制，並 且統稱為幀（frame）：頭資訊幀和資料幀。

初識——HTTP3

這樣雖然對⼈不友好，但是對計算機⾮常友好，因為計算機只懂⼆進位制，那麼收到報⽂後，⽆需再將明⽂的報⽂轉 成⼆進位制，⽽是直接解析⼆進位制報⽂，這增加了資料傳輸的效率。

  1. 資料流

HTTP2 的資料包不是按順序傳送的，同⼀個連線⾥⾯連續的資料包，可能屬於不同的回應。因此，必須要對資料包做標記，指出它屬於哪個回應。每個請求或回應的所有資料包，稱為⼀個資料流（ Stream ）。

每個資料流都標記著⼀個獨⼀⽆⼆的編號，其中規定客戶端發出的資料流編號為奇數，伺服器發出的資料流編號為偶數。

客戶端還可以指定資料流的優先順序。優先順序⾼的請求，伺服器就先響應該請求

初識——HTTP3
  1. 多路復⽤

HTTP2是可以在⼀個連線中併發多個請求或回應，⽽不⽤按照順序⼀⼀對應。

移除了 HTTP1.1中的串⾏請求，不需要排隊等待，也就不會再出現「隊頭阻塞」問題，降低了延遲，⼤幅度提⾼了連線的利⽤率。

舉例來說，在⼀個 TCP 連線⾥，伺服器收到了客戶端 A 和 B 的兩個請求，如果發現 A 處理過程⾮常耗時，於是就 回應 A 請求已經處理好的部分，接著回應 B 請求，完成後，再回應 A 請求剩下的部分。

  1. 務器推送

HTTP2還在⼀定程度上改善了傳統的「請求 - 應答」⼯作模式，服務不再是被動地響應，也可以主動向客戶端發 送訊息。

舉例來說，在瀏覽器剛請求 HTML 的時候，就提前把可能會⽤到的 JS、CSS ⽂件等靜態資源主動發給客戶端，減 少延時的等待，也就是伺服器推送（Server Push，也叫 Cache Push）。

HTTP2 也存在缺陷

HTTP2多個請求復⽤⼀個TCP連線，⼀旦發⽣丟包， 就會觸發 TCP 的重傳機制 ，⼀個 TCP 連線中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。 ，就會阻塞住所有的 HTTP 請求。

因此HTTP2也是存在阻塞的問題，那麼HTTP3是不是就來解決阻塞問題的呢？？

HTTP3

HTTP3把 HTTP 下層的 TCP 協議改成了 UDP！

我們都知道 UDP 發⽣是不管順序，也不管丟包的，所以不會出現 HTTP1.1 的隊頭阻塞 和 HTTP2 的⼀個丟包全部重傳問題。

眾所周知UDP是不可靠傳輸，那HTTP3怎麼做到可靠的呢？？？

UDP是不可靠傳輸的，但基於UDP的 QUIC 協議（ 基於UDP的低時延的網際網路傳輸層協議 ） 可以實現類似 TCP 的可靠性傳輸。

QUIC （Quick UDP Internet Connection） 在應用程式層面（應用層） 實現了 TCP 的可靠性，TLS 的安全性和 HTTP2 的併發性，只需要使用者端和服務端的應用程式支援 QUIC 協議，完全避開了作業系統和中間裝置的限制。

用一個等式來描述就是 QUIC = UDP + TLS + HTTP2

什麼是作業系統和中間裝置的限制？？？？？？

TCP是在作業系統核心和中間裝置韌體中實現的。要對TCP進行大更改，就必須要通訊雙方升級作業系統，中間裝置更新韌體，部署成本非常高。

通過QUIC改進擁塞控制體現在哪幾個方面？？

  1. QUIC在應用層即可實現不同的擁塞控制演算法，不需要改作業系統和核心。
  2. 單個程式的不同連線也能支援配置不同的擁塞控制。這樣我們就可以給不同的使用者提供更好的擁塞控制。
  3. 應用程式變更擁塞控制，甚至不需要停機和升級。
  4. QUIC還有頻寬預測，RTT監控，傳送速率調整等高階演算法支援。

擴充套件幾點：

  • QUIC 有⾃⼰的⼀套機制可以保證傳輸的可靠性的。當某個流發⽣丟包時，只會阻塞這個流，其他流不會受到影響。
  • TLS3 升級成了最新的 1.3 版本，頭部壓縮演算法也升級成了 QPack 。
  • HTTPS 要建⽴⼀個連線，要花費 6 次互動，先是建⽴三次握⼿，然後是 TLS/1.3 的三次握⼿。QUIC 直接 把以往的 TCP 和 TLS/1.3 的 6 次互動合併成了 3 次，減少了互動次數。

相關連結

文章只是簡單的就HTTP1.1和HTTP2共同的一個阻塞問題來討論HTTP3是如何改進優化的。雖然覺得HTTP3很好，但是現在還未得到普遍使用。如果對HTTP3感興趣可以看下面的相關連結，講解更深入。

科普：QUIC協議原理分析

QUIC網路協議簡介

相關文章