關於 HTTP/3 您需要了解的內容
快速連結
- 是什麼讓它變得更好？
- 實施困難嗎？
HTTP/3 是下一代 HTTP 協定。它由 QUIC 提供支援，它取代了傳輸層的 TCP，並減少了客戶端建立連線所需的往返次數。
是什麼讓它變得更好？
如果您無法從縮寫「QUIC」中看出，HTTP/3 的速度要快得多。
HTTP 只是 OSI 模型的一部分，它為我們所知的互聯網提供了動力。此模型的每一層都有不同的用途，HTTP 等高階 API 位於最頂層（應用程式層），一直到插入路由器的實體線路和連接：
但這個模型存在一個瓶頸——儘管有新名稱，HTTP 標準本身並不是問題。
TCP（傳輸層）是這裡的罪魁禍首；它是在 70 年代設計的，因此不能很好地處理即時通訊。 HTTP-over-TCP 已達到其極限。谷歌和科技領域的其他公司一直在研究 TCP 的替代品。
2012 年，Google 創建了 SPDY，這是一種建立在 TCP 之上的協議，修復了許多常見問題。 SPDY 本身已被棄用，但它的一部分進入了 HTTP/2，目前有 40% 的網路使用 HTTP/2。
QUIC 是一個新標準，很像 SPDY，但它是建立在 UDP 而不是 TCP 之上的。 UDP 比 TCP 快得多，但通常不太可靠，因為它不具有與 TCP 相同的錯誤檢查和遺失防護功能。它通常用於不需要資料包完全正確的順序，但關心延遲的應用程式（例如即時視訊通話）。
QUIC 仍然可靠，但它在 UDP 之上實現錯誤檢查和可靠性，因此它充分利用了兩種協定的優點。當使用者第一次連線到啟用 QUIC 的網站時，他們將透過 TCP 進行連線。
QUIC 解決的 TCP 的主要問題是隊頭阻塞。一旦伺服器和客戶端之間建立連接，伺服器就會向客戶端發送資料包。如果連接不好並且丟失了一個資料包，則客戶端將保留此後收到的所有資料包，直到伺服器重新傳輸丟失的資料包。 HTTP/2 透過允許在同一個 TCP 連線上進行多次傳輸，在一定程度上解決了這個問題，但它並不完美，實際上可能比具有高遺失連線的 HTTP/1 慢。
QUIC 解決了這個問題，並且更好地處理高損耗連接。 Google 的早期測試顯示，在高延遲場景中，影片緩衝效能提高了約 15%，行動連線的影片緩衝效能提高了 30%。由於 QUIC 減少了必須進行的握手次數，因此延遲將得到全面改善。
實施困難嗎？
雖然 QUIC 是一個新標準，但它建立在 UDP 之上，而 UDP 幾乎已在所有地方得到支援。它不需要任何新的核心更新，這可能會給伺服器帶來問題。 QUIC 應該可以在任何支援 UDP 的系統上開箱即用
一旦 HTTP-over-QUIC 可用，它就應該成為 HTTP-over-TCP 的直接替代品。在撰寫本文時，Chrome 已支援 QUIC，但預設為停用。您可以透過以下方式啟用它進行測試：
chrome://flags並開啟「實驗性 QUIC 協定」標誌。 Firefox 將在今年秋天晚些時候添加支持，隨著 Edge 遷移到 Chromium，它們也將很快獲得支援。
在伺服器端，如果您使用 CloudFlare 作為 CDN，您將能夠啟用儀表板中已有的選項，儘管在行動瀏覽器預設啟用它之前，您不會有許多用戶端實際使用它。 Fastly 正在積極提供支援。如果您想在您的 Web 伺服器上啟用它，則需要稍等一下——對 QUIC 的早期支援預計會在 nginx 1.17 開發週期內實現，但目前還看不到對 Apache 的支援。
一旦 nginx 和 Apache 更新為支援它，將 QUIC 添加到您的網頁或 Web 應用程式將就像更新您的 Web 伺服器並啟用該選項一樣簡單。您無需對應用程式或程式碼進行任何更改，因為一切都是在基礎設施層級處理的。目前還沒有，但很快就會推出，一旦默認支持，您肯定會想要啟用它。