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

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

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

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

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

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

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

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

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

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

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

QUIC 有自己的一套機制可以保證傳輸?shù)目煽啃缘摹．斈骋粚φ埱箜憫l(fā)生丟包時，只會阻塞當前的請求響應，其他請求響應不會受到影響，因此完全不存在隊頭阻塞問題。

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