引言
在過去的三十年裏，HTTP（超文本傳輸協議）一直是互聯網的支柱。我們可以通過 HTTP 瀏覽網頁、下載文件、流式傳輸電影等。這一協議隨着時間的推移已經得到了重大改進。
HTTP 協議是一個應用層協議，它基於 TCP（傳輸控制協議）工作。TCP 協議有若干限制，導致 Web 應用響應較慢。
谷歌開發了一種名為 QUIC 的顛覆性傳輸協議，以克服 TCP 的缺點。QUIC 幾年前被標準化，並加入到了 IETF（互聯網工程任務組）。
近幾年來，採用 QUIC 的公司數量呈指數增長。大多數技術公司，如谷歌、Facebook、Pinterest 等，已經開始採用在傳輸層使用 QUIC 的 HTTP/3.0。這些公司已經看到了其網站在使用 HTTP/3.0 和 QUIC 後性能的顯著提升。
讓我們開始我們的旅程，瞭解 QUIC 將如何取代 TCP。我們首先將瞭解 TCP 和 UDP 的一些基本網絡概念。之後，我們將回顧 HTTP 的發展歷程，以及每個版本是如何克服前一版本的限制的。然後我們將看看 QUIC 是什麼，以及它是如何工作的。我們將探討為什麼 QUIC 比 TCP 具有更高的性能。
TCP 和 UDP 是如何工作的？
TCP（傳輸控制協議）和 UDP（用户數據報協議）是傳輸層協議。這些協議管理着來自任何電子設備的網絡數據包的流動。讓我們詳細瞭解這兩種協議是如何工作的。
TCP
TCP 是一種基於連接的協議。客户端與服務器建立連接後發送數據。TCP 連接通過一種稱為三次握手的機制建立。下圖説明了三次握手過程：
TCP 三次握手過程
該過程包括三個步驟：
- SYN - 客户端向服務器發送一個 SYN 數據包。
- ACK - 收到 SYN 後，服務器通過 ACK 數據包向客户端發送確認。
- SYN-ACK - 客户端收到服務器的 ACK 數據包後，最終通過 SYN-ACK 向服務器發送確認。
TCP 是一種有狀態且可靠的協議。它保證了一台設備到另一台設備的所有數據包的傳遞。此外，它允許客户端和服務器使用同一個連接進行通信。
UDP
UDP 是一種無連接協議。與 TCP 不同，客户端與服務器之間沒有三次握手。客户端發送數據包給服務器，不等待服務器的確認。
UDP 不保證 100% 的數據包傳遞。數據包可能會丟失，可能不會到達另一台設備。UDP 不像 TCP 那樣可靠。
由於沒有初始握手，UDP 比 TCP 快得多。出於性能考慮，UDP 主要用於流數據的應用，如音樂/視頻。
TCP 與 UDP 對比模因
到目前為止，我們已經瞭解了 TCP 和 UDP 協議的工作原理。現在讓我們探索 HTTP 協議，它是一個應用層協議。
HTTP 的發展歷史
HTTP 的第一個版本是 1989 年由 Tim Berners-Lee 在 CERN 開發的。從那時起，這個協議經歷了多次優化和性能改進。大多數現代設備使用 HTTP 1.1/HTTP 2.0 和 HTTP 3.0。我們將回顧 HTTP 的歷史，並瞭解該協議經歷的主要變化。
HTTP/1.0
在最初的 HTTP/0.9 版本之後，HTTP/1.0 開始支持頭部、請求體、txt 文件等。客户端每次從服務器獲取數據時必須創建一個 TCP 連接。這導致了建立連接的資源大量浪費。
HTTP/1.1
此協議增加了在客户端和服務器之間重用現有 TCP 連接來獲取新數據的支持。這是通過 HTTP 頭 部的 keep-alive實現的。
如果客户端想要獲取 10 個 Javascript 文件，則它會與服務器建立一次連接。然後，它會重用同一連接並獲取這 10 個文件，而不是為每個文件創建一個新連接。
這減少了資源浪費並改善了性能，因為它避免了創建冗餘連接。然而，一個主要的缺點是稱為隊頭阻塞的問題。
讓我們通過一個例子來理解這個概念。如上圖所示，你有三個文件——圖片、文本和視頻。視頻文件的大小較大，傳輸所需時間更長。由於視頻文件需要更長時間，它將阻止圖像和文本文件的發送。
HTTP/2.0
HTTP 2.0 通過多路複用解決了 隊頭阻塞 問題。通過多路複用，多個文件可以通過同一個 TCP 連接發送。
這結果提升了性能並在應用層解決了隊頭阻塞問題。然而，在 TCP 層面，如果發生數據包丟失，則必須等待數據包重傳。
多路複用解決方案在數據包丟失的情況下並未像預期那樣工作。事實上，如果數據包丟失超過 5%，HTTP 1.1 的表現會優於 HTTP 2.0。隊頭阻塞問題從應用層轉移到了傳輸層。
下圖説明了單個數據包丟失導致多個流延遲的情況：
當一個數據包丟失時，TCP 會將後續數據包存儲在其緩衝區中，直到收到丟失的數據包。然後，TCP 使用重傳來獲取丟失的數據包。HTTP 無法看到 TCP 的重傳。因此，在這種情況下，不同的流會看到傳輸的延遲。
什麼是 QUIC？
在過去的幾節中，我們看到 TCP 有一些固有的限制，例如三次握手和隊頭阻塞。這些限制可以通過增強 TCP 或用新協議替換 TCP 來解決。
儘管增強 TCP 聽起來很簡單，但 TCP 存在於與操作系統緊密結合的最底層。簡單來説，TCP 的代碼存在於內核層而不是用户空間。考慮到龐大的設備數量，要在內核空間實施更改可能需要很長時間才能影響到所有用户。
因此，谷歌提出了一種新的協議 QUIC，作為 TCP 的替代品。與 TCP 一樣，QUIC 也是一個傳輸層協議。然而，它位於用户空間而不是內核空間。這使得它比 TCP 更容易更改和增強。
QUIC 基於 UDP 工作。它通過使用 UDP 來克服 TCP 的限制。它只是在 UDP 之上增加了一個層或包裝器。這個包裝器添加了 TCP 的特性，如擁塞控制、數據包重傳、多路複用等。它內部使用 UDP，並在其上添加了 TCP 的最佳特性。
既然我們現在瞭解了 QUIC 的基本知識，讓我們深入瞭解這個協議的工作方式。
QUIC 是如何工作的？
QUIC 握手
QUIC 基於 UDP，並且無需經歷三次握手過程。三次握手過程增加了額外的開銷並增加了延遲。因此，QUIC 通過減少連接延遲來提高性能。
在 TCP 的情況下，用於 TLS 的額外握手也會增加延遲。QUIC 在單個調用中結合了 TLS 握手和 QUIC 握手。通過優化握手過程，它提高了性能。
可靠性
你可能會想：“既然 QUIC 基於 UDP，數據包會不會丟失呢？”答案是否定的。QUIC 在 UDP 堆棧上增加了可靠性。例如，如果服務器沒有從客户端收到第 5 個數據包，協議將檢測到這一點，服務器將要求客户端重新發送相同的數據包。
多路複用
與 TCP 類似，QUIC 也實現了多路複用。客户端可以同時使用單個通道傳輸多個文件。QUIC 為每個流（傳輸的文件）創建一個 UUID。它使用 UUID 來識別流。然後，多個流通過一個單一通道發送。
下圖説明了 QUIC 中多路複用的工作機制：
QUIC 中的多路複用
QUIC 通過其多路複用也解決了 TCP 面臨的隊頭阻塞問題。如果一個流遭受數據包丟失，僅該流會受到影響。QUIC 中的流是獨立的，不會相互影響。
安全性
此外，QUIC 還支持 TLS 1.3（傳輸層安全）。這保證了數據的安全性和保密性。TLS 加密了 QUIC 協議的大部分，如數據包編號和連接關閉信號。
為什麼選擇 QUIC？
- 減少延遲 - 通過結合 TLS 握手和連接設置，QUIC 最小化了延遲。這也被稱為 0-RTT（零延遲請求）。它結果在更快的連接建立和提高了 Web 應用的性能。
- 多路複用 - 通過多路複用，QUIC 可以通過單一通道發送多個數據流。這對下載多個文件（如圖片、JavaScript、CSS 等）的客户端應用程序非常有幫助。
- 連接遷移 - 使用 QUIC，您可以在不中斷的情況下從一個網絡接口切換到另一個（例如從 WiFi 切換到移動數據）。這對移動設備來説很重要，提升了用户體驗。
- 提升安全性 - QUIC 運作於 TLS 1.3 之上，提供更好的安全性。此外，它還加密了協議的大部分內容，與僅加密 HTTP 負載的 TCP+TLS 相比，它對安全攻擊具有更高的抵抗力。
- 廣泛支持 - 自從它推出以來，它的採納率一直在增長。這進一步加強了其有效性。
HTTP/3 和 QUIC
HTTP/3 是超文本傳輸協議（HTTP）的最新版本。它在內部使用 QUIC 而不是 TCP。它旨在為現代 Web 提供一個更高效和安全的基礎。它具有 QUIC 提供的所有好處。
HTTP/3 由 IETF 標準化。今天，大部分互聯網流量都依賴於 HTTP/3。
從上圖可以看出，採用率飆升至 30%，並且正逐漸超過 HTTP/1.1。隨着採用率的增長，HTTP/3.0 將在未來幾年逐漸超過 HTTP/2.0。
結論
自 HTTP 三十年前問世以來，互聯網已經取得了長足的進步。HTTP的演進使在線體驗變得更加高效和響應迅速。隨着現代應用的不斷增長需求，我們意識到了底層協議如 TCP 的固有限制。
Google 開發了變革性的協議 QUIC。它利用 UDP 並解決了 TCP 的所有缺陷。減少延遲、多路複用、增強安全性和連接遷移是 QUIC 的一些顯著特徵。QUIC 帶來的創新解決了隊頭阻塞等問題。
像谷歌和 Facebook 這樣的大型技術公司通過在 HTTP/3 中採用 QUIC，看到了性能的顯著提升。隨着採用率的上升和支持的增加，HTTP/3 將成為互聯網通信的標準。在未來幾年內，互聯網將演變並過渡到 HTTP/3，以實現更高的效率、可靠性和性能。
- 源於：https://engineeringatscale.substack.com/p/how-quic-is-displac...
