首先，我們先來介紹一下HTTP2.0傳輸協(xié)議，HTTP2.0傳輸協(xié)議通過二進制傳輸、多路復(fù)用、Header壓縮、Server Push等特性大大地提升了HTTP1.x的性能，但是由于HTTP2.0傳輸協(xié)議是基于TCP協(xié)議實現(xiàn)的，TCP本身特性導(dǎo)致其必然存在一定的瓶頸及缺陷。
HTTP2.0缺陷：
①Head-Of-Line Blocking(隊頭阻塞)：HTTP2.0傳輸協(xié)議多個請求都是在一個TCP連接中進行的，如果TCP傳輸時出現(xiàn)丟包，那么整個TCP就要等待重傳，這樣就會導(dǎo)致該TCP連接中的所有請求被阻塞。舉個例子，見下圖：
從上圖可以看到發(fā)送端一共發(fā)送了四包packet，其中packet 3在網(wǎng)絡(luò)層丟失了，即使packet4被接收方的內(nèi)核接收到，但因為在內(nèi)核中其數(shù)據(jù)并不是連續(xù)的，導(dǎo)致接收端的應(yīng)用層無法讀取，只有等到packet3重傳后，應(yīng)用層才可以從內(nèi)核中讀取數(shù)據(jù)。
②TCP和TLS握手時延：
TCP協(xié)議需要通過三次握手來建立TCP連接確保通信的可靠性（1.5個RTT），TLS_V1.2協(xié)議會在TCP協(xié)議之上通過四次握手建立TSL連接保證通信的安全性（2個RTT），HTTP協(xié)議會在TCP與TLS上發(fā)送請求并接收響應(yīng)（1個RTT）。
這意味著,假如我們想要訪問美國的服務(wù)器，RTT約為250ms時，那么此時HTTPS請求的耗時大概要為1s左右，這就比較高了。
③連接遷移需要重新連接：
一個TCP連接是由源IP地址、源端口、目標(biāo)IP地址以及目標(biāo)端口來確定的。這表示如果端口或者IP地址發(fā)生變動，就需要重新讓TCP和TLS進行連接。這不適于設(shè)備切換網(wǎng)絡(luò)的場景。
上面這三個問題其實都是TCP協(xié)議固有的問題，無論HTTP/2應(yīng)用層怎樣進行設(shè)計，都改變不了這些缺陷，要想解決其根本，就需要將傳輸層協(xié)議TCP更換為UDP，而HTTP 3.0就是這樣做的！
我們知道UDP是一種簡單、不可靠的傳輸協(xié)議。當(dāng)然HTTP 3.0也不僅僅只是將傳輸協(xié)議由TCP替換為UDP，它還基于UDP在應(yīng)用層實現(xiàn)一個叫做QUIC的協(xié)議，這個協(xié)議具有與TCP類似的連接管理、擁塞控制等特性，可以將UDP變得“可靠”。
下面介紹QUIC協(xié)議的優(yōu)點：
①無隊頭阻塞：
QUIC使用的傳輸協(xié)議是UDP，其不關(guān)心數(shù)據(jù)包的順序或者數(shù)據(jù)包丟失，但是QUIC會保證數(shù)據(jù)包的可靠性，每個數(shù)據(jù)包都會有一個唯一標(biāo)識，當(dāng)某個stream的一個數(shù)據(jù)包丟失。這個stream的其他數(shù)據(jù)包即使到達了HTTP，也不會被讀取，直到QUIC重傳丟失的數(shù)據(jù)。
與HTTP/2不同的是其他stream不會因此受到影響。
②連接建立更快：
QUIC內(nèi)部包含了TLS_V1.3，它在數(shù)據(jù)幀中會攜帶TLS里的信息。并且QUIC不需要像HTTP/2通過TCP+TLS握手，它的握手過程僅需要1RTT，握手的目的在于確認(rèn)雙方的連接ID。因此QUIC僅需一個RTT就可以同時完成連接建立與加密密鑰。甚至它在第二次連接時，應(yīng)用數(shù)據(jù)包可以與QUIC握手信息一并發(fā)送，達到0-RTT的效果。
③支持連接遷移：
QUIC協(xié)議沒有用IP地址和端口來確定連接，而是通過連接ID來標(biāo)記通信兩端，即使設(shè)備的網(wǎng)絡(luò)發(fā)生變化后，導(dǎo)致IP地址變化，只要仍保有上下文信息（例如連接ID、TLS信息），就可以無縫復(fù)用原連接。
HTTP 3.0 利用QUIC作為底層支撐協(xié)議，其融合UDP協(xié)議的速度、性能與TCP的安全可靠，解決了HTTP 2.0中引入的一些缺點，優(yōu)化了互聯(lián)網(wǎng)的傳輸體驗。相信在未來HTTP 3.0的時代將會到來！
