QUIC 協定如何運作？
QUIC 是建立在UDP 之上的加密傳輸通訊協定。它的設計結合了 UDP 的速度與 TLS 等通訊協定的安全性，有效地建立快速、安全的網際網路連線。
在傳統通訊協定中，驗證和加密是由較高層級的解決方案（例如TLS）管理，QUIC 則不同，它直接將這些功能整合到傳輸層中。
這使得 QUIC 對於現代網路流量更快速、更有效率。
- 它的工作方式是啟動快速握手程序，使其能快速建立安全連線。
- 握手完成後，QUIC 會同時傳送多個加密資料串流到伺服器，減少延遲並提高效能。
QUIC 將驗證和加密嵌入通訊協定本身，簡化了安全通訊，同時維持 UDP 的輕量優點。
Fast Handshake
握手是每個網路通訊協定的重要部分。QUIC 以 TLS 1.3 握手的認證和加密過程取代TCP中使用的傳統三方握手。
細分而言，典型的 TCP 連線包括
- 用戶端傳送 SYN 封包
- 伺服器回應SYN-ACK 封包
- 用戶端以 ACK 封包結束連線
在傳輸任何資料之前，必須經過這三個步驟。
QUIC 透過 UDP 運作，消除了這項要求。由於 UDP 不需要以相同的方式建立連線，QUIC 可讓資料立即透過 UDP 相容的連結傳送，減少延遲。
在某些情況下，QUIC 可以在第一個連線週期中傳送資料 - 稱為0-RTT（零往返時間）。當伺服器與用戶端有先前快取的連線時，就有可能發生這種情況。不過，雖然 0-RTT 可以提高速度，但它不一定是最安全的選項，如果處理不當，可能會讓資料遭受重播攻擊。
加密機能
除了快速握手之外，QUIC 還引入了內建加密功能。傳統上，在 TCP 上，加密是透過 TLS 通訊協定單獨處理的，它需要自己的握手協商版本和密碼套件。此握手建立了會話所使用的加密演算法和通訊協定。
由於 QUIC 是建基於 UDP，因此它修改了傳統的 TLS 握手方式，以符合其簡化的架構。QUIC 透過傳送包裹在兩個特定元件中的Client Hello (CHLO)來實現此目標：
- 初始封包
- 加密框架
此封裝可將加密握手包含在用戶端傳送的第一個 UDP 資料報中。因此，傳輸和加密握手合併為單一有效的步驟。初始交換之後，QUIC 的行為與 TLS 1.3 相似。
用戶端和伺服器之間的所有後續通訊都會使用握手時的會話金鑰加密。
封包訂購
QUIC 以 UDP 為基礎，此通訊協定以速度著稱，但可靠性卻不高 - 封包可能會被丟棄或不按順序送達。另一方面，TCP 可確保可靠性，但代價是延遲時間的增加。在 TCP 中，如果一個串流發生錯誤，所有來自用戶端的並發串流都會暫停，直到問題解決為止。
QUIC 將資料組織成獨立的串流，並確保每個串流都能維持其內部封包順序，從而在速度與可靠性之間取得平衡。
但是，QUIC 不會強制執行不同串流之間的封包順序。
例如，想像兩個串流 -串流 A和串流 B- 從伺服器傳輸到用戶端。
- 如果來自 StreamA 的封包遺失，Stream A 將獨立處理重新傳輸。
- 碼流 B會繼續不間斷地傳輸，並且可以完成傳輸，而不會受到碼流 A 損失的影響。
與 HTTP/2 等先前的通訊協定相比，這個層級的串流獨立性是一項重要的改進，在 HTTP/2 中，一個串流的封包遺失可能會導致共用相同連線的其他串流停滯不前。
QUIC 協定的挑戰
雖然 QUIC 已經傳輸了 Google 大量的應用程式資料，但其在全球分散環境中的廣泛應用仍然有限。
其中一個主要障礙是網際網路基礎建設的變革速度緩慢。40 多年來，TCP 一直是主要的傳輸層通訊協定，幾乎可以傳輸任何類型的資料。雖然 QUIC 具備明顯的優勢，特別是在減少長距離延遲（例如洲際連線）方面，但相較於 TCP 的多樣性，QUIC 的優點往往被視為範圍狹窄。
Google 已積極推廣 QUIC 的採用，並推進 QUIC 的開發與服務整合。然而，這使得許多企業為了適應標準和趨勢而手忙腳亂。
因此，QUIC 的實施仍然面臨相當大的挑戰，尤其是對於擁有複雜基礎架構、傳統系統或缺乏內部專業知識的組織而言。
0-RTT 的風險
對於快取連線，QUIC 可以在第一次往返時傳送資料 - 稱為0-RTT。雖然此方法可有效消除握手延遲，但卻引入了顯著的安全問題。
其中一個主要風險是缺乏新的加密握手。如果用於快取會話資訊的原始連線遭到洩露，在恢復連線期間傳送的任何應用程式資料也可能暴露。
另一個顧慮涉及重播攻擊。透過 0-RTT 傳送的應用程式資料可能會被路徑上的攻擊者截取，並重複播放多次至同一伺服器。在大多數情況下，加密有助於減緩這類威脅，但 0-RTT 會繞過完全重新協商而削弱這層保護。
因此，雖然 0-RTT 可提供效能優勢，但必須謹慎使用，尤其是在涉及敏感資料或高安全性需求的情況下。
防火牆不相容
從企業安全的角度來看，QUIC 帶來了額外的挑戰 - 特別是對於依賴深度封包檢測和流量解密的組織而言。
其中一個關鍵問題是QUIC 不支援 SSL 解密，而SSL 解密是企業防火牆用來檢查和保護網路流量的常用方法。相反，QUIC 使用自己專有的加密技術。由於它被廣泛部署在 Google 的應用程式套件中，這就造成 IT 團隊在網路可視性和控制上的嚴重盲點。
另一項挑戰在於 QUIC 的設計理念。
Google 所建立的 QUIC 具有彈性且容易更新，有別於僵化老舊的 TCP 基礎架構。雖然這種方法可支援快速創新，但也需要防火牆 和安全工具快速適應通訊協定層級的變更。這種持續更新的需求會對 IT 團隊和基礎架構造成沉重的負擔。
因此，有些防火牆供應商建議完全封鎖 QUIC，直到有更成熟且相容的安全工具為止。從不斷演進的文件到不一致的實施，QUIC 的安全性挑戰持續累積，尤其是對企業環境而言。
利用 Check Point 執行高速網路安全
Check Point Quantum 是業界領先的防火牆，現在支援 QUIC。但Quantum 網路安全提供的遠遠不只是 Google 應用程式的可視性：它提供Check Point的深度威脅感知，以及SandBlast 的零時差保護。 若要瞭解這些尖端威脅，請參閱我們的 2025 年風險報告。
隨需超大規模基礎架構可保持低延遲，並隨組織需求的演進提供無縫可擴展性。 為了提供更好、更清晰的管理，Quantum 提供統一的管理系統，整合網路、雲端及物聯網環境的可視性。
立即開始免費示範，體驗Check Point Quantum 的全部功能。
