一泡尿的時間，快速讀懂QUIC協議
一、TCP協議到底怎麼了？
現時的互聯網應用中，Web平臺（準確地說是基於HTTP及其延伸協議的客戶端/服務器應用）的數據傳輸都基於 TCP 協議。php
但TCP 協議在建立鏈接以前須要進行三次握手（以下圖 1，更詳細原理請見《理論經典：TCP協議的3次握手與4次揮手過程詳解》），若是須要提升數據交互的安全性，既增長傳輸層安全協議（TLS），還會增長更多的更多握手次數（以下圖 2）。html
正如上面兩張圖裏演示的原理，TCP 協議鏈接創建的成本相對較高。nginx
因此，通常的穩定網絡傳輸都是經過TCP，可是在網絡基建自己就已經愈來愈完善的狀況下，TCP設計自己的問題便暴露了出來，特別是在弱網環境下，讓咱們不得不考慮一些新的可能性。git
（本文同步發佈於：http://www.52im.net/thread-2816-1-1.html）程序員
二、QUIC協議登場
和 TCP 相反，UDP 協議是無鏈接協議。客戶端發出 UDP 數據包後，只能「假設」這個數據包已經被服務端接收。這樣的好處是在網絡傳輸層無需對數據包進行確認，但存在的問題就是爲了確保數據傳輸的可靠性，應用層協議須要本身完成包傳輸狀況的確認。github
此時，QUIC 協議就登場了。web
QUIC 是 Quick UDP Internet Connections 的縮寫，谷歌發明的新傳輸協議。面試
與 TCP 相比，QUIC 能夠減小延遲。chrome
QUIC 協議能夠在 1 到 2 個數據包（取決於鏈接的服務器是新的仍是已知的）內，完成鏈接的建立（包括 TLS）（以下圖3所示）。apache
▲ 圖 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詳解》。
三、QUIC協議的目標
QUIC 協議的主要目的，是爲了整合 TCP 協議的可靠性和 UDP 協議的速度和效率。
一張圖看懂QUIC協議的優點：
對於 Google 來講優化 TCP 協議是一個長期目標，QUIC 旨在建立幾乎等同於 TCP 的獨立鏈接，但有着低延遲，並對相似 SPDY 的多路複用流協議有更好的支持。 若是 QUIC 協議的特性被證實是有效的，這些特性之後可能會被遷移入後續版本的 TCP 和 TLS 協議（它們都有很長的開發週期）。
值得注意的是，雖然理論上來講，若是 QUIC 的特性被證實是有效的，這些特性之後可能會被遷移到後續版本的 TCP 協議中，但鑑於TCP協議長達幾十年在互聯網通訊裏的壟斷地位，以及這麼多年積累下來的沉重歷史報復，想要根本性地優化或改進TCP協議，難度至關大（或許，有些事情，只能是想一想而已，IPV6還喊了這麼多年呢，不是同樣沒普及。。。）。
四、QUIC協議這麼好，能夠大規模切換爲QUIC嗎？
理想和現實老是有必定的差距：雖然通過多年的推廣的應用，但QUIC協議目前仍未達到大量普及的階段，在 IETF上的QUIC 依然仍是草稿，而且還存在Google QUIC與IETF QUIC兩類不穩定的協定。
並且，QUIC還面臨如下挑戰：
1）小地方，路由封殺UDP 443端口（ 這正是QUIC 部署的端口）；
2）UDP包過多，因爲QS限定，會被服務商誤認爲是攻擊，UDP包被丟棄；
3）不管是路由器仍是防火牆目前對QUIC都尚未作好準備。
五、QUIC協議實踐
Chrome 瀏覽器從 2014 年開始已經實驗性的支持了 QUIC 協議。能夠經過在 Chrome 瀏覽器中輸入 chrome://net-internals/#quic 查看是否已經支持 QUIC 協議。若是還未支持，能夠在 chrome://flags/#enable-quic 中進行開啓。
開始 Chrome 瀏覽器對 QUIC 協議的支持以後，能夠在 chrome://net-internals/#quic 中查看到當前瀏覽器的 QUIC 一些鏈接。固然目前只有 Google 服務才支持 QUIC 協議（如 YouTube、 Google.com）。
Google 在 2015 年的一篇博文中分享了一些關於 QUIC 協議實現的結果，這些優點在諸如 YouTube 的視頻服務上更爲突出：用戶報告經過 QUIC 協議在觀看視頻的時候能夠減小 30% 的從新緩衝時間。
六、我想試試QUIC協議，能夠怎麼作？
目前支持 QUIC 協議的 web 服務只有 0.9 版本之後的 Caddy 。其餘經常使用 web 服務如 nginx、apache 等都未開始支持。
整個 QUIC 協議比較複雜，想本身徹底實現一套對筆者來講還比較困難。
因此先看看開源實現有哪些。
1）Chromium：
這個是官方支持的。優勢天然不少，Google 官方維護基本沒有坑，隨時能夠跟隨 chrome 更新到最新版本。不過編譯 Chromium 比較麻煩，它有單獨的一套編譯工具。暫時不建議考慮這個方案。
2）proto-quic：
從 chromium 剝離的一個 QUIC 協議部分，可是其 github 主頁已宣佈再也不支持，僅做實驗使用。不建議考慮這個方案。
3）goquic：
goquic 封裝了 libquic 的 go 語言封裝，而 libquic 也是從 chromium 剝離的，好幾年不維護了，僅支持到 quic-36， goquic 提供一個反向代理，測試發現因爲 QUIC 版本過低，最新 chrome 瀏覽器已沒法支持。不建議考慮這個方案。
4）quic-go：
quic-go 是徹底用 go 寫的 QUIC 協議棧，開發很活躍，已在 Caddy 中使用，MIT 許可，目前看是比較好的方案。
那麼，對於中小團隊或我的開發者來講，比較推薦的方案是最後一個，即採用 caddy 來部署實現 QUIC。caddy 這個項目本意並非專門用來實現 QUIC 的，它是用來實現一個免籤的 HTTPS web 服務器的（caddy 會自動續簽證書）。而QUIC 只是它的一個附屬功能（不過現實是——好像用它來實現 QUIC 的人更多）。
從Github的技術趨勢來講，有關QUIC的開源資源愈來愈多，有興趣能夠自已逐一研究研究：https://github.com/search?q=quic
七、本文小結
QUIC 協議開創性的使用了 UDP 協議做爲底層傳輸協議，經過各類方式減小了網絡延遲。
雖然目前 QUIC 協議已經運行在一些較大的網站上，但離大範圍普及還有較長的一段距離，期待 QUIC 協議規範可以成爲終稿，並在除了谷歌瀏覽器以外的其餘瀏覽器和應用服務器中也可以實現。
八、參考資料
Google的「 Next generation multiplexed transport over UDP」文檔：
Next generation multiplexed transport over UDP.pdf (563.01 KB ）
九、系列文章
本文是系列文章中的第10篇，本系列文章的大綱以下：
《網絡編程懶人入門(五)：快速理解爲何說UDP有時比TCP更有優點》
《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網絡編程懶人入門(八)：手把手教你寫基於TCP的Socket長鏈接》
附錄：更多網絡編程相關資料推薦
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》
《通俗易懂-深刻理解TCP協議（下）：RTT、滑動窗口、擁塞處理》
《理論聯繫實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解》
《高性能網絡編程(一)：單臺服務器併發TCP鏈接數到底能夠有多少》
《高性能網絡編程(二)：上一個10年，著名的C10K併發鏈接問題》
《高性能網絡編程(三)：下一個10年，是時候考慮C10M併發問題了》
《高性能網絡編程(四)：從C10K到C10M高性能網絡應用的理論探索》
《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》
《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》
《鮮爲人知的網絡編程(一)：淺析TCP協議中的疑難雜症(上篇)》
《鮮爲人知的網絡編程(二)：淺析TCP協議中的疑難雜症(下篇)》
《鮮爲人知的網絡編程(三)：關閉TCP鏈接時爲何會TIME_WAIT、CLOSE_WAIT》
《鮮爲人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》
《鮮爲人知的網絡編程(九)：理論聯繫實際，全方位深刻理解DNS》
《技術掃盲：新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解》
《現代移動端網絡短鏈接的優化手段總結：請求速度、弱網適應、安全保障》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的「弱」和「慢」》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《腦殘式網絡編程入門(一)：跟着動畫來學TCP三次握手和四次揮手》
《腦殘式網絡編程入門(二)：咱們在讀寫Socket時，究竟在讀寫什麼？》
《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》
《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《腦殘式網絡編程入門(五)：天天都在用的Ping命令，它究竟是什麼？》
《腦殘式網絡編程入門(六)：什麼是公網IP和內網IP？NAT轉換又是什麼鬼？》
《以網遊服務端的網絡接入層設計爲例，理解實時通訊的技術挑戰》
《全面瞭解移動端DNS域名劫持等雜症：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減少近半》
《Android程序員必知必會的網絡通訊傳輸層協議——UDP和TCP》
《IM開發者的零基礎通訊技術入門(一)：通訊交換技術的百年發展史(上)》
《IM開發者的零基礎通訊技術入門(二)：通訊交換技術的百年發展史(下)》
《IM開發者的零基礎通訊技術入門(三)：國人通訊方式的百年變遷》
《IM開發者的零基礎通訊技術入門(四)：手機的演進，史上最全移動終端發展史》
《IM開發者的零基礎通訊技術入門(五)：1G到5G，30年移動通訊技術演進史》
《IM開發者的零基礎通訊技術入門(六)：移動終端的接頭人——「基站」技術》
《IM開發者的零基礎通訊技術入門(七)：移動終端的千里馬——「電磁波」》
《IM開發者的零基礎通訊技術入門(八)：零基礎，史上最強「天線」原理掃盲》
《IM開發者的零基礎通訊技術入門(九)：無線通訊網絡的中樞——「核心網」》
《IM開發者的零基礎通訊技術入門(十)：零基礎，史上最強5G技術掃盲》
《IM開發者的零基礎通訊技術入門(十一)：爲何WiFi信號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通訊技術入門(十三)：爲何手機信號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
《IM開發者的零基礎通訊技術入門(十五)：理解定位技術，一篇就夠》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》
《百度APP移動端網絡深度優化實踐分享(二)：網絡鏈接優化篇》
《百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇》
《可能會搞砸你的面試：你知道一個TCP鏈接上能發起多少個HTTP請求嗎？》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-2816-1-1.html）
原文出處：https://www.cnblogs.com/imteck4713/p/11777310.html
- 1. QUIC，快速UDP網絡連接協議
- 2. 快速讀懂 HTTP/3 協議
- 3. QUIC 協議
- 4. 一文讀懂MQTT協議
- 5. 可靠的UDP協議--QUIC協議
- 6. HTTP與QUIC協議
- 7. QUIC協議簡史
- 8. QUIC協議初探
- 9. QUIC協議介紹
- 10. Web服務器快速啓用QUIC協議
- 更多相關文章...
- • SQL 快速參考 - SQL 教程
- • Eclipse 快速修復 - Eclipse 教程
- • 適用於PHP初學者的學習線路和建議
- • JDK13 GA發佈：5大特性解讀
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. QUIC，快速UDP網絡連接協議
- 2. 快速讀懂 HTTP/3 協議
- 3. QUIC 協議
- 4. 一文讀懂MQTT協議
- 5. 可靠的UDP協議--QUIC協議
- 6. HTTP與QUIC協議
- 7. QUIC協議簡史
- 8. QUIC協議初探
- 9. QUIC協議介紹
- 10. Web服務器快速啓用QUIC協議