默認
打賞 發表評論 5
想開發IM:買成品怕坑?租第3方怕貴?找開源自已擼?盡量別走彎路了... 找站長給點建議
網絡編程懶人入門(十):一泡尿的時間,快速讀懂QUIC協議
閱讀(3842) | 評論(5 收藏3 淘帖1 2

1、TCP協議到底怎么了?


現時的互聯網應用中,Web平臺(準確地說是基于HTTP及其延伸協議的客戶端/服務器應用)的數據傳輸都基于 TCP 協議。

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

網絡編程懶人入門(十):一泡尿的時間,快速讀懂QUIC協議_11111.png        網絡編程懶人入門(十):一泡尿的時間,快速讀懂QUIC協議_2.png
▲ 圖 1 - TCP的三次握手原理圖                                           ▲ 圖 2  - TLS的初始化握手原理圖

正如上面兩張圖里演示的原理,TCP 協議連接建立的成本相對較高。

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

2、QUIC協議登場


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

此時,QUIC 協議就登場了。

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

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

QUIC 協議可以在 1 到 2 個數據包(取決于連接的服務器是新的還是已知的)內,完成連接的創建(包括 TLS)(如下圖3所示)。

網絡編程懶人入門(十):一泡尿的時間,快速讀懂QUIC協議_3-0.png
▲ 圖 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協議_3-2.png

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

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

3、QUIC協議的目標


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

一張圖看懂QUIC協議的優勢:
網絡編程懶人入門(十):一泡尿的時間,快速讀懂QUIC協議_4.png

對于 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協議_666.png

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、參考資料



Google的“ Next generation multiplexed transport over UDP”文檔:
Next generation multiplexed transport over UDP.pdf (563.01 KB , 下載次數: 0 , 售價: 1 金幣)

9、系列文章


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


附錄:更多網絡編程相關資料推薦


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請求嗎?
知乎技術分享:知乎千萬級并發的高性能長連接網關技術實踐
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:不為人知的網絡編程(九):理論聯系實際,全方位深入理解DNS下一篇:求教,對于有關TCP協議文章的圖片的內容有疑問

本帖已收錄至以下技術專輯

推薦方案
評論 5
群主,我一泡屎都拉完了,還沒看懂,腫么辦!
簽名: 秋天到了,終于涼快了
引用:clark.li 發表于 2019-11-01 15:44
群主,我一泡屎都拉完了,還沒看懂,腫么辦!

你這是拉稀了吧,拉個shi能比拉尿還快...
簽名: 《主流移動端賬號登錄方式的原理及設計思路》http://www.uktmgv.tw/thread-2863-1-1.html
群主這篇我看了個把小時,你這泡尿是怎么肥事
引用:李瑞啊 發表于 2019-11-06 15:25
群主這篇我看了個把小時,你這泡尿是怎么肥事

下次不能叫這標題,矛盾很大。。。
簽名: 《主流移動端賬號登錄方式的原理及設計思路》http://www.uktmgv.tw/thread-2863-1-1.html
引用:JackJiang 發表于 2019-11-06 15:33
下次不能叫這標題,矛盾很大。。。

把尿改成shi就沒問題  就是有點惡心
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
曾氏料二肖中特