QUIC協(xié)議研究

陳振波（武漢郵電科學(xué)研究院，湖北武漢,430074）

QUIC協(xié)議研究

陳振波
（武漢郵電科學(xué)研究院，湖北武漢,430074）

為了解決當(dāng)前TCP傳輸存在的兩個(gè)主要問題：（1）建立連接、斷開連接的耗時(shí)傳輸機(jī)制；（2）前序包阻塞（Head-of-line blocking, HOL）問題，本文介紹一種基于UDP作為底層傳輸?shù)娜聟f(xié)議(Quick UDP Internet Connections，QUIC)，通過采用UDP為傳輸層協(xié)議，避免建立連接、斷開連接的耗時(shí)問題和前序包阻塞問題，并且通過一種巧妙的機(jī)制保證可靠性傳輸，克服UDP傳輸存在的問題。

TCP；前序包阻塞；UDP；QUIC

0 引言

建立在TCP基礎(chǔ)之上的HTTP是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，誕生之初，主要就是為了將超文本標(biāo)記語言(HTML)文檔從Web服務(wù)器傳送到客戶端的瀏覽器。但是到了Web 2.0時(shí)代，HTML頁面變得越來越復(fù)雜，不僅僅單純的是一些簡單的文字和圖片，同時(shí)有了層疊樣式表（Cascading Style Sheets，CSS），JavaScript（一種直譯式腳本語言）來豐富頁面展示，隨著Ajax（一種創(chuàng)建交互式網(wǎng)頁應(yīng)用的網(wǎng)頁開發(fā)技術(shù)，英文全稱：Asynchronous JavaScript And XML）的出現(xiàn)，客戶端又多了一種向服務(wù)器端獲取數(shù)據(jù)的方法，這些其實(shí)都是基于HTTP協(xié)議的。同樣到了移動(dòng)互聯(lián)網(wǎng)時(shí)代，頁面可以在手機(jī)端瀏覽器里顯示，但是和電腦端相比，手機(jī)端的網(wǎng)絡(luò)情況更加復(fù)雜，經(jīng)常涉及到蜂窩網(wǎng)絡(luò)與無線局域網(wǎng)之間的切換，因此需要對(duì)HTTP進(jìn)行深入理解并不斷優(yōu)化。SPDY（發(fā)音如英語：speedy）及QUIC就是在這樣的背景下相繼出現(xiàn)，接下來先分別介紹HTTP及SPDY的發(fā)展、QUIC的特點(diǎn)，然后進(jìn)行對(duì)比分析。

1 HTTP及SPDY

1.1 HTTP 1.X

HTTP/0.9是一個(gè)過時(shí)的協(xié)議，它只接受GET一種請(qǐng)求方法，沒有在網(wǎng)絡(luò)傳輸中指定版本號(hào)，且不支持請(qǐng)求頭。由于該版本不支持POST方法，因此客戶端無法向服務(wù)器傳遞太多信息。

隨后提出的HTTP/1.0是第一個(gè)指定版本號(hào)的HTTP協(xié)議版本，早期只是使用在一些較為簡單的網(wǎng)頁和網(wǎng)絡(luò)請(qǐng)求上，而今主要是在代理服務(wù)器中使用。

HTTP/1.1在1999年開始廣泛應(yīng)用于現(xiàn)在的各大瀏覽器網(wǎng)絡(luò)請(qǐng)求中，同時(shí)也是當(dāng)前使用最為廣泛的HTTP協(xié)議。HTTP/1.1與HTTP/1.0的主要區(qū)別為：

（1）緩存處理。在HTTP/1.0中主要使用header里的If-Modified-Since, Expires作為緩存判斷的標(biāo)準(zhǔn)，HTTP/1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。

（2）帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用。HTTP/1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶端只是需要某個(gè)對(duì)象的一部分，而服務(wù)器卻將整個(gè)對(duì)象傳過來了，并且不支持?jǐn)帱c(diǎn)續(xù)傳功能，HTTP/1.1則在請(qǐng)求頭引入了range頭域，它允許只請(qǐng)求資源的某個(gè)部分，即返回碼是206（Partial Content），這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接。

（3）錯(cuò)誤通知的管理。在HTTP/1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如409（Conflict）表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除。

（4）Host頭處理。在HTTP/1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址，因此請(qǐng)求消息中的URL并沒有傳遞主機(jī)名（hostname）。但隨著虛擬主機(jī)技術(shù)的發(fā)展，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)（Multi-homed Web Servers），并且它們共享一個(gè)IP地址。HTTP/1.1的請(qǐng)求消息和響應(yīng)消息都應(yīng)支持Host頭域，且請(qǐng)求消息中如果沒有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤（400 Bad Request）。

（5）長連接。HTTP/1.1支持長連接（Persistent Connection）和請(qǐng)求的流水線（Pipelining）處理，在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲，在HTTP/1.1中默認(rèn)開啟Connection： keep-alive，一定程度上彌補(bǔ)了HTTP/1.0每次請(qǐng)求都要?jiǎng)?chuàng)建連接的缺點(diǎn)。

盡管HTTP/1.1相比于HTTP/1.0有了很大的優(yōu)化，但仍存在不少問題。

（1）需要很多TCP連接來實(shí)現(xiàn)并發(fā)請(qǐng)求與響應(yīng)，且在傳輸數(shù)據(jù)時(shí)每次都需要重新建立連接，這增加了大量的延遲時(shí)間并可能引起網(wǎng)絡(luò)擁塞和高數(shù)據(jù)包丟失，導(dǎo)致更差的網(wǎng)絡(luò)性能。

（2）在傳輸數(shù)據(jù)時(shí)，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無法驗(yàn)證對(duì)方的身份，這在一定程度上無法保證數(shù)據(jù)的安全性。

（3）頭部信息（header）里攜帶的內(nèi)容過大，在一定程度上增加了傳輸?shù)某杀荆⑶颐看握?qǐng)求header基本不怎么變化，尤其在移動(dòng)端環(huán)境下容易增加用戶流量。

（4）雖然HTTP/1.1支持了keep-alive，來彌補(bǔ)多次創(chuàng)建連接產(chǎn)生的延遲，但是keep-alive使用多了同樣會(huì)給服務(wù)端帶來大量的性能壓力。

（5）HTTP請(qǐng)求嚴(yán)格由客戶端發(fā)起，在網(wǎng)頁加載很多嵌入對(duì)象時(shí)會(huì)嚴(yán)重影響性能，因?yàn)榉?wù)器只能在客戶端發(fā)出請(qǐng)求后才能傳輸數(shù)據(jù)。

1.2 SPDY與HTTP/2

SPDY是一種基于TCP的開放網(wǎng)絡(luò)傳輸應(yīng)用層協(xié)議，由Google開發(fā)，用來發(fā)送網(wǎng)頁內(nèi)容。設(shè)計(jì)SPDY的目的在于降低網(wǎng)頁的加載時(shí)間，與HTTP/1.1相比，它在以下幾方面作了改進(jìn)。

（1）降低延遲。針對(duì)HTTP高延遲的問題，SPDY采取了多路復(fù)用（multiplexing）。多路復(fù)用通過多個(gè)請(qǐng)求流共享一個(gè)TCP連接的方式，同時(shí)服務(wù)端也可通過一個(gè)連接發(fā)出多個(gè)應(yīng)答流，提高了服務(wù)端性能。多路復(fù)用技術(shù)可以減少網(wǎng)絡(luò)擁塞、降低延遲，同時(shí)提高了帶寬的利用率。

（2）請(qǐng)求優(yōu)先級(jí)。多路復(fù)用帶來一個(gè)新的問題是，在連接共享的基礎(chǔ)之上有可能會(huì)導(dǎo)致關(guān)鍵請(qǐng)求被阻塞。SPDY允許給每個(gè)請(qǐng)求設(shè)置優(yōu)先級(jí)，這樣重要的請(qǐng)求就會(huì)優(yōu)先得到響應(yīng)。比如瀏覽器加載首頁，首頁的html內(nèi)容應(yīng)該優(yōu)先展示，之后才是各種靜態(tài)資源文件，腳本文件等加載，這樣可以保證用戶能第一時(shí)間看到網(wǎng)頁內(nèi)容。

（3）header壓縮。HTTP 1.x的header很多時(shí)候都是重復(fù)多余的。選擇合適的壓縮算法可以減小包的大小和數(shù)量，降低延遲。

（4）基于HTTPS的加密協(xié)議傳輸，大大提高了傳輸數(shù)據(jù)的可靠性。SPDY中廣泛應(yīng)用了安全傳輸層協(xié)議（Transport Layer Security，TLS）加密，傳輸內(nèi)容也均以gzip或DEFLATE格式壓縮。

（5）服務(wù)端推送。采用了SPDY的網(wǎng)頁，在客戶端發(fā)出一個(gè)資源請(qǐng)求時(shí)，服務(wù)端會(huì)把相關(guān)的資源主動(dòng)推送到客戶端而避免等待客戶端再發(fā)出請(qǐng)求后響應(yīng)。這可以減少頁面加載時(shí)間。

需要說明的是，SPDY并不用于替換HTTP，它只是修改了HTTP的請(qǐng)求與應(yīng)答在網(wǎng)絡(luò)上傳輸?shù)姆绞剑贿@意味著只需增加一個(gè)SPDY傳輸層，現(xiàn)有的所有服務(wù)端應(yīng)用均不用做任何修改。當(dāng)使用SPDY的方式傳輸時(shí)，HTTP請(qǐng)求會(huì)被處理、標(biāo)記簡化和壓縮。比如，每一個(gè)SPDY端點(diǎn)會(huì)持續(xù)跟蹤每一個(gè)在之前的請(qǐng)求中已經(jīng)發(fā)送的HTTP報(bào)文頭部，從而避免重復(fù)發(fā)送還未改變的頭部。而還未發(fā)送的報(bào)文的數(shù)據(jù)部分將在被壓縮后被發(fā)送。SPDY的構(gòu)成如圖1所示。

圖1 SPDY構(gòu)成圖

2015年推出的HTTP/2大部分基于SPDY實(shí)現(xiàn)，主要區(qū)別為：

（1）HTTP/2支持明文 HTTP 傳輸，而 SPDY 強(qiáng)制使用HTTPS。

（2）HTTP/2消息頭（header）的壓縮算法采用 HPACK，而非SPDY 采用的 DEFLATE。

由于HTTP/2推出時(shí)間不長，相較于HTTP/1.1應(yīng)用范圍還不廣，但是未來肯定會(huì)逐漸取代HTTP/1.1。

2 QUIC

2.1 HTTP/2的局限性

除了QUIC是基于UDP實(shí)現(xiàn)，前面幾種協(xié)議都是基于TCP。TCP因其面向連接、可靠傳輸?shù)忍攸c(diǎn)而被廣泛采用，但在如今帶寬越來越大的網(wǎng)絡(luò)環(huán)境下，TCP的局限性也制約了HTTP/2的性能，主要表現(xiàn)為以下兩點(diǎn)。

（1）數(shù)據(jù)傳輸前TCP先要進(jìn)行“三次握手”，建立連接后才開始傳輸應(yīng)用數(shù)據(jù)，這無疑增加了網(wǎng)絡(luò)延時(shí)；在采用TLS協(xié)議時(shí)需要交換密鑰，這又增加了一次往返時(shí)延（Round-Trip Time，RTT）。

（2）HOL(Head-of-line)blocking，前序包阻塞。TCP保證有序傳輸，所以當(dāng)一個(gè)數(shù)據(jù)包丟失時(shí)，其他所有的包都要等它重傳整理后才會(huì)交給應(yīng)用層，對(duì)于多路復(fù)用共享一個(gè)TCP連接的SPDY和HTTP/2來說，這無疑影響更大。

2.2 QUIC的特點(diǎn)

QUIC最主要的目標(biāo)是減小網(wǎng)絡(luò)傳輸延遲，所以選擇了UDP作為傳輸層協(xié)議，它的主要優(yōu)點(diǎn)有：

（1）QUIC協(xié)議在創(chuàng)建連接握手時(shí)，只需要1到2個(gè)數(shù)據(jù)包即可。參考TCP+TLS協(xié)議的傳輸方式，QUIC設(shè)計(jì)了類似DTLS（Datagram Transport Layer Security，數(shù)據(jù)報(bào)傳輸安全層）的傳輸模型。這個(gè)模型大大簡化了建立連接的過程，使得創(chuàng)建連接握手時(shí)只需1到2個(gè)數(shù)據(jù)包。對(duì)于無線網(wǎng)絡(luò)來說，客戶端和服務(wù)器之間的延時(shí)通常在100ms以上。傳統(tǒng)TCP+TLS協(xié)議的傳輸方式，在創(chuàng)建連接時(shí)的4個(gè)數(shù)據(jù)包和QUIC協(xié)議的1個(gè)數(shù)據(jù)包相比，連接創(chuàng)建上就會(huì)多耗時(shí)300ms以上。圖2、圖3分別為TCP+TLS、QUIC的握手示意圖。

（2）避免前序包阻塞。SPDY和HTTP/2支持將頁面的多個(gè)數(shù)據(jù)（如音頻、圖片等）通過一個(gè)TCP連接進(jìn)行傳輸。該特性能夠加快頁面組件的傳輸速度，但是對(duì)于TCP協(xié)議來說，這會(huì)遇到前序包阻塞的問題。因此，即使邏輯上一個(gè)TCP連接上并行的在進(jìn)行多路數(shù)據(jù)傳輸，其他毫無關(guān)聯(lián)的數(shù)據(jù)也會(huì)因此阻塞。由于UDP協(xié)議沒有嚴(yán)格的順序，當(dāng)一個(gè)數(shù)據(jù)包遇到問題需要重傳時(shí)，只會(huì)影響該數(shù)據(jù)包對(duì)應(yīng)的資源，其他獨(dú)立的資源（如其他CSS、JavaScript文件）不會(huì)受到影響。QUIC協(xié)議直接通過底層使用UDP協(xié)議天然的避免了該問題。

圖2 TCP+TLS握手示意圖

圖3 QUIC握手示意圖

(3)QUIC協(xié)議有一個(gè)非常獨(dú)特的特性，稱為向前糾錯(cuò)（Forward Error Correction，F(xiàn)EC），每個(gè)數(shù)據(jù)包除了它本身的內(nèi)容之外，還包括了部分其他數(shù)據(jù)包的數(shù)據(jù)，因此少量的丟包可以通過其他包的冗余數(shù)據(jù)直接組裝而無需重傳。向前糾錯(cuò)犧牲了每個(gè)數(shù)據(jù)包可以發(fā)送數(shù)據(jù)的上限，但是減少了因?yàn)閬G包導(dǎo)致的數(shù)據(jù)重傳，因?yàn)閿?shù)據(jù)重傳將會(huì)消耗更多的時(shí)間（包括確認(rèn)數(shù)據(jù)包丟失、請(qǐng)求重傳、等待新數(shù)據(jù)包等步驟的時(shí)間消耗）。

(4) 底層協(xié)議切換到UDP協(xié)議之后的另一大好處是，連接不再依賴于來源IP。對(duì)于TCP協(xié)議來說，標(biāo)識(shí)一個(gè)TCP連接需要4個(gè)參數(shù)，即來源IP、來源端口、目的IP和目的端口。其中的任一參數(shù)改變，TCP連接就需要重新創(chuàng)建。這對(duì)于傳統(tǒng)網(wǎng)絡(luò)來說影響不大，因?yàn)閬碓春湍康腎P相對(duì)固定。但是在無線網(wǎng)絡(luò)中，情況就大不相同了。設(shè)備在移動(dòng)過程中，可能會(huì)因?yàn)榫W(wǎng)絡(luò)切換（如從WIFI網(wǎng)絡(luò)切換到4G網(wǎng)絡(luò)環(huán)境），導(dǎo)致TCP連接需要重新創(chuàng)建。QUIC協(xié)議使用了UDP協(xié)議，不再需要這四組參數(shù)。同時(shí)QUIC協(xié)議實(shí)現(xiàn)了自己的會(huì)話標(biāo)記方式，稱為連接ID。當(dāng)設(shè)備網(wǎng)絡(luò)環(huán)境切換時(shí)，連接ID不會(huì)發(fā)生變化，因此無需重新進(jìn)行握手。該特性除了可以減少無謂的連接重連之外，還可以充分利用設(shè)備的不同網(wǎng)絡(luò)接口，進(jìn)行資源的并行下載。因?yàn)殡m然這些網(wǎng)絡(luò)接口有不同的IP，但只要他們能夠共享連接ID，就能夠并行的從服務(wù)器下載數(shù)據(jù)。

QUIC協(xié)議內(nèi)置了TLS棧，實(shí)現(xiàn)了自己的傳輸加密層，同時(shí)QUIC還包含了部分HTTP/2的實(shí)現(xiàn),底層通過UDP協(xié)議替代了TCP，上層只需要一層用于和遠(yuǎn)程服務(wù)器交互的HTTP/2 API。這是因?yàn)镼UIC協(xié)議已經(jīng)包含了多路復(fù)用和連接管理，HTTP API只需要完成HTTP協(xié)議的解析即可。圖4為協(xié)議層次對(duì)比圖。

圖4 協(xié)議層次對(duì)比圖

3 結(jié)束語

QUIC通過一次（通信雙方從未建立連接）甚至不需要往返握手就可建立連接，這大大降低了網(wǎng)絡(luò)傳輸延遲。同時(shí)采用UDP底層協(xié)議避免了HTTP/2基于TCP的HOL（前序包阻塞）問題。今天，大多數(shù)人都會(huì)隨身帶著諸如智能手機(jī)等移動(dòng)設(shè)備，在TCP中當(dāng)網(wǎng)絡(luò)環(huán)境發(fā)生變化時(shí)需要重新分配IP地址、建立連接，在未來這顯然太慢了。QUIC通過一個(gè)64 bit的GUID（Globally Unique Identifier，全球唯一標(biāo)識(shí)符）來標(biāo)記傳輸包，服務(wù)器可以通過它來區(qū)分來源端口，并且在QUIC連接斷開后不需要往返握手來建立連接。

所有這些都使QUIC有著強(qiáng)大的吸引力和應(yīng)用前景，或許會(huì)在某一天取代TCP、HTTP，更有可能的是它們互相吸收對(duì)方的長處，共同發(fā)展。

[1]Megyesi P, Kr?mer Z, Molnár S. How quick is QUIC[C]// Communications (ICC), 2016 IEEE International Conference on. IEEE, 2016: 1-6.

[2]Biswal P, Gnawali O. Does QUIC make the Web faster[C]// Global Communications Conference (GLOBECOM), 2016 IEEE. IEEE, 2016: 1-6.

[3]Gratzer F. QUIC-Quick UDP Internet Connections[J]. Future Internet (FI) and Innovative Internet Technologies and Mobile Communications (IITM), 2016, 39.

[4]Carlucci G, De Cicco L, Mascolo S. HTTP over UDP: an Experimental Investigation of QUIC[C]//Proceedings of the 30th Annual ACM Symposium on Applied Computing. ACM, 2015: 609-614.

Research on QUIC Protocol

Chen Zhenbo
(Wuhan Research Institute of Post and Telecommunications，Wuhan Hubei,430074)

In order to solve the two main problems of TCP transmission: (1) the time-consuming transmission mechanism of connection and disconnection; (2) Head-of-line blocking (HOL), this paper introduces a new protocol called QUIC, which is based on UDP, uses UDP as the transport layer protocol, avoids the problem of time-consuming and HOL, and ensures the reliability of transmission, overcomes the existing problems of UDP transmission through a clever mechanism .

TCP; HOL; UDP; QUIC