和 TCP 相反，UDP 協議是無連接協議。客戶端發出 UDP 數據包后，只能“假設”這個數據包已經被服務端接收。這樣的好處是在網絡傳輸層無需對數據包進行確認，但存在的問題就是為了確保數據傳輸的可靠性，應用層協議需要自己完成包傳輸情況的確認。
此時，QUIC 協議就登場了。
QUIC 是 Quick UDP Internet Connections 的縮寫，谷歌發明的新傳輸協議。
與 TCP 相比，QUIC 可以減少延遲。
QUIC 協議可以在 1 到 2 個數據包（取決于連接的服務器是新的還是已知的）內，完成連接的創建（包括 TLS）（如下圖3所示）。
▲ 圖 3 - QUIC 協議握手原理圖
從表面上看：QUIC 非常類似于在 UDP 上實現的 TCP + TLS + HTTP/2。由于 TCP 是在操作系統內核和中間件固件中實現的，因此對 TCP 進行重大更改幾乎是不可能的（TCP 協議棧通常由操作系統實現，如 Linux、Windows 內核或者其他移動設備操作系統。修改 TCP 協議是一項浩大的工程，因為每種設備、系統的實現都需要更新）。但是，由于 QUIC 建立在 UDP 之上，因此沒有這種限制。QUIC 可以實現可靠傳輸，而且相比于 TCP，它的流控功能在用戶空間而不在內核空間，那么使用者就不受限于 CUBIC 或是 BBR，而是可以自由選擇，甚至根據應用場景自由調整優化。
QUIC 與現有 TCP + TLS + HTTP/2 方案相比，有以下幾點主要特征：
1）利用緩存，顯著減少連接建立時間；
2）改善擁塞控制，擁塞控制從內核空間到用戶空間；
3）沒有 head of line 阻塞的多路復用；
4）前向糾錯，減少重傳；
5）連接平滑遷移，網絡狀態的變更不會影響連接斷線。
從圖上可以看出，QUIC 底層通過 UDP 協議替代了 TCP，上層只需要一層用于和遠程服務器交互的 HTTP/2 API。這是因為 QUIC 協議已經包含了多路復用和連接管理，HTTP API 只需要完成 HTTP 協議的解析即可。
有關QUIC的詳解請見：《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》。