一文了解HTTP3.0比HTTP2.0強在哪里

　　首先，我們先來介紹一下HTTP2.0傳輸協(xié)議，HTTP2.0傳輸協(xié)議通過二進制傳輸、多路復用、Header壓縮、Server Push等特性大大地提升了HTTP1.x的性能，但是由于HTTP2.0傳輸協(xié)議是基于TCP協(xié)議實現(xiàn)的，TCP本身特性導致其必然存在一定的瓶頸及缺陷。

　　HTTP2.0缺陷：

　?、貶ead-Of-Line Blocking(隊頭阻塞)：HTTP2.0傳輸協(xié)議多個請求都是在一個TCP連接中進行的，如果TCP傳輸時出現(xiàn)丟包，那么整個TCP就要等待重傳，這樣就會導致該TCP連接中的所有請求被阻塞。舉個例子，見下圖：

　　從上圖可以看到發(fā)送端一共發(fā)送了四包packet，其中packet 3在網絡層丟失了，即使packet4被接收方的內核接收到，但因為在內核中其數(shù)據(jù)并不是連續(xù)的，導致接收端的應用層無法讀取，只有等到packet3重傳后，應用層才可以從內核中讀取數(shù)據(jù)。

　?、赥CP和TLS握手時延：

　　TCP協(xié)議需要通過三次握手來建立TCP連接確保通信的可靠性(1.5個RTT)，TLS_V1.2協(xié)議會在TCP協(xié)議之上通過四次握手建立TSL連接保證通信的安全性(2個RTT)，HTTP協(xié)議會在TCP與TLS上發(fā)送請求并接收響應(1個RTT)。

　　這意味著,假如我們想要訪問美國的服務器，RTT約為250ms時，那么此時HTTPS請求的耗時大概要為1s左右，這就比較高了。

　?、圻B接遷移需要重新連接：

　　一個TCP連接是由源IP地址、源端口、目標IP地址以及目標端口來確定的。這表示如果端口或者IP地址發(fā)生變動，就需要重新讓TCP和TLS進行連接。這不適于設備切換網絡的場景。

　　上面這三個問題其實都是TCP協(xié)議固有的問題，無論HTTP/2應用層怎樣進行設計，都改變不了這些缺陷，要想解決其根本，就需要將傳輸層協(xié)議TCP更換為UDP，而HTTP 3.0就是這樣做的!

　　我們知道UDP是一種簡單、不可靠的傳輸協(xié)議。當然HTTP 3.0也不僅僅只是將傳輸協(xié)議由TCP替換為UDP，它還基于UDP在應用層實現(xiàn)一個叫做QUIC的協(xié)議，這個協(xié)議具有與TCP類似的連接管理、擁塞控制等特性，可以將UDP變得“可靠”。

　　下面介紹QUIC協(xié)議的優(yōu)點：

　?、贌o隊頭阻塞：

　　QUIC使用的傳輸協(xié)議是UDP，其不關心數(shù)據(jù)包的順序或者數(shù)據(jù)包丟失，但是QUIC會保證數(shù)據(jù)包的可靠性，每個數(shù)據(jù)包都會有一個唯一標識，當某個stream的一個數(shù)據(jù)包丟失。這個stream的其他數(shù)據(jù)包即使到達了HTTP，也不會被讀取，直到QUIC重傳丟失的數(shù)據(jù)。

　　與HTTP/2不同的是其他stream不會因此受到影響。

　　②連接建立更快：

　　QUIC內部包含了TLS_V1.3，它在數(shù)據(jù)幀中會攜帶TLS里的信息。并且QUIC不需要像HTTP/2通過TCP+TLS握手，它的握手過程僅需要1RTT，握手的目的在于確認雙方的連接ID。因此QUIC僅需一個RTT就可以同時完成連接建立與加密密鑰。甚至它在第二次連接時，應用數(shù)據(jù)包可以與QUIC握手信息一并發(fā)送，達到0-RTT的效果。

　?、壑С诌B接遷移：

　　QUIC協(xié)議沒有用IP地址和端口來確定連接，而是通過連接ID來標記通信兩端，即使設備的網絡發(fā)生變化后，導致IP地址變化，只要仍保有上下文信息(例如連接ID、TLS信息)，就可以無縫復用原連接。

　　HTTP 3.0 利用QUIC作為底層支撐協(xié)議，其融合UDP協(xié)議的速度、性能與TCP的安全可靠，解決了HTTP 2.0中引入的一些缺點，優(yōu)化了互聯(lián)網的傳輸體驗。相信在未來HTTP 3.0的時代將會到來!