發(fā)明QUIC的原因以及QUIC的使用人群

當(dāng)上世紀(jì)70年代TCP被發(fā)明的時(shí)候，我想沒有人會預(yù)料到50年之后我們?nèi)匀辉谑褂盟?。但事?shí)是，我們現(xiàn)在還在使用TCP。

在過去幾十年中，TCP不斷發(fā)展，并新增了與可靠數(shù)據(jù)傳輸、流量控制、擁塞控制等相關(guān)的各種特性。但許多研究者以及包括我在內(nèi)的從業(yè)者都認(rèn)為TCP已至末路。自從TCP發(fā)明以來，互聯(lián)網(wǎng)已經(jīng)成為社會生活中非常重要的組成部分，但遺憾的是，TCP并沒有與時(shí)俱進(jìn)以滿足不斷增長的需求。

不過鼓舞人心的消息是，在代替TCP方面，有一位最重要的“候選人”——它能夠使互聯(lián)網(wǎng)傳輸繼續(xù)發(fā)展，并解決許多困擾互聯(lián)網(wǎng)多年的問題。具體來說，這個(gè)有可能替代TCP的協(xié)議被人們稱為QUIC，人們對QUIC的出現(xiàn)激動不已。但這種激動是否合理，我們將在今后的文章說明。本文我們將來了解發(fā)明QUIC的原因以及QUIC的使用人群。

什么是QUIC?

QUIC是一種通用、安全、多路復(fù)用的傳輸層新型網(wǎng)絡(luò)協(xié)議。它的目的是替代TCP（目前是互聯(lián)網(wǎng)上用于數(shù)據(jù)傳輸?shù)闹髁鲄f(xié)議）。2012年，QUIC協(xié)議由當(dāng)時(shí)還在谷歌任職的Jim Roskind開發(fā)。2013年，QUIC正式對外公布。

2015年，QUIC被提交給IETF進(jìn)行標(biāo)準(zhǔn)化，但是直到六年以后，也就是2021年5月，IETF才發(fā)布了第一版標(biāo)準(zhǔn)化的QUIC，被命名為RFC 9000。同時(shí)，IETF還發(fā)布使用了QUIC的HTTP/3標(biāo)準(zhǔn)化版本。

QUIC吸納了很多與TCP類似的屬性，還有TLS加密，將它們置于UDP傳輸之上的應(yīng)用層中。

為什么需要QUIC？

雖然TCP已經(jīng)“英勇地”服務(wù)多年，但它很可能已經(jīng)走到了盡頭。它最初設(shè)計(jì)用于有線互聯(lián)網(wǎng)，根本沒有想到今天的無線互聯(lián)網(wǎng)會發(fā)展到如此容量和規(guī)模。許多專家很清楚，它無法適應(yīng)今日互聯(lián)網(wǎng)的發(fā)展。而QUIC的出現(xiàn)可以使網(wǎng)絡(luò)更快、更高效、更安全，而最重要的是，可以不斷發(fā)展。

在QUIC出現(xiàn)以前，TCP的主要替代選擇是UDP。簡而言之，TCP提供了可靠的互聯(lián)網(wǎng)傳輸，其中可以確保數(shù)據(jù)的傳輸，而UDP提供了更快、但卻非可靠的傳輸。QUIC的目的就是結(jié)合TCP的最佳特性和UDP傳輸層。

TCP的主要限制包括：

TCP僅定義了40字節(jié)的可選位，且?guī)缀跞刻顫M。結(jié)果就是，沒有新特性的位置了。

許多中間件（如防火墻）假設(shè)TCP數(shù)據(jù)包將以某種確定方式構(gòu)造。如果數(shù)據(jù)包與它們的預(yù)期相差太大，就會被拒絕或者延遲，這使得TCP協(xié)議幾乎無法發(fā)展。

由于TCP在內(nèi)核里實(shí)現(xiàn)，那么任何TCP傳輸?shù)母露夹枰?jīng)過新的內(nèi)核修改。對于一些基礎(chǔ)設(shè)施相對陳舊的公司來說，需要耗費(fèi)數(shù)年才能采用新的特性。

TCP是傳輸層，沒有內(nèi)置加密（即TLS），所以它需要在上層增加。導(dǎo)致的結(jié)果就是需要很長時(shí)間才能建立安全連接，并且一些通過TCP傳輸?shù)臄?shù)據(jù)（比如數(shù)據(jù)包頭部）沒有被加密，從而產(chǎn)生安全漏洞。

QUIC和HTTP/3一起使用的目的就是代替HTTP/1（或2）和TCP的組合，以及解決TCP協(xié)議所帶來的一些已知問題。

QUIC如何解決TCP所帶來的挑戰(zhàn)？

首先，在UDP之上構(gòu)建QUIC這一務(wù)實(shí)的決定所帶來的優(yōu)勢相當(dāng)明顯。UDP在互聯(lián)網(wǎng)上被廣泛部署，所以無需從零開始定義傳輸層（如從零開始，可能要耗費(fèi)幾十年）。

相較于TCP，UDP的開銷要少很多，這個(gè)特點(diǎn)使它更快速、更簡單也更高效。但它存在一個(gè)重大缺陷，那就是缺乏可靠性。UDP無法確保每個(gè)通過它發(fā)送的數(shù)據(jù)包傳輸，也無法確保數(shù)據(jù)包以準(zhǔn)確順序發(fā)送給接收方。

QUIC繼承了TCP的特性，將它們構(gòu)建于UDP之上，并添加了更多其他特性。TCP是傳輸層，TLS和HTTP2位于其上方的應(yīng)用層，QUIC同時(shí)包含了應(yīng)用層和傳輸層機(jī)制。因此，它的目的就是代替TCP傳輸層。

QUIC使用UDP作為底層傳輸協(xié)議，同時(shí)內(nèi)置TLS加密，并結(jié)合了TCP的可靠性相關(guān)特性。QUIC在應(yīng)用層（即用戶空間）獲得進(jìn)一步實(shí)現(xiàn)。因此，無需更新內(nèi)核，你就可以進(jìn)行大量修改。

誰在使用QUIC？

作為一種通用傳輸協(xié)議，QUIC可以用于許多基于互聯(lián)網(wǎng)的工作流，但部署的第一步就是將網(wǎng)頁瀏覽轉(zhuǎn)移到QUIC，因?yàn)樗鶐淼淖钪苯拥暮锰幘褪腔贖TTPS的Web瀏覽。

作為TCP的繼任者，QUIC只能與HTTP/3一起使用。為了使用該協(xié)議，客戶端和網(wǎng)站都需要支持它，但因?yàn)橹挥猩贁?shù)網(wǎng)站使用HTTP/3，所以這也成為了QUIC協(xié)議被廣泛采用道路上的一個(gè)阻礙。根據(jù)W3Tech[1]，截止2021年10月2日，約35%的網(wǎng)站仍然在使用HTTP/1；約45%的網(wǎng)站遷移到了HTTP/2，而只有大約20%的網(wǎng)站正在使用HTTP/3和QUIC。

截止2021年中旬，QUIC占據(jù)了互聯(lián)網(wǎng)流量的12%。谷歌是第一家（也是最有名的）采用QUIC協(xié)議的公司（毫不意外，畢竟QUIC協(xié)議是由谷歌員工開發(fā)的）。在其生態(tài)中，谷歌擁有自己的服務(wù)器、應(yīng)用程序、服務(wù)和客戶端，所以它很容易實(shí)現(xiàn)QUIC，并將眾多應(yīng)用遷移到新的框架。30%的YouTube流量已經(jīng)轉(zhuǎn)移到了QUIC。

接著是Facebook（現(xiàn)更名為Meta），它已經(jīng)將70%的流量遷移到了QUIC。Facebook和Instagram移動應(yīng)用程序都已經(jīng)在最大限度地使用QUIC。

這就是QUIC協(xié)議采用所面臨的現(xiàn)狀。微軟只有少量流量使用了QUIC；在流媒體領(lǐng)域，只有YouTube和Facebook Live支持了QUIC。流媒體視頻接近80%的Web流量，大部分依然使用的是TCP。流媒體巨頭公司Netflix和Amazon Prime都沒有支持QUIC。不過，微軟有將其VPN產(chǎn)品從TCP遷移到QUIC的傾向[2]。

目前支持QUIC的生態(tài)包括：

瀏覽器：Chrome（默認(rèn)）、Edge、Firefox、Safari和其他默認(rèn)使用TCP的瀏覽器（但將QUIC作為可選選項(xiàng)）。

應(yīng)用：所有來自谷歌的應(yīng)用，如Gmail和YouTube；Facebook的應(yīng)用；Uber。

服務(wù)器/CDN：Akamai、微軟、Apple、谷歌、Cloudflare、Fastly、Caddy和NetApp。其中一些CDN已經(jīng)驗(yàn)證了QUIC的實(shí)現(xiàn)，但幾乎它們所有的流量都還在使用TCP。

Web服務(wù)器：LiteSpeed、H20、Ngnix和Apache。

負(fù)載均衡器：LiteSpeed和F5 BIG-IP。

技術(shù)社區(qū)項(xiàng)目：基于chromium實(shí)現(xiàn)的libquic、反向代理（充當(dāng)反向代理服務(wù)器的Docker鏡像）。

編程語言：Go（quic-go）、Quic.NET（C#）。

如你所見，基于Web的基礎(chǔ)設(shè)施已經(jīng)開始向QUIC遷移，但是在大多數(shù)情況下，QUIC還不是默認(rèn)選項(xiàng)，而且一些大公司依然沒有支持QUIC。

為什么這么久才推出QUIC？

QUIC依然是一個(gè)新標(biāo)準(zhǔn)，它的目的是重新設(shè)計(jì)互聯(lián)網(wǎng)的諸多方面。而對如此眾多的特性進(jìn)行標(biāo)準(zhǔn)化需要時(shí)間。雖然QUIC在2013年首次提交給IETF，但直到2021年5月才正式推出，所以它仍然沒有獲得不同生態(tài)的完全支持。

QUIC首次公布與正式標(biāo)準(zhǔn)化之間相隔時(shí)間太久，這使得很多廠商開始開發(fā)自己的協(xié)議版本。他們在獲取到最初發(fā)布的QUIC后，將自己的版本構(gòu)建在其上。但是他們所使用的協(xié)議不同于最終及官方版本。因此，QUIC有很多不同的版本，其中一些并不支持官方版本的必備特性，且不同的廠商需要時(shí)間將自己的版本調(diào)整為與2021官方版本保持一致。我們可以看到，這種過渡還出在早期階段，比如實(shí)現(xiàn)了自己的gQUIC版本的谷歌正在遷移到IETF發(fā)布的QUIC版本。

也就是說，更加廣泛的QUIC采用依然要面臨許多挑戰(zhàn)，包括企業(yè)安全規(guī)定對QUIC的接受度、支持TCP回退的請求以及規(guī)范依然相當(dāng)基礎(chǔ)這一事實(shí)。我將在后續(xù)文章中更加詳細(xì)地說明其中一些挑戰(zhàn)。

QUIC擁有互聯(lián)網(wǎng)傳輸?shù)臐摿?/p>

TCP是為過去的互聯(lián)網(wǎng)時(shí)代所設(shè)計(jì)的協(xié)議，它無法適用于今日的互聯(lián)網(wǎng)，而QUIC的目的是解決TCP的許多問題，使互聯(lián)網(wǎng)變得更安全、更靈敏并且可以不斷發(fā)展。需要謹(jǐn)記的是，我們現(xiàn)在仍處在QUIC協(xié)議部署的早期階段，接下來的幾年我們將見證它是否能夠完成成為TCP繼任者的使命。QUIC的潛力不僅僅是成為TCP的替代方案，它在實(shí)時(shí)協(xié)議上的一些標(biāo)準(zhǔn)化舉措有可能使其代替在視頻會議和云游戲中使用的實(shí)時(shí)通信協(xié)議（如WebRTC）。

審核編輯 ：李倩