HTTP 3.0于 2022 年 6 月 6 日正式釋出了，最近盼盼抽出一些時間專門看了下，總結了一下，分享給大家學習。
HTTP3.0何改造UDP？
在HTTP2.0中推出了許多重要的優化，如二進制分幀協定、多路複用、頭部壓縮、服務端推送等，大幅度的提高了HTTP的性能，将其推上了新的台階。
但即使性能得到了優化，HTTP在某些地方還是不滿足大家的預期，主要是TCP帶來的影響。如：
- 建立連接配接的時間過長
- 隊頭阻塞
- 移動網絡切換時無法保持連接配接
- 網絡切換時需要重建立立連接配接
TCP影響性能的一些特點，那為什麼最終選用了UDP呢？
- 基于TCP的裝置、協定、應用特别多，帶來的影響特别大，難以相容。
- TCP協定棧是Linux核心中的重要部分，修改、更新、相容的成本特别大。
- TCP協定複雜，改造難度高。
既然TCP走不通，此時谷歌就将目光放到了同樣是傳輸層協定的UDP身上。
UDP的幾個特點:
- UDP無連接配接（沒有建立連接配接和結束連接配接的成本）
- UDP資料無序，且資料報之間沒有關聯（無隊頭阻塞問題）
- UDP協定簡單（修改成本低）
- UDP的幾個特點都完全滿足我們的需求，而唯一的缺陷就是UDP無法像TCP一樣具有可靠性。
是以谷歌決定中UDP的基礎上改造出一個具備TCP優點的新協定——QUIC協定。
QUIC協定
QUIC ，即快速UDP網絡連接配接 (Quick UDP Internet Connections )， 是由谷歌提出的實驗性網絡傳輸協定 ，位于OSI模型的傳輸層。
QUIC旨在解決TCP協定的缺陷，并最終替代TCP協定， 以減少資料傳輸，降低連接配接建立延遲時間，加快網頁傳輸速度。
QUIC主要特點如下
QUIC資料格式
QUIC連接配接建立 回顧HTTPS的握手過程包含TCP握手和TLS握手
建立連接配接-QUIC
多路複用
首次提出：HTTP2
定義：單個TCP連接配接上可以同時發送多個HTTP請求。
目的：解決HTTP1.1中單個連接配接1次隻能發送一個請求的性能瓶頸 1個請求對應1個流，通過Stream ID就可以判斷該資料幀屬于哪個請求。
假設有A和B兩個請求，對應的Stream ID分别為1和2。
前向糾錯
前向糾錯是一種差錯控制方式，它是指信号在被送入傳輸信道之前預先按一定的算法進行編碼處理，加入帶有信号本身特征的冗碼，在接收端按照相應算法對接收到的信号進行解碼，進而找出在傳輸過程中産生的錯誤碼并将其糾正的技術。
當出現丢包時，TCP采用的是重傳機制，而QUIC采用的是前向糾錯機制。
- 對于TCP來說，如果發生丢包，則需要一個等待延時判斷是否發生了丢包，然後再啟動重傳機制，這個過程會造成一定的阻塞，影響傳輸的時間。
- QUIC每發送一組資料就對這組資料進行異或運算，并将結果作為一個校驗和包發送出去。如果前面這組資料中出現了丢包的情況，就可以通過校驗和與其他包來還原出丢包的資料，避免了重傳帶來的損耗。
連接配接遷移
在目前的移動網絡環境下，使用者的網絡随時都有可能發生切換，比如從移動網絡切換到WIFI環境，此時我們的IP位址就會發生變化。
由于TCP協定使用五元組（源IP，源端口，目的IP，目的端口，傳輸層協定） 來唯一表示一條連接配接，是以之前的連接配接就不可能繼續保持，就需要重建立立TCP連接配接。
為了解決這個問題，基于UDP實作的QUIC完全摒棄了五元組的概念，其通過生成一個64位的随機數作為連接配接的辨別，即使當我們發生了IP位址的切換，這個辨別也不會發生任何變化，我們就可以快速的恢複連接配接，大大的改善了移動端應用的體驗。
總結
QUIC是如何提升網絡加載速度的？
- 降低連接配接耗時：在用戶端有緩存的情況下實作 0-RTT 建立連接配接
- 更靈活的擁塞控制：在使用者态可以為每個請求配置不同的擁塞控制政策
- 無隊頭阻塞的多路複用：在使用者态可以為每個請求配置不同的擁塞控制政策
- 連接配接遷移：網絡切換不會中斷資料傳輸