Quic 全稱 quick udp internet connection “快速 UDP 互聯網連接”，由 google 提出的使用 udp 進行多路並發傳輸的協議.
為什么需要QUIC
1. 協議歷史悠久導致中間設備僵化
2. 依賴於操作系統的實現導致協議本身僵化
3. 建立連接的握手延遲大
a. HTTPS 和 HTTP2 還需要使用 TLS 協議來進行安全傳輸。這就出現了兩個握手延遲：
i. TCP 三次握手導致的 TCP 連接建立的延遲
ii. TLS 完全握手需要至少 2 個 RTT 才能建立，簡化握手需要 1 個 RTT 的握手延遲
b. 對於很多短連接場景，這樣的握手延遲影響很大，且無法消除
4. 隊頭阻塞
a. 隊頭阻塞主要是 TCP 協議的可靠性機制引入的。TCP 使用序列號來標識數據的順序，數據必須按照順序處理，如果前面的數據丟失，后面的數據就算到達了也不會通知應用層來處理
b. 另外 TLS 協議層面也有一個隊頭阻塞，因為 TLS 協議都是按照 record 來處理數據的，如果一個 record 中丟失了數據，也會導致整個 record 無法正確處理
c. QUIC 協議選擇了 UDP，因為 UDP 本身沒有連接的概念，不需要三次握手，優化了連接建立的握手延遲，同時在應用程序層面實現了 TCP 的可靠性，TLS 的安全性和 HTTP2 的並發性，只需要用戶端和服務端的應用程序支持 QUIC 協議，完全避開了操作系統和中間設備的限制
優勢
Quic 相比現在廣泛應用的 http2+tcp+tls 協議有如下優勢：
1 減少了 TCP 三次握手及 TLS 握手時間
a. 0RTT 建連可以說是 QUIC 相比 HTTP2 最大的性能優勢
i. 傳輸層 0RTT 就能建立連接
ii. 加密層 0RTT 就能建立加密連接
2 改進的擁塞控制
a. TCP 的擁塞控制實際上包含了四個算法：慢啟動，擁塞避免，快速重傳，快速恢復
b. QUIC 協議當前默認使用了 TCP 協議的 Cubic 擁塞控制算法 [6]，同時也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等擁塞控制算法
c. 從擁塞算法本身來看，QUIC 只是按照 TCP 協議重新實現了一遍，那么 QUIC 協議到底改進在哪些方面呢？主要有如下幾點:
i. 可插拔
ii. 單調遞增的Packet Number
iii. 不允許 Reneging
iv. 更多的 Ack 塊
v. Ack Delay 時間
vi. 基於 stream 和 connecton 級別的流量控制
vii. 加密認證的報文
3 避免隊頭阻塞的多路復用
a. HTTP2多路復用
i. 多路復用是 HTTP2 最強大的特性 [7]，能夠將多條請求在一條 TCP 連接上同時發出去。但也惡化了 TCP 的一個問題，隊頭阻塞
ii. 由於 HTTP2 強制使用 TLS，還存在一個 TLS 協議層面的隊頭阻塞
b. QUIC多路復用
i. QUIC 最基本的傳輸單元是 Packet，不會超過 MTU 的大小，整個加密和認證過程都是基於 Packet 的，不會跨越多個 Packet。這樣就能避免 TLS 協議存在的隊頭阻塞。
ii. Stream 之間相互獨立，比如 Stream2 丟了一個 Pakcet，不會影響 Stream3 和 Stream4。不存在 TCP 隊頭阻塞。
連接遷移
a. 當其中任何一個元素發生變化時，這條連接依然維持着，能夠保持業務邏輯不中斷。當然這里面主要關注的是客戶端的變化，因為客戶端不可控並且網絡環境經常發生變化，而服務端的 IP 和端口一般都是固定的
b. 那 QUIC 是如何做到連接遷移呢？
i. 很簡單，任何一條 QUIC 連接不再以 IP 及端口四元組標識，而是以一個 64 位的隨機數作為 ID 來標識，這樣就算 IP 或者端口發生變化時，只要 ID 不變，這條連接依然維持着，上層業務邏輯感知不到變化，不會中斷，也就不需要重連。
ii. 由於這個 ID 是客戶端隨機產生的，並且長度有 64 位，所以沖突概率非常低
前向冗余糾錯
在重要的包比如握手消息發生丟失時，能夠根據冗余信息還原出握手消息
證書壓縮，減少證書傳輸量，針對包頭進行驗證