從HTTP/1.0開始，一直到HTTP/2慈参，不管應(yīng)用層協(xié)議如何改進呛牲，TCP一直以來都是HTTP協(xié)議的基礎(chǔ)，主要是因為他能提供可靠連接驮配。
但是娘扩，從HTTP 3.0開始着茸，這個情況就有所變化了。
因為琐旁，在最新推出的HTTP 3.0中涮阔，已經(jīng)徹底啟用TCP協(xié)議了。
TCP隊頭阻塞
我們知道灰殴，TCP傳輸過程中會把數(shù)據(jù)拆分為一個個按照順序排列的數(shù)據(jù)包敬特，這些數(shù)據(jù)包通過網(wǎng)絡(luò)傳輸?shù)搅私邮斩耍邮斩嗽?strong>按照順序將這些數(shù)據(jù)包組合成原始數(shù)據(jù)牺陶，這樣就完成了數(shù)據(jù)傳輸伟阔。
但是如果其中的某一個數(shù)據(jù)包沒有按照順序到達，接收端會一直保持連接等待數(shù)據(jù)包返回掰伸，這時候就會阻塞后續(xù)請求皱炉。這就發(fā)生了TCP隊頭阻塞。
HTTP/1.1的管道化持久連接也是使得同一個TCP鏈接可以被多個HTTP使用狮鸭，但是HTTP/1.1中規(guī)定一個域名可以有6個TCP連接娃承。而HTTP/2中，同一個域名只是用一個TCP連接怕篷。
所以历筝，在HTTP/2中，TCP隊頭阻塞造成的影響會更大廊谓，因為HTTP/2的多路復(fù)用技術(shù)使得多個請求其實是基于同一個TCP連接的梳猪，那如果某一個請求造成了TCP隊頭阻塞，那么多個請求都會受到影響蒸痹。
TCP握手時長
我們都知道TCP的可靠連接是基于三次握手與四次揮手實現(xiàn)的春弥。但是問題是三次握手是需要消耗時間的。
TCP三次握手的過程客戶端和服務(wù)器之間需要交互三次叠荠，那么也就是說需要額外消耗1.5 RTT匿沛。
RTT：網(wǎng)絡(luò)延遲（Round Trip Time）。他是指一個請求從客戶端瀏覽器發(fā)送一個請求數(shù)據(jù)包到服務(wù)器榛鼎，再從服務(wù)器得到響應(yīng)數(shù)據(jù)包的這段時間逃呼。RTT 是反映網(wǎng)絡(luò)性能的一個重要指標。
在客戶端和服務(wù)端距離比較遠的情況下者娱，如果一個RTT達到300-400ms抡笼，那么我握手過程就會顯得很”慢”了。
升級TCP
基于上面我們提到的兩個問題黄鳍，有人提出來說：既然TCP存在這些問題推姻，并且我們也知道這些問題的存在，甚至解決方案也不難想到框沟，為什么不能對協(xié)議本身做一次升級藏古，解決這些問題呢增炭？
其實，這就涉及到一個”協(xié)議僵化“的問題拧晕。
這樣講隙姿，我們在互聯(lián)網(wǎng)上瀏覽數(shù)據(jù)的時候，數(shù)據(jù)的傳輸過程其實是極其復(fù)雜的防症。
我們知道的孟辑，想要在家里使用網(wǎng)絡(luò)有幾個前提，首先我們要通過運行商開通網(wǎng)絡(luò)蔫敲，并且需要使用路由器饲嗽，而路由器就是網(wǎng)絡(luò)傳輸過程中的一個中間設(shè)備。
中間設(shè)備是指插入在數(shù)據(jù)終端和信號轉(zhuǎn)換設(shè)備之間奈嘿，完成調(diào)制前或解調(diào)后某些附加功能的輔助設(shè)備貌虾。例如集線器、交換機和無線接入點裙犹、路由器尽狠、安全解調(diào)器、通信服務(wù)器等都是中間設(shè)備叶圃。
在我們看不到的地方袄膏，這種中間設(shè)備還有很多很多，一個網(wǎng)絡(luò)需要經(jīng)過無數(shù)個中間設(shè)備的轉(zhuǎn)發(fā)才能到達終端用戶掺冠。
如果TCP協(xié)議需要升級沉馆，那么意味著需要這些中間設(shè)備都能支持新的特性，我們知道路由器我們可以重新?lián)Q一個德崭，但是其他的那些中間設(shè)備呢斥黑？尤其是那些比較大型的設(shè)備呢？更換起來的成本是巨大的眉厨。
而且锌奴，除了中間設(shè)備之外，操作系統(tǒng)也是一個重要的因素憾股，因為TCP協(xié)議需要通過操作系統(tǒng)內(nèi)核來實現(xiàn)鹿蜀，而操作系統(tǒng)的更新也是非常滯后的。
所以荔燎，這種問題就被稱之為”中間設(shè)備僵化”耻姥，也是導致”協(xié)議僵化”的重要原因。這也是限制著TCP協(xié)議更新的一個重要原因有咨。
所以，近些年來蒸健，由IETF標準化的許多TCP新特性都因缺乏廣泛支持而沒有得到廣泛的部署或使用座享！
QUIC
所以婉商，擺在HTTP/3.0面前的就只有一條路，那就是放棄TCP渣叛。
于是丈秩，HTTP/3.0在基于UDP+迪菲赫爾曼算法（Diffie–Hellman）之上實現(xiàn)了QUIC協(xié)議（Quick UDP Internet Connections）。
QUIC協(xié)議有以下特點：
基于UDP的傳輸層協(xié)議：它使用UDP端口號來識別指定機器上的特定服務(wù)器淳衙。
可靠性：雖然UDP是不可靠傳輸協(xié)議蘑秽，但是QUIC在UDP的基礎(chǔ)上做了些改造，使得他提供了和TCP類似的可靠性箫攀。它提供了數(shù)據(jù)包重傳肠牲、擁塞控制、調(diào)整傳輸節(jié)奏以及其他一些TCP中存在的特性靴跛。
實現(xiàn)了無序缀雳、并發(fā)字節(jié)流：QUIC的單個數(shù)據(jù)流可以保證有序交付，但多個數(shù)據(jù)流之間可能亂序梢睛，這意味著單個數(shù)據(jù)流的傳輸是按序的肥印，但是多個數(shù)據(jù)流中接收方收到的順序可能與發(fā)送方的發(fā)送順序不同！
快速握手：QUIC提供0-RTT和1-RTT的連接建立
使用TLS 1.3傳輸層安全協(xié)議：與更早的TLS版本相比绝葡，TLS 1.3有著很多優(yōu)點深碱，但使用它的最主要原因是其握手所花費的往返次數(shù)更低，從而能降低協(xié)議的延遲藏畅。
阻礙
以上敷硅，我們介紹了很多QUIC的相比較于TCP的優(yōu)點，可以說這種協(xié)議相比較于TCP確實要優(yōu)秀一些墓赴。
因為他是基于UDP的竞膳，并沒有改變UDP協(xié)議本身，只是做了一些增強诫硕，雖然可以避開中間設(shè)備僵化的問題坦辟，但是，在推廣上面也不是完全沒有問題的章办。
首先锉走，很多企業(yè)、運營商和組織對53端口（DNS）以外的UDP流量會進行攔截或者限流藕届，因為這些流量近來常被濫用于攻擊挪蹭。
特別是一些現(xiàn)有的UDP協(xié)議和實現(xiàn)易受放大攻擊（amplification attack）威脅，攻擊者可以控制無辜的主機向受害者投放發(fā)送大量的流量休偶。
所以梁厉，基于UDP的QUIC協(xié)議的傳輸可能會受到屏蔽。
另外，因為UDP一直以來定位都是不可靠連接词顾，所以有很多中間設(shè)備對于他的支持和優(yōu)化程度并不高八秃，所以，出現(xiàn)丟包的可能性還是有的肉盹。昔驱。。
但是不管怎么樣上忍，HTTP/3.0的時代一定會到來的骤肛，QUIC協(xié)議全面代替TCP的時代也會到來的，讓我們拭目以待吧窍蓝。
