天天看點

網絡程式設計懶人入門(十):一泡尿的時間,快速讀懂QUIC協定1、TCP協定到底怎麼了?2、QUIC協定登場3、QUIC協定的目标4、QUIC協定這麼好,可以大規模切換為QUIC嗎?5、QUIC協定實踐6、我想試試QUIC協定,可以怎麼做?7、本文小結8、參考資料9、系列文章附錄:更多網絡程式設計相關資料推薦

1、TCP協定到底怎麼了?

現時的網際網路應用中,Web平台(準确地說是基于HTTP及其延伸協定的用戶端/伺服器應用)的資料傳輸都基于 TCP 協定。

但TCP 協定在建立連接配接之前需要進行三次握手(如下圖 1,更詳細原理請見《理論經典:TCP協定的3次握手與4次揮手過程詳解》),如果需要提高資料互動的安全性,既增加傳輸層安全協定(TLS),還會增加更多的更多握手次數(如下圖 2)。

網絡程式設計懶人入門(十):一泡尿的時間,快速讀懂QUIC協定1、TCP協定到底怎麼了?2、QUIC協定登場3、QUIC協定的目标4、QUIC協定這麼好,可以大規模切換為QUIC嗎?5、QUIC協定實踐6、我想試試QUIC協定,可以怎麼做?7、本文小結8、參考資料9、系列文章附錄:更多網絡程式設計相關資料推薦

▲ 圖 1 - TCP的三次握手原理圖

網絡程式設計懶人入門(十):一泡尿的時間,快速讀懂QUIC協定1、TCP協定到底怎麼了?2、QUIC協定登場3、QUIC協定的目标4、QUIC協定這麼好,可以大規模切換為QUIC嗎?5、QUIC協定實踐6、我想試試QUIC協定,可以怎麼做?7、本文小結8、參考資料9、系列文章附錄:更多網絡程式設計相關資料推薦

▲ 圖 2  - TLS的初始化握手原理圖

正如上面兩張圖裡示範的原理,TCP 協定連接配接建立的成本相對較高。

是以,一般的穩定網絡傳輸都是通過TCP,但是在網絡基建本身就已經越來越完善的情況下,TCP設計本身的問題便暴露了出來,特别是在弱網環境下,讓我們不得不考慮一些新的可能性。

(本文同步釋出于:http://www.52im.net/thread-2816-1-1.html)

2、QUIC協定登場

和 TCP 相反,UDP 協定是無連接配接協定。用戶端發出 UDP 資料包後,隻能“假設”這個資料包已經被服務端接收。這樣的好處是在網絡傳輸層無需對資料包進行确認,但存在的問題就是為了確定資料傳輸的可靠性,應用層協定需要自己完成包傳輸情況的确認。

此時,QUIC 協定就登場了。

QUIC 是 Quick UDP Internet Connections 的縮寫,谷歌發明的新傳輸協定。

與 TCP 相比,QUIC 可以減少延遲。

QUIC 協定可以在 1 到 2 個資料包(取決于連接配接的伺服器是新的還是已知的)内,完成連接配接的建立(包括 TLS)(如下圖3所示)。

網絡程式設計懶人入門(十):一泡尿的時間,快速讀懂QUIC協定1、TCP協定到底怎麼了?2、QUIC協定登場3、QUIC協定的目标4、QUIC協定這麼好,可以大規模切換為QUIC嗎?5、QUIC協定實踐6、我想試試QUIC協定,可以怎麼做?7、本文小結8、參考資料9、系列文章附錄:更多網絡程式設計相關資料推薦

▲ 圖 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協定1、TCP協定到底怎麼了?2、QUIC協定登場3、QUIC協定的目标4、QUIC協定這麼好,可以大規模切換為QUIC嗎?5、QUIC協定實踐6、我想試試QUIC協定,可以怎麼做?7、本文小結8、參考資料9、系列文章附錄:更多網絡程式設計相關資料推薦

從圖上可以看出,QUIC 底層通過 UDP 協定替代了 TCP,上層隻需要一層用于和遠端伺服器互動的 HTTP/2 API。這是因為 QUIC 協定已經包含了多路複用和連接配接管理,HTTP API 隻需要完成 HTTP 協定的解析即可。

有關QUIC的詳解請見:《技術掃盲:新一代基于UDP的低延時網絡傳輸層協定——QUIC詳解》。

3、QUIC協定的目标

QUIC 協定的主要目的,是為了整合 TCP 協定的可靠性和 UDP 協定的速度和效率。

一張圖看懂QUIC協定的優勢:

網絡程式設計懶人入門(十):一泡尿的時間,快速讀懂QUIC協定1、TCP協定到底怎麼了?2、QUIC協定登場3、QUIC協定的目标4、QUIC協定這麼好,可以大規模切換為QUIC嗎?5、QUIC協定實踐6、我想試試QUIC協定,可以怎麼做?7、本文小結8、參考資料9、系列文章附錄:更多網絡程式設計相關資料推薦

對于 Google 來說優化 TCP 協定是一個長期目标,QUIC 旨在建立幾乎等同于 TCP 的獨立連接配接,但有着低延遲,并對類似 SPDY 的多路複用流協定有更好的支援。 如果 QUIC 協定的特性被證明是有效的,這些特性以後可能會被遷移入後續版本的 TCP 和 TLS 協定(它們都有很長的開發周期)。

值得注意的是,雖然理論上來說,如果 QUIC 的特性被證明是有效的,這些特性以後可能會被遷移到後續版本的 TCP 協定中,但鑒于TCP協定長達幾十年在網際網路通信裡的壟斷地位,以及這麼多年積累下來的沉重曆史報複,想要根本性地優化或改進TCP協定,難度相當大(或許,有些事情,隻能是想想而已,IPV6還喊了這麼多年呢,不是一樣沒普及。。。)。

4、QUIC協定這麼好,可以大規模切換為QUIC嗎?

理想和現實總是有一定的差距:雖然經過多年的推廣的應用,但QUIC協定目前仍未達到大量普及的階段,在 IETF上的QUIC 依然還是草稿,并且還存在Google QUIC與IETF QUIC兩類不穩定的協定。

而且,QUIC還面臨以下挑戰:

1)小地方,路由封殺UDP 443端口( 這正是QUIC 部署的端口);

2)UDP包過多,由于QS限定,會被服務商誤認為是攻擊,UDP包被丢棄;

3)無論是路由器還是防火牆目前對QUIC都還沒有做好準備。

5、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)。

網絡程式設計懶人入門(十):一泡尿的時間,快速讀懂QUIC協定1、TCP協定到底怎麼了?2、QUIC協定登場3、QUIC協定的目标4、QUIC協定這麼好,可以大規模切換為QUIC嗎?5、QUIC協定實踐6、我想試試QUIC協定,可以怎麼做?7、本文小結8、參考資料9、系列文章附錄:更多網絡程式設計相關資料推薦

Google 在 2015 年的一篇博文中分享了一些關于 QUIC 協定實作的結果,這些優勢在諸如 YouTube 的視訊服務上更為突出:使用者報告通過 QUIC 協定在觀看視訊的時候可以減少 30% 的重新緩沖時間。

6、我想試試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

7、本文小結

QUIC 協定開創性的使用了 UDP 協定作為底層傳輸協定,通過各種方式減少了網絡延遲。

雖然目前 QUIC 協定已經運作在一些較大的網站上,但離大範圍普及還有較長的一段距離,期待 QUIC 協定規範能夠成為終稿,并在除了谷歌浏覽器之外的其他浏覽器和應用伺服器中也能夠實作。

8、參考資料

《技術掃盲:新一代基于UDP的低延時網絡傳輸層協定——QUIC詳解》

《讓網際網路更快:新一代QUIC協定在騰訊的技術實踐分享》

《七牛雲技術分享:使用QUIC協定實作實時視訊直播0卡頓!》

Google的“ Next generation multiplexed transport over UDP”文檔:

 Next generation multiplexed transport over UDP.pdf (563.01 KB ) 

9、系列文章

本文是系列文章中的第10篇,本系列文章的大綱如下:

《網絡程式設計懶人入門(一):快速了解網絡通信協定(上篇)》

《網絡程式設計懶人入門(二):快速了解網絡通信協定(下篇)》

《網絡程式設計懶人入門(三):快速了解TCP協定一篇就夠》

《網絡程式設計懶人入門(四):快速了解TCP和UDP的差異》

《網絡程式設計懶人入門(五):快速了解為什麼說UDP有時比TCP更有優勢》

《網絡程式設計懶人入門(六):史上最通俗的集線器、交換機、路由器功能原理入門》

《網絡程式設計懶人入門(七):深入淺出,全面了解HTTP協定》

《網絡程式設計懶人入門(八):手把手教你寫基于TCP的Socket長連接配接》

《網絡程式設計懶人入門(九):通俗講解,有了IP位址,為何還要用MAC位址?》

《網絡程式設計懶人入門(十):一泡尿的時間,快速讀懂QUIC協定》(本文)

附錄:更多網絡程式設計相關資料推薦

《TCP/IP詳解 - 第11章·UDP:使用者資料報協定》

《TCP/IP詳解 - 第17章·TCP:傳輸控制協定》

《TCP/IP詳解 - 第18章·TCP連接配接的建立與終止》

《TCP/IP詳解 - 第21章·TCP的逾時與重傳》

《技術往事:改變世界的TCP/IP協定(珍貴多圖、手機慎點)》

《通俗易懂-深入了解TCP協定(上):理論基礎》

《通俗易懂-深入了解TCP協定(下):RTT、滑動視窗、擁塞處理》

《理論經典:TCP協定的3次握手與4次揮手過程詳解》

《理論聯系實際:Wireshark抓包分析TCP 3次握手、4次揮手過程》

《計算機網絡通訊協定關系圖(中文珍藏版)》

《UDP中一個包的大小最大能多大?》

《P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介》

《P2P技術詳解(二):P2P中的NAT穿越(打洞)方案詳解》

《P2P技術詳解(三):P2P技術之STUN、TURN、ICE詳解》

《通俗易懂:快速了解P2P技術中的NAT穿透原理》

《高性能網絡程式設計(一):單台伺服器并發TCP連接配接數到底可以有多少》

《高性能網絡程式設計(二):上一個10年,著名的C10K并發連接配接問題》

《高性能網絡程式設計(三):下一個10年,是時候考慮C10M并發問題了》

《高性能網絡程式設計(四):從C10K到C10M高性能網絡應用的理論探索》

《高性能網絡程式設計(五):一文讀懂高性能網絡程式設計中的I/O模型》

《高性能網絡程式設計(六):一文讀懂高性能網絡程式設計中的線程模型》

《不為人知的網絡程式設計(一):淺析TCP協定中的疑難雜症(上篇)》

《不為人知的網絡程式設計(二):淺析TCP協定中的疑難雜症(下篇)》

《不為人知的網絡程式設計(三):關閉TCP連接配接時為什麼會TIME_WAIT、CLOSE_WAIT》

《不為人知的網絡程式設計(四):深入研究分析TCP的異常關閉》

《不為人知的網絡程式設計(五):UDP的連接配接性和負載均衡》

《不為人知的網絡程式設計(六):深入地了解UDP協定并用好它》

《不為人知的網絡程式設計(七):如何讓不可靠的UDP變的可靠?》

《不為人知的網絡程式設計(八):從資料傳輸層深度解密HTTP》

《不為人知的網絡程式設計(九):理論聯系實際,全方位深入了解DNS》

《技術掃盲:新一代基于UDP的低延時網絡傳輸層協定——QUIC詳解》

《讓網際網路更快:新一代QUIC協定在騰訊的技術實踐分享》

《現代移動端網絡短連接配接的優化手段總結:請求速度、弱網适應、安全保障》

《聊聊iOS中網絡程式設計長連接配接的那些事》

《移動端IM開發者必讀(一):通俗易懂,了解移動網絡的“弱”和“慢”》

《移動端IM開發者必讀(二):史上最全移動弱網絡優化方法總結》

《IPv6技術詳解:基本概念、應用現狀、技術實踐(上篇)》

《IPv6技術詳解:基本概念、應用現狀、技術實踐(下篇)》

《從HTTP/0.9到HTTP/2:一文讀懂HTTP協定的曆史演變和設計思路》

《腦殘式網絡程式設計入門(一):跟着動畫來學TCP三向交握和四次揮手》

《腦殘式網絡程式設計入門(二):我們在讀寫Socket時,究竟在讀寫什麼?》

《腦殘式網絡程式設計入門(三):HTTP協定必知必會的一些知識》

《腦殘式網絡程式設計入門(四):快速了解HTTP/2的伺服器推送(Server Push)》

《腦殘式網絡程式設計入門(五):每天都在用的Ping指令,它到底是什麼?》

《腦殘式網絡程式設計入門(六):什麼是公網IP和内網IP?NAT轉換又是什麼鬼?》

《以網遊服務端的網絡接入層設計為例,了解實時通信的技術挑戰》

《邁向高階:優秀Android程式員必知必會的網絡基礎》

《全面了解移動端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)