HTTP協議，又稱為超文本傳輸協定。是一種用於在網頁瀏覽器和網頁伺服器之間交換資料的應用層協定。

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

HTTP1.0規定瀏覽器和伺服器保持短連接，瀏覽器每次要求都需要與伺服器建立TCP連接。HTTP1.0也規定下一個請求必須在前一個請求回應到達之前才能發送，如果前一個請求的回應一直不到達，那麼下一個請求就不發送，後面的請求就都阻塞了，所以HTTP1.0存在請求的隊頭阻塞。HTTP1.0還不支援斷點續傳，每次都會傳送全部的頁面和數據， 在只需要部分數據的情況下就會浪費多餘頻寬。

HTTP 1.1解決了1.0版本存在的問題，它可以保持長連接，避免每次請求都要重複建立TCP連接，提高了網路的使用率。HTTP 1.1 可以使用管道傳輸，支援多個請求同時發送，但伺服器還是按照順序先回應前面的請求，再回應後面的請求，如果前面的回應特別慢，後面就會有許多請求排隊等著處理。所以，HTTP 1.1 還是有反應的隊頭阻塞問題。另外，HTTP 1.1已經可以斷點續傳。

HTTP 2.0是HTTP協定的第一個主要修訂版，它與前面的版本用於傳遞資料的方法有很大的差異。

HTTP2.0會壓縮頭部，如果同時有多個請求其頭部一樣或相似，則協定會消除重複部分。

HTTP 2.0 將請求和回應訊息編碼為二進制，而不再使用先前的純文字訊息，增加了資料傳輸的效率。

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

HTTP 2.0也在一定程度上改善了傳統的請求應答工作模式，服務端不再是被動地回應，而是可以主動向客戶端發送訊息、推送額外的資源。

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

QUIC全名為“快速UDP 網路連線”，是由Google提出的使用UDP進行多路並發傳輸的協定。

QUIC 有自己的一套機制可以確保傳輸的可靠性的。當某一對請求回應發生丟包時，只會阻塞目前的請求回應，其他請求回應不會受到影響，因此完全不存在隊頭阻塞問題。

HTTP 3 .0使用了UDP作為傳輸層協議，能夠減少三次握手的時間延遲，從而達到快速建立連接的效果。此外，QUIC協定可以使用連接ID來標記通訊的兩個端點，即使行動裝置的網路發送變化，導致IP位址變化了，只要還有連接ID和TLS金鑰等上下文訊息，就可以重複使用原連接，從而實現連接遷移。