QUIC，快速UDP網絡連接協議
QUIC ，即 快速UDP網絡連接 ( Quick UDP Internet Connections )， 是由 Google 提出的實驗性網絡傳輸協議 ，位於 OSI 模型傳輸層。 QUIC 旨在解決 TCP 協議的缺陷，並最終替代 TCP 協議， 以減少數據傳輸，降低連接建立延遲時間，加快網頁傳輸速度。
QUIC 主要特點有：
- 多流設計；
- 低等待延遲；
- 加密性能更優；
- 前向糾錯；
- 應用程序實現；
- 連接保持；
多流設計
採用 多路複用 思想，一個連接可以同時承載多個 流 ( stream )，同時發起多個請求。 請求間完全 獨立 ，某個請求阻塞甚至報文出錯均不影響其他請求。
對比 HTTP 長連接，由於 TCP 是隻實現一個字節流，如果請求阻塞，新請求無法發起。
低等待延遲
先考察典型的 TLS 連接建立過程：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ufuYvJOM-1584590152833)(https://linux-network-programming.readthedocs.io/zh_CN/latest/_images/b6c3265b63fd50ce949c3df89a6326d2.png)]
- 首先，執行三次握手，建立 TCP 連接(藍色部分)；
- 然後，執行 TLS 握手，建立 TLS 連接(黃色部分)；
- 此後開始傳輸業務數據；
客戶端和服務器之間要進行好幾輪協議交互，才能建立 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網絡編程 ，轉至 原文 可獲得最佳閱讀體驗。
訂閱更新，獲取更多學習資料，請關注我們的 微信公衆號 ：
