快速UDP網路連結（Quick UDP Internet Connection，QUIC）在2021年5月於網際網路工程工作小組（IETF）的 RFC 9000 中標準化。然而QUIC並不完全是一個最近才出現的協定，最初是在2012 年由 Google所開發與部署的網路協議，且該協議的初始公開版本在 2013 年 8 月發布的 Chromium 29版本中已出現。QUIC 是一種以使用者封包通訊協定（User Datagram Protocol，UDP）來取代傳輸控制通訊協定（Transmission Control Protocol，TCP），並不是從根本上改變流控制過程（flow control procedures），而是通過改變傳輸功能在終端主機內實現的位置，從而改變可控制該功能的對象。
目前IP的TCP協議已經實現操作系統功能，應用程式通過一個介面與TCP交換，如此一來該介面實現開/關和讀/寫的基本I/O功能。資料流程完整性和流程控制的細節基本上對應用程式是隱藏的，此得應用程序變為簡單，但這種簡單也伴隨著一些問題。
在基於 Web 的服務方面TCP 有其問題，如今，大多數網頁都不是簡單的一項整體，通常包含許多單獨的物件，包括圖像、自定義框架、樣式表等，每一個物件都是單獨的，如果使用的是原始的HTTP瀏覽器，則每個物件都將在新的 TCP 會話中讀取，即使是從相同的 IP 位址所提供的服務。因此為組合 Web 資源中對每個不同 Web 物件設置新的 TCP 會話和新的傳輸層安全性協定 (Transport Layer Security，TLS) 標頭，所需資源成本可能變得相當大，重新利用已建立的 TLS 會話，藉由同一服務器多次提取資料的作法幾乎是壓倒的誘人。
在已發起的單一TCP會話中使用多工傳輸（multiplexing）傳輸數據的方法會產生問題。跨單獨會話進行多工傳輸多重邏輯資料，可能會造成串流處理器之間相互依賴，並造成多路數據流隊頭阻塞（head of line blocking）延遲，整列的封包會阻塞在同一TCP會話中。使用多工傳輸來傳輸多重邏輯資料，能達到端到端傳輸，在安全和控制速率方面是有意義，但TCP實現的方式卻不理想。如果想透過在網路協定中引入平行行為達到一致性，藉此提高效率，就必須超越目前TCP的處理方式。
不過，有些應用程式或服務平台雖然希望改變TCP傳輸方式，但考量成本和收益的問題後就會卻步。對於這些需要轉換傳輸方式的平台來說，這樣大費周章的變動沒有吸引力。
如果能直接透過應用程式控制傳輸服務，就可以直接看到成果。用戶資料包協定（User Datagram Protocol，UDP）這時就發揮了作用，UDP是一種夾層（shim）協定，將應用程式資料放在IP封包傳送出去，實現端到端傳輸，搭配本身擁有的酬載並加載資料擁塞控制結合為UDP酬載。如此，應用程式就完全控制了傳輸協定，並且可以根據需要，自定義傳輸協定的行為，不需等待第三方。
QUIC摘要
QUIC是端到端傳輸協定的實現，使用UDP協定作為基礎(圖一)，結合TCP的可靠性和控制功能，將其與TLS的會話加密功能相結合，增加了多重串流更彈性的版本，還增加了對位址的敏捷性支援，以承受多種網路位址轉換（Network Address Translation，NAT）行為。
圖 1 – HTTP 架構中TCP和QUIC的比較
未來將持續探討「認識QUIC」系列，本系列共五篇。(1/5)
相關連結：
Geoff Huston(2022). A look at QUIC use. APNIC.
檢自：
https://blog.apnic.net/2022/07/11/a-look-at-quic-use/ (Aug. 08, 2022)
