本章節將解釋 QUIC 傳輸層協定各基本模組的功能，但不會逐字解釋協定。 如果您想自己實現 QUIC，這些介紹會加強你對協定的理解，但有關具體細節，請參考 IETF 的網際網路草案和 RFC。

1. 建立一個 連接

2. TLS 安全性

3. 使用 串流(streams)

在初始封包建立連接後，發起方立即發送一個加密frame，開始建立安全層交握。安全層使用 TLS 1.3 協定。

在 QUIC 中，沒有方法或機制避免使用 TLS 連接。該設計是為了使中間設備難以篡改封包，防止協定僵化。

QUIC 連接是兩個 QUIC 端點之間的單次對話（ conversation ）過程。

QUIC 建立連接時，加密算法的版本協商與傳輸層交握被合併完成以減小建立連接時的延遲。

為了通過這樣的連接實際發送資料，它必須創建和使用一個或多個串流。

連接ID ( Connection ID )

每個連接過程都有一組連接標識符，或稱連接ID，該ID用以識別該連接。連接ID由端點獨立選擇，每個端點都選擇其對等方使用的連接ID。

這些連接ID的主要功能是確保較低協定層（ UDP，IP及其底層協定 ）的地址更改不會導致 QUIC 連接的封包傳遞到錯誤的端點。

通過利用連接ID，連接可以以 TCP 永遠無法實現的方式在 IP 地址和網路接口之間遷移。 例如，當客戶端裝置移動到一個有 Wifi 網路的環境時，將正在下載的項目從蜂巢式網路轉已到更快的 Wifi 連接。 同樣，如果 Wifi 不可用時，下載可以繼續通過蜂窩連接進行。

端口編號 ( Port numbers )

QUIC 建立在 UDP 之上，因此使用16位元的端口號字段來區分傳入的連接。

版本協商 ( Version negotiation )

源自客戶端的 QUIC 連接請求將告訴伺服器端它要使用哪個版本的 QUIC 協定，服務器將響應回覆一個列表包含所支援的版本來供客戶端選擇。

在 QUIC 中的資料串流（ Streams ）提供了一個輕量級，有序的字節流的抽象化。

QUIC 中有兩種基本的資料串流類型：

• 單向資料串流: 從發起者到對等端（ Peer ）的單向資料串流。

• 雙向均可發出資料的雙向資料串流。

連接端點的任意一方都可以建立這兩種資料串流，資料串流之間可並行、交錯地傳輸，並且可以被取消。

通過 QUIC 發送資料將建立一個或多個資料串流。

流量控制 ( Flow control )

每個資料串流都有獨立的流量控制，端點可以通過此實現內存控制和反壓（ back pressure ）。資料串流的創建本身也受到流量控制，連接雙方可以聲明最多願意接受多少數量的資料串流ID。

資料串流識別符 ( Stream Identifiers )

資料串流由一組無符號62位元的整數標示，稱為資料串流ID。資料串流ID的最低2位元用於標示資料串流類型（ 單向或雙向 ）和資料串流啟動器。

資料串流ID的最低位元（ 0x1 ）標示資料串流的發起者。客戶端發起為偶數（ 設置為0 ）資料串流，伺服器端發起為奇數（ 設置為1 ）資料串流。

第2個位元（ 0x2 ）用於識別單/雙向資料串流。單向資料串流始終為1，雙向資料串流則為0。

資料串流的並行性 ( Stream concurrency )

QUIC 允許任意數量的資料串流同時運行。端點通過閒置最大資料串流ID來控制並行的傳入資料串流數量。

每個端點指定自己的最大資料串流ID數，並只對對等端端點有效。

傳送和接收資料 ( Sending and Receiving Data )

端點使用資料串流來發送和接收資料。這是資料串流的最終目的。 QUIC 資料串流是有序的字節流抽象。但是不同資料串流之間是無序的。

資料串流的優先順位 ( Stream Prioritization )

如果正確設置了各資料串流的優先度，流復用機制可以顯著提升應用的效率。使用其它多路復用協定（ 如HTTP/2 ）的經驗表明，有效的優先度劃分策略對效率具有顯著的正面影響。

QUIC 本身沒有交換優先級訊息的框架。 相反，它信任來自使用 QUIC 的應用程序的優先級訊息。利用 QUIC 的協定可以定義與它們的應用程序語義相匹配的優先級分配方案。

有許多對 HTTP/2 優先級排序模型的批評，並且擔心它過於復雜，並且沒有被許多 HTTP/2 伺服器端使用和實現。 目前，HTTP/3 中的優先級已從主要的 HTTP/3 規範中刪除，且正被做成一個 .

在用戶空間中實作傳輸協定有助於協定的快速迭代，因為相對容易地發展協定而無需客戶端和伺服器端更新其作業系統核心以部署新版本。

QUIC 本身沒有固有的東西阻礙未來在作業系統核新中實現和提供 QUIC 協定。

更多的實作 ( Many implementations )

在用戶空間中實作一個新的傳輸層協定時，一個顯而易見的效果是我們會看到很多獨立的實作。

在可預見的未來，不同的應用程序可能包含（ 或基於 ）不同的 HTTP/3 和 QUIC 實作。

為了減少建立新連接所需的時間，曾連接到該伺服器端的客戶端會緩存某些參數，並使用這些參數與伺服器端建立 0-RTT 連接。 這樣，客戶端可以立即發送資料，而不必等待交握的動作完成。

常規 TCP 和使用該協定的程式成功的因素之一是標準化的 socket API。 它具有定義明確的功能，使用此 API，您可以在許多不同的作業系統之間移動程式，因為 TCP 的工作原理相同。

但 QUIC 並不是。 QUIC 目前沒有標準化的 API。

使用 QUIC 時，你需要選擇一個現有的程式庫來實作，並堅持使用它的 API。這在某種程度上把應用 "綁定" 到了單一的庫上。換庫代表著使用另外一套 API，這可能帶來相當的工作量。

另外，由於 QUIC 一般在用戶空間中實作，所以它不像現有的 TCP 和 UDP socket API 那樣能輕鬆擴展。 使用 QUIC 代表著選擇了 socket API 之外的另一套 API。

在 QUIC 工作組的設計討論中，最長的主題之一就是 Spin Bit，人們花費了數百封郵件和數百個小時來討論它。

Spin Bit 的支持者認為，兩個 QUIC 端點之間路徑上的運營商和人員需要有辦法來測量延遲。

反對者則反感此功能潛在的訊息洩露。

Spinning a bit

客戶端和伺服器端這兩個端點都為每個 QUIC 連接維護旋轉值0或1，並且將為該連接發送的封包上的旋轉位設置為適當的值。

然後，在每一次往返時，連接雙方都翻轉這一 bit 的值。效果就是觀察者可以監視的那個位域中的1和0的脈衝。

僅當發送人不受應用程序或流控制的限制時，此觀察才有效，並且在網路上對封包進行排序可能會使封包意外出現。