週一，IETF透露它將HTTP-over-QUIC實驗協議重新命名為HTTP / 3。HTTP-over-QUIC是一種HTTP重寫，用TCP替換TCP。

如果這看起來有點為時過早，那麼它與IETF的歷史運作方式並不完全不符。就像TLS 1.3在每個網站甚至已經切換到TLS 1.2之前推出的那樣（儘管到8月份絕大多數都有）並且SHA-3已經建立，儘管幾年前SHA-2開始使用。因此，儘管事實上只有31.2％的前1000萬網站甚至使用HTTP / 2，但HTTP / 3已經出現。

已經有1000萬支援QUIC的1.2％。那是大約120,000個網站。

那麼，什麼是HTTP-over-QUIC - 或者我想現在它是HTTP / 3 - 這個新協議對於 

什麼是HTTP / 3（又名HTTP-over-QUIC）

HTTP-over-QUIC是一種實驗性的Google協議，它是一種HTTP重寫，它在QUIC中交換傳統上位於網際網路核心的標準TCP。

TCP是傳輸控制協議，與IP（網際網路協議）一起，它已成為定義網際網路多年的基本規則之一。它足夠老，它有一個三位數的RFC編號。這是一個IETF的笑話，TCP是在1981年定義的.TCP是一種面向連線的協議，它旨在提供無差錯的資料傳輸，它控制資料如何分解成資料包並傳播到連線的另一端。

不幸的是，無差錯傳輸功能是一把雙刃劍，因為它可以增加連線的延遲。它必須確保它接收每個資料包，並執行校驗和雜湊來驗證這一點。簡而言之，雜湊是一種單向函式，有助於驗證真實性。如果資料全部按預期到達，則校驗和產生的雜湊值將與已知的雜湊值匹配。如果沒有，TCP將使連線另一端的一方再次傳送它。

QUIC是Quick UDP Internet Connections的首字母縮寫。這引出了一個問題，什麼是UDP？UDP是使用者資料協議。解釋這個問題的最好方法是回到我們剛剛與TCP討論過的無差錯傳輸。UDP是另一種連線協議，但它不提供無差錯傳輸。相反，它促進了一種低延遲的連線（由於它容忍一些資料丟失的事實）。

將它應用於現實生活可能會很有啟發性。TCP無處不在，網際網路上的絕大多數流量都是TCP。這非常適合資料保真度很重要的情況。當您在YouTube上看到視訊緩衝，或者在節目載入時您在Netflix上獲得風車 - 這是一個TCP連線。您的裝置基本上是在說“我需要在繼續之前瞭解這些資料。”

在UDP優先的情況下，當您需要傳送恆定的實時資料流時，延遲是不可接受的。一些明顯的背景是IP語音（VoIP），Skype和視訊遊戲網路等視訊訊息應用。在這種情況下，UDP只會在連線另一端的聚會上丟擲一個恆定的資料流，如果有些資料丟失，資料最終會趕上來。這稱為盡力而為。

QUIC是由Google設計的實驗性協議。這可能看起來很奇怪，但谷歌的SPDY最終變成了HTTP / 2，所以這也不是前所未有的。QUIC本質上是谷歌重寫TCP的嘗試，它結合了HTTP / 2，TCP，UDP和傳輸層安全性（TLS）等。目標是讓QUIC替換TCP和UDP。它預設是加密的，這意味著它比它的前輩更快，更安全。這主要是因為它使用TLS 1.3（RFC 8446）並利用其改進的單次往返握手和零往返恢復功能。

來自Google的Chromium部落格：

QUIC的另一個重要收益是改善擁塞控制和丟失恢復。重傳資料包時，不會重複使用資料包序列號。這避免了關於已經接收到哪些分組的模糊性並且避免了可怕的重傳超時。因此，在網路狀況不佳的情況下，QUIC比TCP更勝一籌，為最慢1％的連線縮短了Google搜尋頁面載入時間。對於像YouTube這樣的視訊服務，這些好處更加明顯。使用者在使用QUIC觀看視訊時報告的重建次數減少了30％。這意味著花在盯著微調器上的時間更少，觀看視訊的時間也更多。

雖然最初只有Google的伺服器支援HTTP-over-QUIC，但今年早些時候Facebook也增加了支援。

這對SSL / TLS行業意味著什麼？

就如何與當前的SSL / TLS生態系統一起使用而言，它不會對數字證書的使用產生太大的直接影響，因為TLS在協議中被烘焙，並且身份驗證仍然需要由可信證書處理當局和PKI。

可能來自HTTP / 3的最大好處是，它將迫使網站更快地支援TLS 1.3。

但是，由於不到三分之一的網際網路甚至使用HTTP / 2而且我們仍然有一小部分亂七八糟的人依賴於HTTP（以及一些願意死在那座山上的人），但這仍然可能暫時不會有一段時間。）。

訊息來源：IETF