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

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

不過鼓舞人心的消息是，在代替TCP方面，有一位最重要的“候選人”——它能夠使互聯(lián)網(wǎng)傳輸繼續(xù)發(fā)展，并解決許多困擾互聯(lián)網(wǎng)多年的問題。具體來說，這個有可能替代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é)議由當時還在谷歌任職的Jim Roskind開發(fā)。2013年，QUIC正式對外公布。

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

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

為什么需要QUIC？

雖然TCP已經(jīng)“英勇地”服務(wù)多年，但它很可能已經(jīng)走到了盡頭。它最初設(shè)計用于有線互聯(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)核里實現(xiàn)，那么任何TCP傳輸?shù)母露夹枰?jīng)過新的內(nèi)核修改。對于一些基礎(chǔ)設(shè)施相對陳舊的公司來說，需要耗費數(shù)年才能采用新的特性。

TCP是傳輸層，沒有內(nèi)置加密（即TLS），所以它需要在上層增加。導致的結(jié)果就是需要很長時間才能建立安全連接，并且一些通過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ù)實的決定所帶來的優(yōu)勢相當明顯。UDP在互聯(lián)網(wǎng)上被廣泛部署，所以無需從零開始定義傳輸層（如從零開始，可能要耗費幾十年）。

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

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

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

誰在使用QUIC？

作為一種通用傳輸協(xié)議，QUIC可以用于許多基于互聯(lián)網(wǎng)的工作流，但部署的第一步就是將網(wǎng)頁瀏覽轉(zhuǎn)移到QUIC，因為它所帶來的最直接的好處就是基于HTTPS的Web瀏覽。

作為TCP的繼任者，QUIC只能與HTTP/3一起使用。為了使用該協(xié)議，客戶端和網(wǎng)站都需要支持它，但因為只有少數(shù)網(wǎng)站使用HTTP/3，所以這也成為了QUIC協(xié)議被廣泛采用道路上的一個阻礙。根據(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ù)和客戶端，所以它很容易實現(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（默認）、Edge、Firefox、Safari和其他默認使用TCP的瀏覽器（但將QUIC作為可選選項）。

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

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

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

負載均衡器：LiteSpeed和F5 BIG-IP。

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

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

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

為什么這么久才推出QUIC？

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

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

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

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

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

審核編輯 ：李倩