從HTTP/1.0開始，一直到HTTP/2，不管應(yīng)用層協(xié)議如何改進(jìn)，TCP一直以來(lái)都是HTTP協(xié)議的基礎(chǔ)，主要是因?yàn)樗芴峁┛煽窟B接。

但是，從HTTP 3.0開始，這個(gè)情況就有所變化了。

因?yàn)椋谧钚峦瞥龅腍TTP 3.0中，已經(jīng)徹底啟用TCP協(xié)議了。

TCP隊(duì)頭阻塞

我們知道，TCP傳輸過(guò)程中會(huì)把數(shù)據(jù)拆分為一個(gè)個(gè)**按照順序**排列的數(shù)據(jù)包，這些數(shù)據(jù)包通過(guò)網(wǎng)絡(luò)傳輸?shù)搅私邮斩?，接收端?*按照順序**將這些數(shù)據(jù)包組合成原始數(shù)據(jù)，這樣就完成了數(shù)據(jù)傳輸。

但是如果其中的某一個(gè)數(shù)據(jù)包沒(méi)有按照順序到達(dá)，接收端會(huì)一直保持連接等待數(shù)據(jù)包返回，這時(shí)候就會(huì)阻塞后續(xù)請(qǐng)求。這就發(fā)生了**TCP隊(duì)頭阻塞。**

HTTP/1.1的管道化持久連接也是使得同一個(gè)TCP鏈接可以被多個(gè)HTTP使用，但是HTTP/1.1中規(guī)定一個(gè)域名可以有6個(gè)TCP連接。而HTTP/2中，同一個(gè)域名只是用一個(gè)TCP連接。

所以，在HTTP/2中，TCP隊(duì)頭阻塞造成的影響會(huì)更大，因?yàn)镠TTP/2的多路復(fù)用技術(shù)使得多個(gè)請(qǐng)求其實(shí)是基于同一個(gè)TCP連接的，那如果某一個(gè)請(qǐng)求造成了TCP隊(duì)頭阻塞，那么多個(gè)請(qǐng)求都會(huì)受到影響。

TCP握手時(shí)長(zhǎng)

我們都知道TCP的可靠連接是基于三次握手與四次揮手實(shí)現(xiàn)的。但是問(wèn)題是三次握手是需要消耗時(shí)間的。

TCP三次握手的過(guò)程客戶端和服務(wù)器之間需要交互三次，那么也就是說(shuō)需要額外消耗1.5 RTT。

> RTT：網(wǎng)絡(luò)延遲（Round Trip Time）。他是指一個(gè)請(qǐng)求從客戶端瀏覽器發(fā)送一個(gè)請(qǐng)求數(shù)據(jù)包到服務(wù)器，再?gòu)姆?wù)器得到響應(yīng)數(shù)據(jù)包的這段時(shí)間。RTT 是反映網(wǎng)絡(luò)性能的一個(gè)重要指標(biāo)。

在客戶端和服務(wù)端距離比較遠(yuǎn)的情況下，如果一個(gè)RTT達(dá)到300-400ms，那么我握手過(guò)程就會(huì)顯得很”慢”了。

升級(jí)TCP

基于上面我們提到的兩個(gè)問(wèn)題，有人提出來(lái)說(shuō)：既然TCP存在這些問(wèn)題，并且我們也知道這些問(wèn)題的存在，甚至解決方案也不難想到，為什么不能對(duì)協(xié)議本身做一次升級(jí)，解決這些問(wèn)題呢？

其實(shí)，這就涉及到一個(gè)”協(xié)議僵化“的問(wèn)題。

這樣講，我們?cè)诨ヂ?lián)網(wǎng)上瀏覽數(shù)據(jù)的時(shí)候，數(shù)據(jù)的傳輸過(guò)程其實(shí)是極其復(fù)雜的。

我們知道的，想要在家里使用網(wǎng)絡(luò)有幾個(gè)前提，首先我們要通過(guò)運(yùn)行商開通網(wǎng)絡(luò)，并且需要使用路由器，而路由器就是網(wǎng)絡(luò)傳輸過(guò)程中的一個(gè)中間設(shè)備。

中間設(shè)備是指插入在數(shù)據(jù)終端和信號(hào)轉(zhuǎn)換設(shè)備之間，完成調(diào)制前或解調(diào)后某些附加功能的輔助設(shè)備。例如集線器、交換機(jī)和無(wú)線接入點(diǎn)、路由器、安全解調(diào)器、通信服務(wù)器等都是中間設(shè)備。

在我們看不到的地方，這種中間設(shè)備還有很多很多，一個(gè)網(wǎng)絡(luò)需要經(jīng)過(guò)無(wú)數(shù)個(gè)中間設(shè)備的轉(zhuǎn)發(fā)才能到達(dá)終端用戶。

如果TCP協(xié)議需要升級(jí)，那么意味著需要這些中間設(shè)備都能支持新的特性，我們知道路由器我們可以重新?lián)Q一個(gè)，但是其他的那些中間設(shè)備呢？尤其是那些比較大型的設(shè)備呢？更換起來(lái)的成本是巨大的。

而且，除了中間設(shè)備之外，操作系統(tǒng)也是一個(gè)重要的因素，因?yàn)門CP協(xié)議需要通過(guò)操作系統(tǒng)內(nèi)核來(lái)實(shí)現(xiàn)，而操作系統(tǒng)的更新也是非常滯后的。

所以，這種問(wèn)題就被稱之為”中間設(shè)備僵化”，也是導(dǎo)致”協(xié)議僵化”的重要原因。這也是限制著TCP協(xié)議更新的一個(gè)重要原因。

所以，近些年來(lái)，由IETF標(biāo)準(zhǔn)化的許多TCP新特性都因缺乏廣泛支持而沒(méi)有得到廣泛的部署或使用！

QUIC

所以，擺在HTTP/3.0面前的就只有一條路，那就是放棄TCP。

于是，HTTP/3.0在基于UDP+迪菲赫爾曼算法（Diffie–Hellman）之上實(shí)現(xiàn)了QUIC協(xié)議（Quick UDP Internet Connections）。

QUIC協(xié)議有以下特點(diǎn)：

基于UDP的傳輸層協(xié)議：它使用UDP端口號(hào)來(lái)識(shí)別指定機(jī)器上的特定服務(wù)器。

可靠性：雖然UDP是不可靠傳輸協(xié)議，但是QUIC在UDP的基礎(chǔ)上做了些改造，使得他提供了和TCP類似的可靠性。它提供了數(shù)據(jù)包重傳、擁塞控制、調(diào)整傳輸節(jié)奏以及其他一些TCP中存在的特性。

實(shí)現(xiàn)了無(wú)序、并發(fā)字節(jié)流：QUIC的單個(gè)數(shù)據(jù)流可以保證有序交付，但多個(gè)數(shù)據(jù)流之間可能亂序，這意味著單個(gè)數(shù)據(jù)流的傳輸是按序的，但是多個(gè)數(shù)據(jù)流中接收方收到的順序可能與發(fā)送方的發(fā)送順序不同！

快速握手：QUIC提供0-RTT和1-RTT的連接建立

使用TLS 1.3傳輸層安全協(xié)議：與更早的TLS版本相比，TLS 1.3有著很多優(yōu)點(diǎn)，但使用它的最主要原因是其握手所花費(fèi)的往返次數(shù)更低，從而能降低協(xié)議的延遲。

阻礙

以上，我們介紹了很多QUIC的相比較于TCP的優(yōu)點(diǎn)，可以說(shuō)這種協(xié)議相比較于TCP確實(shí)要優(yōu)秀一些。

因?yàn)樗腔赨DP的，并沒(méi)有改變UDP協(xié)議本身，只是做了一些增強(qiáng)，雖然可以避開中間設(shè)備僵化的問(wèn)題，但是，在推廣上面也不是完全沒(méi)有問(wèn)題的。

首先，很多企業(yè)、運(yùn)營(yíng)商和組織對(duì)53端口（DNS）以外的UDP流量會(huì)進(jìn)行攔截或者限流，因?yàn)檫@些流量近來(lái)常被濫用于攻擊。

特別是一些現(xiàn)有的UDP協(xié)議和實(shí)現(xiàn)易受放大攻擊（amplification attack）威脅，攻擊者可以控制無(wú)辜的主機(jī)向受害者投放發(fā)送大量的流量。

所以，基于UDP的QUIC協(xié)議的傳輸可能會(huì)受到屏蔽。

另外，因?yàn)閁DP一直以來(lái)定位都是不可靠連接，所以有很多中間設(shè)備對(duì)于他的支持和優(yōu)化程度并不高，所以，出現(xiàn)丟包的可能性還是有的。。。

但是不管怎么樣，HTTP/3.0的時(shí)代一定會(huì)到來(lái)的，QUIC協(xié)議全面代替TCP的時(shí)代也會(huì)到來(lái)的，讓我們拭目以待吧。