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

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

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

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

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

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

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

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

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

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

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