在 HTTP 協議已經佔據網際網路大半江山的今天，儘管網速越來越快，但是人類還是致力於將網路傳輸速率提升到極致。
從 HTTP/1.x 到 HTTP/2，TCP 已經不能滿足人類貪婪的慾望了，他們開始向常年被忽視的 UDP 進軍。
QUIC 是什麼？
QUIC（Quick UDP Internet Connections），直譯過來就是“快速的 UDP 網際網路連線”，是 Google 基於 UDP 提出的一種改進的通訊協議，作為傳統 HTTP over TCP 的替代品，開源於 Chromium 專案中。
為了加快 TCP 的傳輸效率，Google 提出了 BBR 擁塞控制演算法，將 TCP 的效能發揮到了極致。由於 TCP 和 UDP 協議是系統核心實現的，要提出新的協議不是不行，只是普及起來會非常困難，就連 BBR 演算法，都需要更新系統核心才能支援。那麼，TCP 的效能已經到了極致，還能更快嗎？
UDP 相比於 TCP，沒有那麼多的要求，只要將資料發出去就行了，不需要考慮資料是否送達了、不需要考慮資料的到達順序、不需要考慮資料的正確性和完整性，所以效率比 TCP 要高出幾個檔次。
UDP 協議曾經被普遍用於視訊直播、網路遊戲之類實時性要求較高的應用，即使少數幾個包沒有送達對應用整體的影響也不大。可是，對於 HTTP 之類的協議，是需要保證資料的正確性、完整性的，所以 UDP 本身並不適合作為 TCP 的替代品。
UDP 不適合替代 TCP 是因為它本身不對資料進行校驗，那麼如果將資料校驗放到其他地方去實現，是不是就可以使用 UDP 了呢？
於是，QUIC 就誕生了，它彙集了 TCP 和 UDP 的優點，使用 UDP 來傳輸資料以加快網路速度，降低延遲，由 QUIC 來保證資料的順序、完整性和正確性，即使發生了丟包，也由 QUIC 來負責資料的 糾錯。
現在，Google 旗下的部分服務（比如 GMail）以及許多介面已經開始使用 QUIC 協議了。如果你使用的是 Chrome 瀏覽器，可以在瀏覽器的這個地址：chrome://net-internals/#quic 看到 QUIC 的連線情況。
QUIC 的優點
由於 TCP、UDP 協議是系統核心實現的，更新修改起來並不很方便，而 QUIC 是軟體層面實現的，更新迭代起來非常方便。
UDP 本身是無序傳輸的，這在單個連線上並行傳輸多個資料有天生的優勢：多個資料直接傳送即可，由 QUIC 對收到的資料進行重新組合排序，然後送往上層應用。這中間不用等待各種資料確認包，效率非常高。
在建立 TCP 連線時，需要進行至少三次握手，如果要開啟 TLS 加密，則還需要進行 TLS 握手。而 QUIC 採用了類似於 TCP Fast Open 的技術，如果之前連線過，那麼之後可以不用重複握手而直接開始傳送資料，以實現 0-RTT 往返時延。即便之前沒有連線過，也可以在 1-RTT 內完成連線並開始傳送資料。並且自身就擁有與 TLS 等效的加密措施。
在發生丟包時，TCP 會重傳丟失的包。而 QUIC，則使用了一種非常神奇的前向糾錯演算法，通過連續的幾個資料包的校驗和，可以直接恢復出丟失的包內容，而不需要重傳。
在移動端表現更好：使用者的網路環境並不穩定，Wi-Fi、4G、3G、2G 之間來回變化，IP 一旦發生變化，TCP 的連線是不可能保持的。而 QUIC 就不存在這樣的問題，通過 ID 來標識使用者（而不是 IP + 埠），在連線切換後直接恢復之前的連線會話。
配合 HTTP/2 API 食用更佳：由於 HTTP/2 採用二進位制幀傳輸機制，QUIC 直接使用這樣的機制進行資料傳輸，效率更高！
QUIC 的缺點
現在很多網路運營商會降低 UDP 包的優先順序，使得 UDP 丟包率特別高。（QUIC 不可用時，瀏覽器一般會 Fallback 到 TCP）
目前只有 Chrome、Opera 瀏覽器支援。
什麼時候更適合使用 QUIC？
- 移動端 由於 QUIC 並不使用 IP + 埠來標識客戶身份，而是使用 ID，這使得在網路環境切換後還可以保持連線，非常適合用在移動網站上面，在手機訊號不穩定的情況下，TCP + TLS 的開銷是非常大的！QUIC 的 0-RTT 可以極大限度地提升訪問速度。
總結
QUIC 實現的目標，就是利用 UDP 實現一個 TCP，支援 TCP 的所有特性，並且比 TCP 更快更好用。
QUIC 是從 2012 年開始的專案，到目前也還只是草案階段，並且同樣處於草案階段的 TLS1.3 也同樣擁有了 QUIC 中的很多優點（比如 0-RTT）。對於訪問速度的優化方式越來越多，適當的選擇可以為網站增色許多。
關注微信公眾號：創宇前端（KnownsecFED），碼上獲取更多優質乾貨！
