下一代通訊協議：QUIC

時間 2019-11-09

標籤下一代通訊協議 quic 简体版

原文原文鏈接

在 HTTP 協議已經佔據互聯網大半江山的今天，儘管網速愈來愈快，可是人類仍是致力於將網絡傳輸速率提高到極致。前端

從 HTTP/1.x 到 HTTP/2，TCP 已經不能知足人類貪婪的慾望了，他們開始向常年被忽視的 UDP 進軍。算法

QUIC 是什麼？

QUIC（Quick UDP Internet Connections），直譯過來就是「快速的 UDP 互聯網鏈接」，是 Google 基於 UDP 提出的一種改進的通訊協議，做爲傳統 HTTP over TCP 的替代品，開源於 Chromium 項目中。chrome

爲了加快 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 是軟件層面實現的，更新迭代起來很是方便。ui

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 直接使用這樣的機制進行數據傳輸，效率更高！