HTTP協(xié)議，又叫做超文本傳輸協(xié)議。是一種用于在Web瀏覽器和Web服務(wù)器之間交換數(shù)據(jù)的應(yīng)用層協(xié)議。

HTTP協(xié)議到目前為止，所有的版本可以分為HTTP 0.9、1.0、1.1、2.0、和3.0，其中普遍應(yīng)用的是HTTP 1.1版本，正在推進(jìn)是HTTP 2.0版本，以及未來的HTTP 3.0版本。

HTTP1.0規(guī)定瀏覽器和服務(wù)器保持短連接，瀏覽器每次請求都需要與服務(wù)器建立一個TCP連接。HTTP1.0還規(guī)定下一個請求必須在前一個請求響應(yīng)到達(dá)之前才能發(fā)送，如果前一個請求的響應(yīng)一直不到達(dá)，那么下一個請求就不發(fā)送，后面的請求就都阻塞了，所以HTTP1.0存在請求的隊頭阻塞。HTTP1.0還不支持?jǐn)帱c續(xù)傳，每次都會傳送全部的頁面和數(shù)據(jù)， 在只需要部分?jǐn)?shù)據(jù)的情況下就會浪費多余帶寬。

HTTP 1.1解決了1.0版本存在的問題，它可以保持長連接，避免每次請求都要重復(fù)建立TCP連接，提高了網(wǎng)絡(luò)的利用率。HTTP 1.1 可以使用管道傳輸，支持多個請求同時發(fā)送，但服務(wù)器還是按照順序先回應(yīng)前面的請求，再回應(yīng)后面的請求，如果前面的回應(yīng)特別慢，后面就會有許多請求排隊等著處理。所以，HTTP 1.1 還是存在響應(yīng)的隊頭阻塞問題。另外，HTTP 1.1已經(jīng)可以斷點續(xù)傳。

HTTP  2.0是HTTP協(xié)議的第一個主要修訂版，它與前面的版本用于傳遞數(shù)據(jù)的方法有很大的差異。

HTTP2.0會壓縮頭部，如果同時有多個請求其頭部一樣或相似，那么協(xié)議會消除重復(fù)部分。

HTTP 2.0 將請求和響應(yīng)消息編碼為二進(jìn)制，而不再使用之前的純文本消息，增加了數(shù)據(jù)傳輸?shù)男省?/span>

HTTP 2.0可以在一個TCP連接中并發(fā)多個請求或回應(yīng)，而不用按照順序一一對應(yīng)，從而徹底解決了HTTP層面隊頭阻塞的問題，大幅度提高了連接的利用率。

HTTP 2.0還在一定程度上改善了傳統(tǒng)的請求應(yīng)答工作模式，服務(wù)端不再是被動地響應(yīng)，而是可以主動向客戶端發(fā)送消息、推送額外的資源。

HTTP 2.0雖然通過多個請求復(fù)用一個TCP連接解決了HTTP的隊頭阻塞 ，但是一旦發(fā)生丟包，就會阻塞住所有的HTTP請求，這就屬于TCP層隊頭阻塞。為了解決這個問題，HTTP 3.0直接放棄使用TCP，將傳輸層協(xié)議改成UDP，但是因為UDP是不可靠傳輸，所以這就需要QUIC實現(xiàn)可靠機(jī)制。

QUIC全稱 “快速 UDP 互聯(lián)網(wǎng)連接”，是由Google提出的使用UDP進(jìn)行多路并發(fā)傳輸?shù)膮f(xié)議。

QUIC 有自己的一套機(jī)制可以保證傳輸?shù)目煽啃缘摹．?dāng)某一對請求響應(yīng)發(fā)生丟包時，只會阻塞當(dāng)前的請求響應(yīng)，其他請求響應(yīng)不會受到影響，因此完全不存在隊頭阻塞問題。

HTTP 3 .0使用了UDP作為傳輸層協(xié)議，能夠減少三次握手的時間延遲，從而達(dá)到快速建立連接的效果。此外，QUIC協(xié)議可以使用連接ID來標(biāo)記通信的兩個端點，即使移動設(shè)備的網(wǎng)絡(luò)發(fā)送變化，導(dǎo)致IP地址變化了，只要還有連接ID和TLS密鑰等上下文信息，就可以復(fù)用原連接，從而實現(xiàn)連接遷移。