圖片來源 Next generation multiplexed transport over UDP (PDF)
減少數(shù)據(jù)包
前文已經(jīng)介紹過QUIC協(xié)議在創(chuàng)建連接握手時，只需要1到2個數(shù)據(jù)包即可。這對于擁有高速互聯(lián)網(wǎng)連接的網(wǎng)絡(luò)環(huán)境下可能沒有太大的感覺，因為此時一個數(shù)據(jù)包的延時大概在10～50ms之間。
一般來說延遲在50ms之內(nèi)不會有太大的感覺。但是對于無線網(wǎng)絡(luò)來說，情況就不太一樣了。且不說傳統(tǒng)2G/3G網(wǎng)絡(luò)，即使是4G網(wǎng)絡(luò)，客戶端和服務(wù)器之間的延時也通常在100ms以上。傳統(tǒng)TCP+TLS協(xié)議的傳輸方式，在創(chuàng)建連接時的4個數(shù)據(jù)包和QUIC協(xié)議的1個數(shù)據(jù)包相比，連接創(chuàng)建上就會多耗時300ms以上。
向前糾錯
QUIC協(xié)議有一個非常獨特的特性，稱為向前糾錯(Forward Error Correction)，每個數(shù)據(jù)包除了它本身的內(nèi)容之外，還包括了部分其他數(shù)據(jù)包的數(shù)據(jù)，因此少量的丟包可以通過其他包的冗余數(shù)據(jù)直接組裝而無需重傳。
這類似網(wǎng)絡(luò)層的RAID 5!
目前默認(rèn)的冗余量是10%，既每發(fā)送10個數(shù)據(jù)包，其冗余數(shù)據(jù)就可以重新構(gòu)建一個丟失的數(shù)據(jù)包。
向前糾錯犧牲了每個數(shù)據(jù)包可以發(fā)送數(shù)據(jù)的上限，但是減少了因為丟包導(dǎo)致的數(shù)據(jù)重傳，因為數(shù)據(jù)重傳將會消耗更多的時間(包括確認(rèn)數(shù)據(jù)包丟失、請求重傳、等待新數(shù)據(jù)包等步驟的時間消耗)。
會話重啟和并行下載
底層協(xié)議切換到UDP協(xié)議之后的另一大好處是，連接不再依賴于來源IP。
對于TCP協(xié)議來說，標(biāo)識一個TCP連接需要4個參數(shù)，既來源IP、來源端口、目的IP和目的端口。其中的任一參數(shù)改變，TCP連接就需要重新創(chuàng)建。
這對于傳統(tǒng)網(wǎng)絡(luò)來說影響不大，因為來源和目的IP相對固定。但是在無線網(wǎng)絡(luò)中，情況就大不相同了。設(shè)備在移動過程中，可能會因為網(wǎng)絡(luò)切換(如從WIFI網(wǎng)絡(luò)切換到4G網(wǎng)絡(luò)環(huán)境)，導(dǎo)致TCP連接需要重新創(chuàng)建。
QUIC協(xié)議使用了UDP協(xié)議，不再需要這四元組參數(shù)。同時QUIC協(xié)議實現(xiàn)了自己的會話標(biāo)記方式，稱為連接UUID。當(dāng)設(shè)備網(wǎng)絡(luò)環(huán)境切換時，連接UUID不會發(fā)生變化，因此無需重新進行握手。
該特性除了可以減少無謂的連接重連之外，還可以充分利用設(shè)備的不同網(wǎng)絡(luò)接口，進行資源的并行下載。因為雖然這些網(wǎng)絡(luò)接口有不同的IP，但只要他們能夠共享連接UUID，就能夠并行的從服務(wù)器下載數(shù)據(jù)。
QUIC協(xié)議實踐
Chrome瀏覽器從2014年開始已經(jīng)實驗性的支持了QUIC協(xié)議。可以通過在Chrome瀏覽器中輸入 chrome://net-internals/#quic 查看是否已經(jīng)支持QUIC協(xié)議。如果還未支持，可以在 chrome://flags/#enable-quic 中進行開啟。
開始Chrome瀏覽器對QUIC協(xié)議的支持之后，可以在 chrome://net-internals/#quic 中查看到當(dāng)前瀏覽器的QUIC一些連接。當(dāng)然目前只有Google服務(wù)才支持QUIC協(xié)議(如YouTube、 Google.com)。
(點擊放大圖像)
關(guān)于防火墻
通常系統(tǒng)管理員會關(guān)注防火墻的TCP規(guī)則，而忽略UDP規(guī)則。如果要在防火墻之后使用QUIC協(xié)議，除了傳統(tǒng)web服務(wù)需要開放的 80/TCP 、 443/TCP 之外，針對QUIC還需要開放 443/UDP 的訪問。
服務(wù)端使用QUIC協(xié)議
目前支持QUIC協(xié)議的web服務(wù)只有0.9版本以后的 Caddy 。其他常用web服務(wù)如nginx、apache等都未開始支持。curl表達了對QUIC協(xié)議 支持的興趣 。
QUIC性能優(yōu)勢
在2015年的 博文 中，Google分享了一些關(guān)于QUIC協(xié)議實現(xiàn)的結(jié)果。
這些優(yōu)勢在諸如YouTube的視頻服務(wù)上更為突出。用戶報告通過QUIC協(xié)議在觀看視頻的時候可以減少30%的重新緩沖時間。
如果YouTube收集的報告可靠，可以預(yù)見視頻服務(wù)提供商會更快的采用QUIC協(xié)議。