QUIC 協議

QUIC ，即 快速UDP網絡鏈接 ( Quick UDP Internet Connections )， 是由 Google 提出的實驗性網絡傳輸協議 ，位於 OSI 模型傳輸層。 QUIC 旨在解決 TCP 協議的缺陷，並最終替代 TCP 協議， 以減小數據傳輸，下降鏈接創建延遲時間，加快網頁傳輸速度。

原文地址： https://network.fasionchan.com

歡迎關注咱們的微信公衆號：小菜學編程 (coding-fan)
歡迎加入咱們的技術交流羣：Linux網絡編程 (183196643)

QUIC 主要特色有：

• 多流設計；
• 低等待延遲；
• 加密性能更優；
• 前向糾錯；
• 應用程序實現；
• 鏈接保持；

多流設計

採用 多路複用 思想，一個鏈接能夠同時承載多個 流 ( stream )，同時發起多個請求。 請求間徹底 獨立 ，某個請求阻塞甚至報文出錯均不影響其餘請求。

對比 HTTP 長鏈接，因爲 TCP 是隻實現一個字節流，若是請求阻塞，新請求沒法發起。

低等待延遲

先考察典型的 TLS 鏈接創建過程：

1. 首先，執行三次握手，創建 TCP 鏈接(藍色部分)；
2. 而後，執行 TLS 握手，創建 TLS 鏈接(黃色部分)；
3. 此後開始傳輸業務數據；

客戶端和服務器之間要進行好幾輪協議交互，才能創建 TLS 鏈接，延遲至關嚴重。 平時訪問 https 網站明顯比 http 網站慢，三次握手和 TLS 握手難辭其咎。

註解:

注意到，三次握手中的 ACK 包與 ClientHello 合併在一塊兒發送。 這是 TCP 實現中使用的 延遲確認 技術，旨在減小協議開銷，改善網絡性能。

那麼，能不能將 TCP 三次握手和 TLS 合併起來呢？ 若是客戶端在發送 SYN 包的同時將 ClientHello 一塊兒發給服務端； 服務端響應 SYN/ACK 包時也帶上相關 TLS 握手包，那麼將能夠節省一塊兒往返時間！

這即是 QUIC 下降延遲的思路，但在 SYN 集成其餘協議協議控制已然不可能。 所以， QUIC 採用基於 UDP 協議之上，在應用程序內實現傳輸控制協議的方案。

加密性能更優

新的安全機制比 TLS 性能更好，並且具備各類攻擊防護策略。

前向糾錯

TCP 採用 重傳 機制，而 QUIC 採用 糾錯 機制。

TCP 發生丟包時，須要一個等待延時判斷髮生了丟包，而後再啓動重傳機制，這個過程會形成必定的阻塞，影響傳輸時間。

而 QUIC 則採用一種更主動的方案，有點相似 RAID5 ，每 n 個包額外發一個 校驗和包 。 若是這 n 個包中丟了一個包，能夠經過其餘包和校驗和恢復出來，徹底不須要重傳。

應用程序內實現

QUIC 直接基於客戶端(應用進程)實現，而非基於內核，能夠快速迭代更新，不須要操做系統層面的改造，部署靈活。 這也是不使用基於迭代升級 TCP 方案的緣由 —— TCP 在操做系統內核中實現，很難進行大規模調整以及推廣。

鏈接保持

QUIC 在客戶端保存鏈接標識，當客戶端 IP 或者端口發生變化時，能夠快速恢復鏈接 —— 客戶端以標識請求服務端，服務端驗證標識後感知客戶端新地址端口並從新關聯，繼續通信。 這對於改善移動端應用鏈接體驗意義重大(從 WiFi 切換到流量)。

附錄

更多網絡技術文章請訪問：Linux網絡編程

訂閱更新，獲取更多學習資料，請關注咱們的 微信公衆號 ：