傳輸層很牛逼的協議：QUIC，速度真的槓槓的！

QUIC 是一項由 Google 設計的協議，致力於將網絡通信變得更快、更高效。它代表了對網絡性能的追求，旨在提供更好的用戶體驗，但與此同時，QUIC 也帶來了一系列網絡安全和監控方面的挑戰。

在當今數字化世界中，網絡速度是一切的關鍵。谷歌一直在努力提高網絡效率和性能，而 QUIC 協議正是這個使命的一部分。然而，隨着 QUIC 的廣泛採用，一些安全問題浮出水面，這引發了對網絡安全和監控的重大關切。尤其令人擔憂的是，大多數傳統防火牆和網絡設備難以有效處理 QUIC 流量，導致了網絡安全中的一道薄弱環節。

本文將深入探討 QUIC 的工作原理，以及它如何改善網絡性能。同時，我們將審視 QUIC 對網絡安全和監控的影響，以及如何解決與 QUIC 相關的挑戰，以確保網絡仍然安全可靠。在數字時代，我們必須在速度和安全之間取得平衡，QUIC 協議的崛起將迫使我們重新思考這個平衡。

讓我們直接開始今天的科普！

目錄：

一、背景

QUIC 協議的背景可以追溯到 Google 的 gQUIC 實驗，這個實驗最初旨在進一步改進 HTTP/2 的性能，並將這種性能擴展到網絡的安全層和傳輸層。這一實驗代表了一項大膽而值得讚賞的嘗試，因爲其目標是替換傳統的 HTTP 協議。2013 年，gQUIC 的首個部分開始在 Google 的服務器和 Chrome 瀏覽器之間傳輸實時數據。Google 通過 gQUIC 協議將各種 Google 服務的實時流量傳送到 Chrome 客戶端，隨着 Google 服務從中受益，gQUIC 的應用逐漸增加。

這一早期實驗的數據後來被證明對 QUIC 協議的設計和發展具有重要意義。然而，值得注意的是，早期的 gQUIC 實驗中包含了兩個關鍵的技術組件，後來通過迭代被移除：

  1. 前向糾錯 (FEC)： 這個功能最初採用了一種奇偶校驗的方案，但它在靈活性和可實施性方面存在問題，因此無法滿足不同需求。奇偶校驗的方案被認爲效果不佳，而且該功能的維護成本遠高於其潛在好處。

  2. ACK 熵： 這一功能旨在保護髮送方免受 ACK 欺騙攻擊的影響。由於所有的流量都已加密，任何 ACK 信息必須由連接的一方發送。然而，後來刪除了 ACK 熵功能，因爲它所防範的攻擊影響相對有限，並且引入了複雜的代碼和協議層面的問題。

這兩個功能的去除反映出協議設計中過早的優化，隨着協議的發展，這些功能變成了維護的負擔，當維護成本超過潛在收益時，就被移除了。

二、什麼是 QUIC？

QUIC（Quick UDP Internet Connections）是一種由 Google 開發的協議，旨在改善網絡連接的速度和可靠性。它的目標是替代當前互聯網基礎設施中使用的傳輸控制協議（TCP），並構建在用戶數據報協議（UDP）之上。

QUIC 採用了加密和多路複用的技術，以提供更高的安全性和更快的數據傳輸速度。它允許通過單個連接傳輸多個數據流，從而減少延遲並提高數據吞吐量。此外，QUIC 還包括擁塞控制和流量控制等功能，用於管理網絡擁塞情況，確保數據傳輸的順暢性。

互聯網工程任務組（IETF）目前正在對 QUIC 進行標準化，主要的 Web 瀏覽器和服務器也在逐漸採用這一協議。與傳統的 TCP 協議相比，QUIC 已經被證明可以顯著減少網頁加載時間和連接斷開的問題，尤其在高延遲和不穩定的網絡環境中表現出色，如移動網絡。QUIC 的發展旨在進一步提高互聯網連接的性能和安全性。

從上圖可以看出：

QUIC = HTTP/2 + TLS + UDP

而

UDP + QUIC = 傳輸層

QUIC，你就記住兩個核心：採用 UDP 傳輸層、使用 TLS 1.3 協議

採用 UDP 傳輸層： QUIC 使用 UDP（用戶數據報協議）作爲傳輸層協議，與傳統的 TCP 相比，UDP 減少了連接建立的延遲。TCP 需要經歷三次握手來建立連接，這會引入 1 個往返時間（1-RTT）的延遲。相比之下，QUIC 的 UDP 傳輸層減少了這個握手過程，從而減少了建立連接的時間。這有助於提高網絡通信的效率，尤其是對於那些對延遲要求較高的應用程序。

使用 TLS 1.3 協議： QUIC 集成了 TLS（傳輸層安全性）協議的最新版本，即 TLS 1.3。TLS 1.3 具有改進的安全性和性能特性，其中一個顯著的特點是支持 1-RTT 和 0-RTT 握手。傳統的 TLS 握手需要多個往返時間（RTT），而 QUIC 協議通過 TLS 1.3 允許客戶端在 TLS 握手完成之前發送應用程序數據。這意味着在第一次握手時需要 1-RTT，但之後，已建立連接的客戶端可以使用緩存的信息來快速恢復 TLS 連接，只需 0-1 RTT。這顯著減少了建立連接的時間，使數據能夠更快地傳輸，特別是對於重複連接的情況。

HTTPS TLS 流量與 QUIC 抓包分析

三、QUIC 的發展歷程

2012 年：QUIC 的提出

QUIC 協議最早由 Google 公司於 2012 年提出。它的初衷是改進互聯網通信的性能，特別是 Web 頁面加載速度，通過減少傳統 TCP 協議中的握手延遲等問題來實現這一目標。

2016 年：IETF 開始標準化 QUIC

在 2016 年，互聯網工程任務組（IETF）開始正式着手標準化 QUIC 協議。這標誌着 QUIC 進入了一個更廣泛的開放標準化過程，旨在確保該協議能夠被廣泛採用並具有互操作性。

2017 年：gQUIC 的部署

在 2017 年，Google 公司開發並部署了 QUIC 協議的初始設計，稱爲 gQUIC。這是 QUIC 的一個重要里程碑，標誌着其在實際網絡環境中的初步應用和測試。

2021 年：RFC900 發佈，QUIC 正式標準化

QUIC 協議的正式標準化版本，即 RFC900，於 2021 年發佈。這一標準化版本的發佈證實了 QUIC 作爲一種新的傳輸層協議的地位，使其能夠在更廣泛的網絡環境中得以應用和推廣。

說到底：QUIC 本質上是基於 HTTP/2 構建的，但具有更快的連接建立和多路複用。它旨在減少延遲，提高性能，並更好地適應現代網絡。

四、QUIC 協議的基本功能

QUIC 協議的基本功能包括：

  1. 獨立的邏輯流： QUIC 允許在單個連接上並行傳輸多個邏輯數據流。每個數據流都是獨立管理的，這意味着一個數據流的延遲或中斷不會影響其他數據流的傳輸。這有助於提高網絡效率，特別是在處理多個請求和響應時。

  2. 一致的安全性： QUIC 提供端到端的安全性，所有數據在傳輸過程中都經過加密。默認情況下，QUIC 使用 TLS 1.3 來建立安全連接，確保數據的機密性和完整性。這有助於保護通信免受竊聽和篡改。

  3. 低延遲： QUIC 旨在減少網絡通信的延遲。它採用快速的連接建立過程，減少了握手時間，並通過多路複用和快速重傳等機制降低了數據傳輸的延遲。這對於實時應用程序和減少頁面加載時間非常重要。

  4. 可靠性： QUIC 提供可靠的數據傳輸，確保數據的完整性和準確性。它具有丟包恢復和重傳機制，以應對網絡中可能發生的數據包丟失或損壞情況。這有助於防止數據損壞和丟失。

  5. 避免 HOL（Head-of-Line）阻塞： QUIC 通過允許多個數據流在單個連接上獨立傳輸，解決了 HOL 阻塞問題。這意味着即使一個數據流遇到問題，其他數據流仍然可以繼續傳輸，而不會受到影響。這有助於提高整體效率和性能。

多路傳輸

五、QUIC 協議的核心特性

QUIC 協議大概包含三大特性：

5.1 0-RTT 連接建立

5.2 無隊頭阻塞的多路複用

隊頭阻塞

5.3 無歧義重傳

六、QUIC 數據包

QUIC 數據包由兩個主要部分組成：頭部（Header）和數據（Data）。

以下是這兩個部分的詳細說明：

6.1 頭部（Header）

6.2 數據（Data）

6.3 一些常見的數據幀類型

  1. PING 幀： 用於測試連接的可用性。PING 幀不包含負載，只是用於確認連接是否存活。

  2. ACK 幀： 用於確認收到的數據包。它包含有關已收到的數據包的信息，以確保數據的可靠傳輸。

  3. RESET_STREAM 幀： 用於重置特定數據流的狀態。當一個數據流需要被中斷或重新開始時，可以使用 RESET_STREAM 幀。

  4. STOP_SENDING 幀： 用於停止向特定的數據流發送數據。這可以用於暫停數據傳輸或處理異常情況。

  5. CRYPTO 幀： 用於傳輸加密數據。在 QUIC 中，加密通常是在連接建立過程中進行的，CRYPTO 幀用於在已建立的連接上傳輸加密的應用層數據。

  6. STREAM 幀： 用於傳輸普通數據流。STREAM 幀可以包含應用層數據，用於在連接上進行雙向通信，支持多路複用。

七、QUIC 協議優勢

7.1 減少連接時間

QUIC 協議通過一次握手來替代傳統的 TCP 和 TLS 握手，從而顯著減少了建立連接所需的時間。這對需要快速在線服務的應用程序和服務非常重要。

7.2 處理數據包丟失

在 TCP 上使用 HTTP/2 時，可能會受到隊頭阻塞的影響，這意味着一個數據包的丟失會導致後續數據包被阻塞。QUIC 通過允許數據流獨立到達目的地來解決了這個問題，提高了連接的性能和可靠性。

7.3 穩定的連接

QUIC 支持連接遷移，允許在網絡發生變化時保持連接的穩定性。即使 IP 地址發生變化，也可以重新建立連接，而不需要完全重新建立連接。

7.4 靈活性和開發容易

QUIC 協議在應用程序級別實現，而不是在操作系統內核中，這使得它更加靈活和容易進行改進和開發。開發人員可以更容易地控制和定製協議的行爲。

八、QUIC 協議的缺點

8.1 增加了遭受攻擊的脆弱性

QUIC 協議更容易受到分佈式拒絕服務（DDoS）攻擊的威脅。因爲它是無連接的，不需要像 TCP 那樣進行三次握手，攻擊者更容易發起反射和放大攻擊，通過僞造源 IP 地址來淹沒目標服務器，使其不可用。QUIC 的無連接性使其更難以進行流量控制和訪問控制，從而增加了 DDoS 攻擊的可能性。

8.2 兼容性問題

QUIC 協議相對較新，可能與某些舊設備、網絡設備或防火牆不兼容。一些應用程序需要精確控制網絡行爲，而 QUIC 的新特性可能不適用於所有用例。因此，在部署 QUIC 時，需要考慮與現有基礎設施和設備的兼容性問題。

8.3 傳輸速率較低

儘管 QUIC 被設計爲提供更快速和高效的數據傳輸，但它的傳輸速率可能受到加密和身份驗證機制的影響。QUIC 在數據包傳輸方面增加了額外的開銷，這可能導致較小數據包的傳輸速率較低，尤其是在高延遲網絡中。

8.4 故障排除困難

與 TCP 相比，使用 QUIC 進行網絡故障排除可能更加複雜。由於 QUIC 的加密和身份驗證功能，診斷與數據包丟失、網絡擁塞或性能問題相關的問題可能需要更高級的網絡監控工具和專業知識。解決問題的難度可能增加，因爲數據包內容和流量可能不可見。

8.5 需要保持最新狀態

QUIC 仍然處於不斷髮展和演進的階段，因此可能會發生協議規範的更改和更新。使用 QUIC 的組織需要及時瞭解最新的開發和更新，以確保協議的實現始終保持最新狀態，以獲得最佳性能和安全性。

九、QUIC 協議應用場景

9.1 實時 Web 和移動應用程序

實時通信應用程序，如視頻通話、語音聊天和即時消息，需要低延遲和可靠的數據傳輸。QUIC 通過獨立的流和擁塞控制機制，提供了快速且高效的數據傳輸，適用於這些應用。

9.2 物聯網設備通信

物聯網設備通常在受限的網絡環境中運行，使用 TCP 或 MQTT 等傳輸協議可能導致高延遲和數據包丟失。QUIC 在高延遲和丟包的網絡條件下表現出色，因此適用於與物聯網設備的通信，提供可靠和高效的替代方案。

9.3 車聯網和聯網汽車

車聯網生態系統需要實時的數據交換，以提供車輛跟蹤、交通管理和安全功能。QUIC 的低延遲、多路複用和數據包恢復能力有助於確保車輛和基礎設施之間的可靠通信，並提高車聯網系統的性能。

9.4 雲計算

雲計算涉及通過互聯網交付計算資源。QUIC 可以提供低延遲和端到端加密，從而改善雲應用程序的用戶體驗和安全性。

9.5 支付和電子商務應用程序

支付和電子商務應用程序需要安全可靠的數據傳輸，以保護用戶的敏感信息。QUIC 通過使用 TLS 加密和可靠的 HTTP3 流，爲這些應用程序提供了更高的安全性和性能，同時提高了用戶體驗。

十、誰在使用 QUIC？

QUIC（快速 UDP 互聯網連接）協議作爲一種通用傳輸協議，正在逐漸改變互聯網通信的方式。雖然它可以用於多種互聯網工作流程，但目前最顯著的採用領域之一是基於 HTTPS 的 Web 瀏覽。讓我們看看誰正在使用 QUIC 以及它的採用情況。

10.1 QUIC 協議與 Web 瀏覽

QUIC 最顯著的應用之一是通過將 Web 瀏覽轉移到 QUIC 來實現基於 HTTPS 的連接。然而，要使用 QUIC，客戶端和服務器都需要支持該協議。這一點在廣泛採用中可能構成一定的障礙，因爲目前只有少數網站已經遷移到使用 HTTP/3，而 HTTP/3 是 QUIC 的後繼者。

10.2 主要採用者

儘管 QUIC 的採用還在增長，但已經有一些主要的互聯網巨頭開始採用該協議。以下是一些主要的 QUIC 採用者：

  1. Google： 作爲 QUIC 的創建者，Google 是第一個採用該協議的大公司之一。在 Google 生態系統中，包括服務器、應用程序、服務和客戶端，QUIC 的部署相對容易。例如，Google 將其視頻平臺 YouTube 的 30% 流量遷移到了 QUIC 上。

  1. Facebook： Facebook 已將超過 75% 的流量遷移到 QUIC。Facebook 和 Instagram 的移動應用程序也充分利用了 QUIC 的性能優勢。

  1. 微軟： 儘管微軟的採用程度相對較低，但它正在考慮將其 VPN 產品從 TCP 轉向 QUIC，這表明微軟也在積極探索 QUIC 的潛力。

10.3 當前的生態系統

QUIC 的支持生態系統在不斷增長，包括瀏覽器、應用程序、服務器、CDN、Web 服務器、負載均衡器、社區項目和編程語言。以下是一些支持 QUIC 的關鍵組成部分：

總結一下本文，QUIC 協議優勢很明顯，但是目前來說不太成熟，希望 QUIC 協議能夠越來越完善、越來越安全，使用率越來越高！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/syhVQ2Y89hNUfanGZZCVnA

猜你喜歡