在 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）。對於訪問速度的優化方式越來越多，適當的選擇可以爲網站增色許多。
出處：知道創宇前端（https://knownsec-fed.com/2018-01-19-xia-yi-dai-tong-xin-xie-yi-quic/）