QUIC(Quick UDP Internet Connections)協(xié)議是一種全新的基于UDP的web開發(fā)協(xié)議。
從TCP協(xié)議說(shuō)起
當(dāng)前，web平臺(tái)的數(shù)據(jù)傳輸都基于TCP協(xié)議。TCP協(xié)議在創(chuàng)建連接之前需要進(jìn)行 三次握手 (圖1)，如果需要提高數(shù)據(jù)交互的安全性，既增加傳輸層安全協(xié)議(TLS)，還會(huì)增加更多的握手次數(shù)(圖2)。
圖1，TCP三次握手示意(來(lái)源 Next generation multiplexed transport over UDP (PDF) )
圖2，TLS初始化握手示意(來(lái)源 Next generation multiplexed transport over UDP (PDF) )
正因?yàn)門CP協(xié)議連接建立的成本相對(duì)較高，可以通過 TCP快速打開 (TCP Fast Open)來(lái)減少建立連接時(shí)的握手次數(shù)。但是該技術(shù)目前應(yīng)用較少。
和TCP相反，UDP協(xié)議是無(wú)連接協(xié)議?？蛻舳税l(fā)出UDP數(shù)據(jù)包后，只能“假設(shè)”這個(gè)數(shù)據(jù)包已經(jīng)被服務(wù)端接收。這樣的好處是在網(wǎng)絡(luò)傳輸層無(wú)需對(duì)數(shù)據(jù)包進(jìn)行確認(rèn)，但存在的問題就是為了確保數(shù)據(jù)傳輸?shù)目煽啃?，?yīng)用層協(xié)議需要自己完成包傳輸情況的確認(rèn)。
此時(shí)，QUIC協(xié)議就登場(chǎng)了。QUIC協(xié)議可以在1到2個(gè)數(shù)據(jù)包(取決于連接的服務(wù)器是新的還是已知的)內(nèi)，完成連接的創(chuàng)建(包括TLS)(圖3)。
圖3，QUIC協(xié)議握手示意(來(lái)源 Next generation multiplexed transport over UDP (PDF) )
QUIC協(xié)議的目的
從前文對(duì)比可以看出，QUIC協(xié)議的主要目的，是為了整合TCP協(xié)議的可靠性和UDP協(xié)議的速度和效率。
QUIC的維基百科頁(yè)面 介紹了該協(xié)議的主要目的：
對(duì)于Google來(lái)說(shuō)優(yōu)化TCP協(xié)議是一個(gè)長(zhǎng)期目標(biāo)，QUIC旨在創(chuàng)建幾乎等同于TCP的獨(dú)立連接，但有著低延遲，并對(duì)類似SPDY的多路復(fù)用流協(xié)議有更好的支持。 如果QUIC協(xié)議的特性被證明是有效的，這些特性以后可能會(huì)被遷移入后續(xù)版本的TCP和TLS協(xié)議(它們都有很長(zhǎng)的開發(fā)周期)。
值得注意的是， 如果QUIC的特性被證明是有效的，這些特性以后可能會(huì)被遷移到后續(xù)版本的TCP協(xié)議中 。
TCP協(xié)議的實(shí)現(xiàn)是高度管制的。TCP協(xié)議棧通常由操作系統(tǒng)實(shí)現(xiàn)，如Linux、Windows內(nèi)核或者其他移動(dòng)設(shè)備操作系統(tǒng)。修改TCP協(xié)議是一項(xiàng)浩大的工程，因?yàn)槊糠N設(shè)備、系統(tǒng)的實(shí)現(xiàn)都需要更新。
相反的，UDP協(xié)議在操作系統(tǒng)層面實(shí)現(xiàn)相對(duì)簡(jiǎn)單，基于UDP協(xié)議實(shí)現(xiàn)新的協(xié)議以驗(yàn)證Google對(duì)于TCP協(xié)議改進(jìn)的理論，驗(yàn)證成本相對(duì)較低。
QUIC協(xié)議內(nèi)置了TLS棧，實(shí)現(xiàn)了自己的 傳輸加密層 ，而沒有使用現(xiàn)有的TLS 1.2。同時(shí)QUIC還包含了部分HTTP/2的實(shí)現(xiàn)，因此QUIC的地位看起來(lái)是這樣的：
從圖上可以看出，QUIC底層通過UDP協(xié)議替代了TCP，上層只需要一層用于和遠(yuǎn)程服務(wù)器交互的HTTP/2 API。這是因?yàn)镼UIC協(xié)議已經(jīng)包含了多路復(fù)用和連接管理，HTTP API只需要完成HTTP協(xié)議的解析即可。
QUIC特性
避免前序包阻塞
SPDY和HTTP/2協(xié)議現(xiàn)在都支持將頁(yè)面的多個(gè)數(shù)據(jù)(如圖片、js等)通過一個(gè)數(shù)據(jù)鏈接進(jìn)行傳輸。該特性能夠加快頁(yè)面組件的傳輸速度，但是對(duì)于TCP協(xié)議來(lái)說(shuō)，這會(huì)遇到前序包阻塞的問題。這是由于TCP協(xié)議在處理包時(shí)是有嚴(yán)格順序的，當(dāng)其中一個(gè)數(shù)據(jù)包遇到問題，TCP連接需要等待這個(gè)包完成重傳之后才能繼續(xù)進(jìn)行。因此，即使邏輯上一個(gè)TCP連接上并行的在進(jìn)行多路數(shù)據(jù)傳輸，其他毫無(wú)關(guān)聯(lián)的數(shù)據(jù)也會(huì)因此阻塞。
圖片來(lái)源 Next generation multiplexed transport over UDP (PDF)
QUIC協(xié)議直接通過底層使用UDP協(xié)議天然的避免了該問題。由于UDP協(xié)議沒有嚴(yán)格的順序，當(dāng)一個(gè)數(shù)據(jù)包遇到問題需要重傳時(shí)，只會(huì)影響該數(shù)據(jù)包對(duì)應(yīng)的資源，其他獨(dú)立的資源(如其他css、js文件)不會(huì)受到影響。
