當上世紀70年代TCP被發明的時候，我想沒有人會預料到50年之后我們仍然在使用它。但事實是，我們現在還在使用TCP。

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

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

什么是QUIC?

QUIC是一種通用、安全、多路復用的傳輸層新型網絡協議。它的目的是替代TCP（目前是互聯網上用于數據傳輸的主流協議）。2012年，QUIC協議由當時還在谷歌任職的Jim Roskind開發。2013年，QUIC正式對外公布。

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

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

為什么需要QUIC？

雖然TCP已經“英勇地”服務多年，但它很可能已經走到了盡頭。它最初設計用于有線互聯網，根本沒有想到今天的無線互聯網會發展到如此容量和規模。許多專家很清楚，它無法適應今日互聯網的發展。而QUIC的出現可以使網絡更快、更高效、更安全，而最重要的是，可以不斷發展。

在QUIC出現以前，TCP的主要替代選擇是UDP。簡而言之，TCP提供了可靠的互聯網傳輸，其中可以確保數據的傳輸，而UDP提供了更快、但卻非可靠的傳輸。QUIC的目的就是結合TCP的最佳特性和UDP傳輸層。

TCP的主要限制包括：

TCP僅定義了40字節的可選位，且幾乎全部填滿。結果就是，沒有新特性的位置了。

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

由于TCP在內核里實現，那么任何TCP傳輸的更新都需要經過新的內核修改。對于一些基礎設施相對陳舊的公司來說，需要耗費數年才能采用新的特性。

TCP是傳輸層，沒有內置加密（即TLS），所以它需要在上層增加。導致的結果就是需要很長時間才能建立安全連接，并且一些通過TCP傳輸的數據（比如數據包頭部）沒有被加密，從而產生安全漏洞。

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

QUIC如何解決TCP所帶來的挑戰？

首先，在UDP之上構建QUIC這一務實的決定所帶來的優勢相當明顯。UDP在互聯網上被廣泛部署，所以無需從零開始定義傳輸層（如從零開始，可能要耗費幾十年）。

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

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

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

誰在使用QUIC？

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

作為TCP的繼任者，QUIC只能與HTTP/3一起使用。為了使用該協議，客戶端和網站都需要支持它，但因為只有少數網站使用HTTP/3，所以這也成為了QUIC協議被廣泛采用道路上的一個阻礙。根據W3Tech[1]，截止2021年10月2日，約35%的網站仍然在使用HTTP/1；約45%的網站遷移到了HTTP/2，而只有大約20%的網站正在使用HTTP/3和QUIC。

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

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

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

目前支持QUIC的生態包括：

瀏覽器：Chrome（默認）、Edge、Firefox、Safari和其他默認使用TCP的瀏覽器（但將QUIC作為可選選項）。

應用：所有來自谷歌的應用，如Gmail和YouTube；Facebook的應用；Uber。

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

Web服務器：LiteSpeed、H20、Ngnix和Apache。

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

技術社區項目：基于chromium實現的libquic、反向代理（充當反向代理服務器的Docker鏡像）。

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

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

為什么這么久才推出QUIC？

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

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

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

QUIC擁有互聯網傳輸的潛力

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

審核編輯 ：李倩