當通過網(wǎng)絡(luò)傳輸數(shù)據(jù)時,一種新的協(xié)議QUIC(Quick UDP Internet Connection,快速UDP互聯(lián)網(wǎng)連接)正在成為FAANG的默認選擇。本篇文章描述了QUIC協(xié)議是如何克服其他版本HTTP的限制脫穎而出的。
FAANG是美國市場上五大最受歡迎和表現(xiàn)最佳的科技股的首字母縮寫,即Facebook、Apple、Amazon、Netflix和Google。
HTTP的演進
HTTP屬于應(yīng)用層傳輸協(xié)議,運行于TCP/IP之上。現(xiàn)在它已成為萬維網(wǎng)中數(shù)據(jù)交換的基礎(chǔ)。HTTP包括4個穩(wěn)定版本:HTTP/0.9、HTTP/1.0、HTTP/1.1 和HTTP/2。HTTP/3于2018年首次提出,目前已獲得全球2/3 web瀏覽器的支持。
HTTP/0.9(1991)
HTTP/0.9是HTTP的第一個版本,用作W3C的底層通信協(xié)議。它是一個非常簡單的客戶端-服務(wù)器、請求-響應(yīng)、使用Telnet的協(xié)議,只支持GET命令(作為請求方法)和超文本協(xié)議(作為響應(yīng)類型)。該協(xié)議不包含HTTP消息頭,且發(fā)送響應(yīng)后,連接會立即斷開。
HTTP/1.0(1996)
HTTP/0.9極其簡單,且使用非常受限。新的HTTP版本HTTP/1.0引入了很多新特性,使它更加通用。這些新的特性包括:
每次HTTP 請求/響應(yīng)都會重新建立TCP連接
添加了對 POST 和 HEAD 方法的支持
協(xié)議頭帶有版本號、協(xié)議類型、狀態(tài)碼字段
響應(yīng)類型:超文本、腳本、媒體、樣式表
支持keep-alive連接,但默認情況下它是“關(guān)閉”的
HTTP/1.1(1997)
HTTP/1.0的主要缺陷是:它在每次請求響應(yīng)時都要建立新的TCP連接。這種做法非常耗時,且影響客戶端和服務(wù)器的性能。HTTP/1.1的出現(xiàn)解決了這一問題:
單個TCP連接上可以傳送多個HTTP請求和響應(yīng)
添加了對 PUT、DELETE、TRACE、OPTIONS 方法的支持
默認持久連接
HTTP/2(2015)
隨著流媒體內(nèi)容的增加,網(wǎng)站也開始變得越來越復(fù)雜。為了滿足這種需求,HTTP/1.1的功能不斷擴展:首次支持多個TCP連接,并試驗性地引入了管道機制(pipelining),即在同一個TCP連接里面,客戶端可以同時發(fā)送多個請求。但擴展不可能無止境,最終需要采用一個新的協(xié)議,于是HTTP/2出現(xiàn)了,該協(xié)議包括如下重大改進:
多路復(fù)用:這是HTTP/2的一個特性,允許同時通過單個TCP連接發(fā)起多重請求-響應(yīng)消息。每次HTTP請求-響應(yīng)都被分割成二進制幀,客戶端和服務(wù)器都以二進制幀為基本單位發(fā)送消息(請求和響應(yīng))。通過多路復(fù)用,客戶端無需再等待上一個請求完成就可以發(fā)送多重請求。這樣,HTTP/2便解決了HTTP隊頭阻塞(HoL)的問題。如圖所示:
頭部壓縮:使用 HPACK 壓縮消息頭
非阻塞下載
支持服務(wù)器推送
采用二進制分幀,不再是純文本
解決了隊頭阻塞問題
HTTP/3(2018)
通過多路復(fù)用,HTTP/2解決了隊頭阻塞問題。但如果TCP流中出現(xiàn)了丟包,根據(jù)TCP的擁塞控制機制,其他數(shù)據(jù)流就只能等待丟包被重新發(fā)送和接收。所以,TCP的隊頭阻塞問題在HTTP/2中依然存在。
HTTP/3通過使用基于UDP的傳輸協(xié)議QUIC解決了這一問題。
HTTP/3是自HTTP/2之后最新且最主要的HTTP版本。因為HTTP/3本身就是為QUIC協(xié)議設(shè)計的,所以也被描述為基于QUIC的HTTP/2。HTTP/3的目標是通過使用谷歌的QUIC協(xié)議提供快速、可靠安全的網(wǎng)絡(luò)連接。HTTP/3包括以下特性:
使用基于UDP的QUIC作為傳輸協(xié)議
解決了TCP隊頭阻塞問題
使用QPACK頭部壓縮機制
提供更快頁面加載時間
HTTP/2 VS HTTP/3
相同點:
HTTP/2 和 HTTP/3 使用相同的語法和語義結(jié)構(gòu),并且適用于同一請求/響應(yīng)方法、狀態(tài)碼和協(xié)議字段。此外,兩者都使用設(shè)計相似的頭部壓縮算法(HPACK 和 QPACK)。
不同點:
特性 | HTTP/2 | HTTP/3 |
傳輸層協(xié)議 | TCP | 基于UDP的QUIC |
頭部壓縮算法 | HPACK | QPACK |
隊頭阻塞問題 | 解決HTTP隊頭阻塞 | 同時解決HTTP和TCP 隊頭阻塞 |
握手協(xié)議 | TCP + TLS | QUIC |
加密協(xié)商 | 可通過TLS(默認版本為1.2,后續(xù)版本可選)與ALPN協(xié)議擴展進行協(xié)商 | 使用用于QUIC協(xié)議的Alt-Svc(以 TLS 1.3 作為 TLS 的最低版本) |
握手時間 | 因為需要TCP和TLS 握手,所以更慢 | QUIC協(xié)議直接處理數(shù)據(jù)流,所以更快 |
QUIC是一種新的多路傳輸層網(wǎng)絡(luò)協(xié)議標準,建立在 UDP 之上。QUIC的主要目標是通過減少頁面加載時間提升用戶體驗,并提高HTTPS的傳輸性能。它在本質(zhì)上是TCP+TLS+HTTP/2。
設(shè)計HTTP/3的目的就是要充分利用 QUIC 的優(yōu)勢。QUIC 協(xié)議本身可以處理數(shù)據(jù)流,所以排除了 TCP 隊頭阻塞問題。
QUIC 的一些關(guān)鍵特性包括:
基于UDP
使用沒有隊頭阻塞的連接復(fù)用
重構(gòu)TCP的關(guān)鍵機制(連接復(fù)用、連接建立、擁塞控制、可靠性),并成為可靠的傳輸協(xié)議
交換數(shù)據(jù)包
對于典型的QUIC協(xié)議,客戶端和服務(wù)器之間交換了三種類型的數(shù)據(jù)包,如下圖所示:
1. 安全的首包
首先,客戶端在一個CRYPTO幀中傳輸包含TLS 1.3 Client Hello的首包。Client Hello包含不同類型的的擴展項,如目標服務(wù)器的SNI(Server Name Indication,服務(wù)器名稱指示 )、QUIC 傳輸參數(shù)、壓縮證書等,以及客戶端支持的壓縮方法和不同的加密套件。
如果服務(wù)器接受QUIC和TLS 1.3參數(shù),它也會在CRYPTO幀中發(fā)送包含對客戶端首包確認信息和TLS 1.3 Server Hello的首包信息。Server Hello中包含被服務(wù)器接收的加密套件和不同的擴展(如密鑰共享、支持的版本等)。在客戶端接收到 Server Hello后,會向服務(wù)器發(fā)送一個ACK確認包。
這三個首包都可能包含一個填充幀,以根據(jù)需要增加數(shù)據(jù)包的大小。
2. 握手包
客戶端和服務(wù)器之間的首包被交換以后,服務(wù)器會發(fā)送一個握手數(shù)據(jù)包,其中包含余下的服務(wù)器端消息,如證書、與服務(wù)器身份驗證相關(guān)的加密擴展??蛻舳藭炞C這些證書,然后QUIC 握手以客戶端發(fā)送的握手消息結(jié)束。
3. 安全的凈荷包
一旦安全的QUIC連接建立,客戶端與服務(wù)器之間的信息便可以安全傳輸。
QUIC 0-RTT
為了縮短建立新連接的時間,QUIC采用0-RTT。在這里,如果客戶端之前使用1-RTT連接到服務(wù)器,則服務(wù)器必須存儲與流量控制相關(guān)的傳輸參數(shù)的副本,如 initial_max_data、initial_max_stream_data_bidi_local 等。
下一次,在QUIC 0-RTT模式中,客戶端立即開始與服務(wù)器的數(shù)據(jù)傳輸,不需要等待握手完成。
然而,0-RTT也有設(shè)計上的缺陷:允許重放攻擊。
我們?yōu)槭裁匆肣UIC?
傳統(tǒng)的TCP協(xié)議是建立在操作系統(tǒng)層和中間路由模塊之上實現(xiàn)的,它的握手階段信息很容易被這些中間模塊篡改而變得不安全。
但QUIC協(xié)議是在UDP之上的用戶級(如瀏覽器)中實現(xiàn)的,因此它更加靈活、對用戶更友好,并且能夠在短時間內(nèi)支持更多設(shè)備。
在 QUIC 中,傳輸相關(guān)的信息被不同的保護層加密,握手包在傳輸鏈路上不容易被識別和修改。因此它提供了更安全的網(wǎng)絡(luò)數(shù)據(jù)傳輸。
翻譯/ Alex 技術(shù)Review / 袁榮喜 原文鏈接: https://blogs.keysight.com/blogs/tech/nwvs.entry.html/2021/07/16/road_to_quic-DGa5.html 特別說明:原作者Anubhab Sahu已授權(quán)本文的翻譯與發(fā)布,特此感謝。
編輯:jq
-
服務(wù)器
+關(guān)注
關(guān)注
12文章
8843瀏覽量
84946 -
TCP
+關(guān)注
關(guān)注
8文章
1335瀏覽量
78862 -
UDP
+關(guān)注
關(guān)注
0文章
318瀏覽量
33831 -
Quic
+關(guān)注
關(guān)注
0文章
25瀏覽量
7271
原文標題:QUIC協(xié)議的演進之路
文章出處:【微信號:xunwei201508,微信公眾號:訊維官方公眾號】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論