Google 的 QUIC 華麗轉身成爲下一代網絡協議： HTTP/3.0

HTTP/2.0 尚未普及，HTTP/3.0 標準就要被制定了。

據 IETF 透露，HTTP-over-QUIC 實驗協議將被重命名爲 HTTP/3，併成爲 HTTP 協議的第三個正式版本。

IETF 是 Internet Engineering Task Force 的縮寫，意思是互聯網工程任務小組，主要負責互聯網標準的開發和推進。被他們「欽定」，HTTP-over-QUIC 成爲HTTP/3.0 算是沒跑了。

QUIC

先來了解一下什麼是 QUIC。

QUIC（Quick UDP Internet Connections），是快速 UDP 互聯網鏈接的縮寫，這是一種實驗性的傳輸層協議，由 Google 開發，在 2013 年實現。

QUIC 是基於 UDP 協議，它在兩個端點之間建立鏈接，且支持多路複用。在設計之初 QUIC 但願可以提供等同於 SSL/TLS 層級的安全保障的同時，減小數據傳輸及建立鏈接時的延遲時間，雙向控制帶寬，從而達到更快速的體驗。

QUIC 相比如今普遍應用的 HTTP2 + TCP + TLS 協議有以下的優點：

1. 減小 TCP 三次握手及 TLS 握手時間。
2. 改進的擁塞控制。
3. 避免隊頭阻塞的多路複用。
4. 鏈接遷移。
5. 前向冗餘糾錯。

HTTP-over-QUIC 算是 QUIC 協議的一種應用實現，而在 IETF 開始標準化該協議時，也有意將它分爲兩層：傳輸和 HTTP 部分。

這個想法也是想將 QUIC 傳輸的部分獨立出來，這樣能夠方便的用於其餘場景下的數據傳輸，而不單單爲 HTTP 或者其餘類 HTTP 的協議使用。

Google 與 QUIC

Google 一直在對協議標準上作努力，早年間提出的 SPDY 協議，被 IETF 標準化以後推出了相似於 SPDY 的 HTTP/2.0 協議標準，Google 當即宣佈放棄對 SPDY 的支持，轉而支持 HTTP/2。而 QUIC 也是 Google 提出的一種基於 UDP 的傳輸協議。

Google 但願 QUIC 可以慢慢取代 TCP 和 UDP，成爲移動互聯網上，二進制數據傳輸的新協議。經過 Google 的測試證實，QUIC 更快也更安全。

QUIC 即 HTTP/3.0

QUIC 雖然在 2013 年就被 Google 提出，可是直到 2015 年才被提議做爲 IETF 的標準草案，並在一年以後，就是 2016 年 7 月，提出了 HTTP-over-QUIC。

在上個月的郵件討論中，IETF HTTP 和 QUIC 工做組主席 Mark Nottingham 正式提出將 HTPP-over-QUIC 重命名爲 HTTP/3.0。隨後的幾天討論中，此項提議被 IETF 成員接受，並給出了官方承認。

自此，HTTP-over-QUIC 正式成爲 HTTP/3.0，爲 HTTP 協議的下一個主要版本。

QUIC 還有多遠

雖然 Chrome 從 29 版本開始就添加了 HTTP-over-QUIC 的支持，而且今年開始 Facebook 也開始採用這項技術。

可是這個在 HTTP/2.0 還不是主流的環境下，HTTP/3.0 已經肯定，它就在將來的某個地方。

據 W3Techs 統計，截止到 2018 年 11 月，前 1000 萬網站在中，有 31.2% 支持了 HTTP/2.0，而 QUIC 只有 1.2%，從趨勢上看，能夠說離咱們還很遠。

小結

HTTP/3.0 是一個仍在開發中的協議，計劃在今年內完成，可是能夠預見的，它離普及還很遠。

不少協議的設計思想是很是值得咱們借鑑與學習的，對協議有興趣的朋友，我找了一篇騰訊團隊的資深研發工程師寫的一篇 QUIC 協議的原理分析，通俗易懂，有興趣能夠點擊「閱讀原文」查看。

以爲有幫助記得點贊和分享哦，謝謝。

參考：

https://www.zdnet.com/article...
https://daniel.haxx.se/blog/2...
https://zhuanlan.zhihu.com/p/...

---

公衆號後臺回覆成長『 成長』，將會獲得我準備的學習資料，也能回覆『 加羣』，一塊兒學習進步；你還能回覆『 提問』，向我發起提問。

推薦閱讀：

圖解 Chrome，架構篇 | 利用預處理腳本，管理小程序代碼| 分詞，科普及解決方案| 圖解：HTTP 範圍請求 | 小程序學習資料 |HTTP 內容編碼 | 輔助模式實戰 | 輔助模式玩出花樣 | 小程序 Flex 佈局