前言

昨天的文章簡單提到了關於 HTTP/3 與先前協定版本的差別，其中一個部分是 HTTP/3 所使用的網路通訊協定是基於 UDP 的 QUIC 協定，不過對於這個協定卻沒有較清楚的理解，所以今天的文章就來介紹一下 QUIC 協定吧！

QUIC 是什麼？

QUIC 是基於 UDP 的多路復用傳輸協定，旨在提供安全、低延遲的網路通信。在2021年發布的RFC 9000正式標準化 QUIC，是一種連接導向的協定，類似於 TCP，但具有更高的性能和靈活性。主要目的是解決傳統 TCP 協定在延遲和性能方面的不足。

從 TCP 到 QUIC 改變了什麼？

• 連接速度的提升：如以下官方文件內容，QUIC 提供了兩種握手方式：

  A full 1-RTT handshake, in which the client is able to send application data after one round trip and the server immediately responds after receiving the first handshake message from the client.
  A 0-RTT handshake, in which the client uses information it has previously learned about the server to send application data immediately. This application data can be replayed by an attacker, so 0-RTT is not suitable for carrying instructions that might initiate any action that could cause unwanted effects if replayed.

  1. 1-RTT模式：在 QUIC 協定中，將 TLS 加密協商整合進握手過程中，因此使用者端只要進行一次1-RTT（Round Trip Time，是指從發送數據包到接收該數據包的確認所需的總時間）就可以進行數據的傳輸，這是第一種模式。
  2. 0-RTT模式：當客戶端與伺服器之前已建立過連接時，使用者可以在握手完成之前立即發送應用數據。這種模式依賴於使用者在首次進行連接時記住連接中的關鍵參數，並將其傳送給伺服器以恢復連接狀態。
     而過去協定版本透過 TCP 進行三次握手後（1-RTT），還會再進行 TLS 的加密協商(1~2-RTT)，此時要經歷2~3 RTT，而 QUIC 連線的速度則明顯提升不少。

• 切換網路（從行動網路切換成 wifi）時能夠保持連線：根據官方文件的定義，TCP 的連接主要是一對 sockets（套接字）所組成，而 socket 則是包含埠號以及 IP 位址。當網路進行切換時，IP 位址也會隨之改變，因此 TCP 連線也會斷開並且進行重新連接。而 QUIC 則是透過 connection ID 對於連線進行識別，以下是RFC 9000的敘述：

  Each connection possesses a set of connection identifiers, or connection IDs, each of which can identify the connection. Connection IDs are independently selected by endpoints; each endpoint selects the connection IDs that its peer uses.
  The primary function of a connection ID is to ensure that changes in addressing at lower protocol layers (UDP, IP) do not cause packets for a QUIC connection to be delivered to the wrong endpoint.

  QUIC 對於每個連線都會分配一個 連線 ID（connection ID），是用來標識端點（endpoints，即使用者端/伺服器端）的標示碼，其目的是在於確保 IP 位址的變更不會造成數據傳到錯誤的端點，因此 IP 位址的改變並不會影響到連線，只要原本的連線 ID 還在時，就可以繼續保持連線，提高了切換網路的靈活性以及避免了重新連線的延遲。對於使用行動裝置（手機 or 平板）十分頻繁的現代，真的是一個意義重大的改變～

• 多路復用的應用：在一個QUIC連線中，可以同時存在多個流（streams）。當發送數據或請求時，將自動建立新的流，而每個流都是獨立的、互不影響的。因此，如果任一請求或回應的封包遺失並需要重傳，這不會像先前的協定版本那樣造成其他請求或回應的阻塞。這種設計使得QUIC能夠有效地提升網路傳輸效率，特別是在現代許多網頁應用都需要同時加載多個資源，也避免隊頭阻塞（Head-of-Line Blocking）問題，提供更流暢的用戶體驗，確保數據能夠快速且可靠地傳輸。

小結

今天簡單介紹了我對於 QUIC 的一些理解，以及它與 TCP 的一些差異，明天開始就會來介紹 HTTP 的 status code 拉～

參考資料

RFC 9000
RFC 9001
MDN