谷歌的QUIC協議會取代TCP嗎？ - levelup

在過去幾年中，QUIC 已成為 Google 服務網路通訊的預設協議。從 Chrome 網路瀏覽器到 Google 伺服器的所有連線中，有一半以上使用 QUIC。Microsoft Edge、Firefox 和 Opera 也正式支援它。

谷歌在開發它時考慮到了網路安全，並用更先進和最新的技術取代了幾個過時的標準。換句話說，QUIC 可能代表了網際網路的未來，這就是理解它如此重要的原因。

那麼，讓我們深入瞭解 Google 的 QUIC 協議，並介紹您需要了解的所有相關資訊。

QUIC的歷史

QUIC 最初代表“ Quick UDP Internet Connections”，儘管該術語不再用作首字母縮寫詞。現在，“QUIC”用於描述谷歌設計的通用傳輸層網路協議。

• 2012年，最初實施部署。
• 2013 年，隨著IETF會議上實驗範圍的擴大，它被公開宣佈。
• 2015 年 6 月，針對其規範的Internet 草案提交給 IETF 以進行標準化。
• 2016年，QUIC工作組成立。
• 2018 年 10 月，基於 QUIC 的 HTTP 對映開始被稱為“ HTTP/3 ”，使得 QUIC 勢必成為全球標準。
• 2021 年 5 月，IETF 終於在RFC 9000 中對其進行了標準化。

什麼是QUIC？

Google 的 QUIC 是一種基於 UDP 的低延遲網際網路傳輸協議，該協議常用於遊戲、流媒體和 VoIP 服務。[…]UDP 比 TCP 輕得多，但作為回報，它提供的糾錯服務比 TCP 少得多。[…]通過 QUIC，Google 旨在將 UDP 和 TCP 的一些最佳功能與現代安全工具相結合。—谷歌希望通過其 QUIC 協議加速網路

QUIC 與 TCP

與TCP不同的是，QUIC 協議只允許以加密形式進行通訊。由於 QUIC 中未加密的通訊形式被設計禁止，隱私和安全本質上是 QUIC 資料傳輸的一部分。這在網路安全方面絕對是一個加分項，但在不嚴格要求加密時也可能代表無用的開銷。

但真正的突破在於與 TCP + TLS相比，QUIC 建立安全連線所需的時間。換句話說，QUIC 的主要目標是大大減少連線建立期間的開銷。

這要歸功於 QUIC 的設計方式。事實上，QUIC 使交換配置金鑰和支援的協議成為初始握手過程的一部分。具體來說，當傳送方開啟連線時，響應資料包中還包含以後需要使用加密的資料包所需的資料。此步驟無需建立 TCP 連線，然後通過其他資料包協商安全協議。這會導致更高的連線速度和響應的顯著下降，甚至在主機間重新連線期間下降到 0ms，這稱為“零 RTT 連線建立”。

如您所見，典型的安全 TCP 連線需要兩到三趟往返，然後傳送方才能真正開始接收資料。這可能需要長達 300 毫秒的時間。通過使用 QUIC，傳送方可以立即開始與之前已經與之交談過的接收方交談。

與UPD相比，QUIC 成為贏家，因為它具有一些 TCP 功能，例如UPD 沒有的擁塞控制和自動重傳。這使得它本質上比純 UDP 更可靠。詳細地說，QUIC雖然使用UDP作為基礎，但它涉及丟失恢復。這是因為 QUIC 的行為類似於 TCP，並在資料丟失時單獨檢查每個流重新傳輸資料。

此外，如果一個流發生錯誤，QUIC 可以繼續獨立地為其他流服務。此功能對於提高易出錯鏈路的效能非常有用，因為在 TCP 通知丟失或丟失的資料包之前可能會收到大量額外的資料。在 QUIC 中，可以在修復流的同時自由處理這些資料。

QUIC 還提高了網路切換事件期間的效能，例如當移動裝置使用者從 Wi-Fi 網路移動到行動網路時。當同樣的事情通過 TCP 發生時，將執行一個漫長的過程，其中每個現有連線一次斷開一個，然後按需重新建立。為了解決這個問題及其在效能方面的後果，QUIC 包含一個連線 ID 到接收器，而不管來源如何。這允許通過重新傳送單個資料包來重新建立連線，該資料包始終包含此 ID，即使傳送方的 IP 地址已更改，接收方也將認為該資料包有效。

那麼，這足以讓 QUIC 取代 TCP 嗎？

結論

在這裡，我們研究了 Google 的 QUIC 協議是什麼，它是如何工作的，以及為什麼它可能代表網際網路協議的未來。QUIC 是由谷歌設計的，旨在取代許多過時的標準，並可能在未來幾年真正改變遊戲規則。