QUIC
/ quick /
想像你一趟去同一家店買了好幾樣不同的東西。用舊的做法（TCP），送貨車把所有東西排成一長條隊伍：如果最前面那箱弄丟了、必須重送，後面每一箱都得跟著等，連那些早就平安到的也一樣。這種卡在隊伍最前頭的問題，叫做行頭阻塞（head-of-line blocking）。QUIC 是一種較新的傳輸協定，設計上讓某一樣東西的延遲不會凍住其他所有東西——每一條資料流都走自己的軌道。
具體來說，QUIC 是一種可靠、加密、可多工的傳輸協定，建立在 UDP 之上，但把聰明的工作放在使用者空間（在應用程式或其函式庫內）處理，而不是在作業系統核心裡。它提供 TCP 所提供的——依序、可靠的傳遞與壅塞控制——但在一條連線裡承載許多獨立的資料流，所以丟失的封包只會卡住它所屬的那條流，不會卡住其餘的流。它還把連線建立與 TLS 加密交握合而為一：舊的 TCP 加 TLS 需要一次往返來建立連線、再用幾次往返來加密，QUIC 卻能在最少一次往返內建立安全連線（重新連到曾經談過話的伺服器時甚至零次往返）。而且因為每條 QUIC 連線都有自己的識別碼，你的工作階段能在手機從 Wi-Fi 切到行動網路時存活下來、不中斷。
為什麼重要：QUIC 是 HTTP/3 的基礎，而 HTTP/3 是網路主要協定的新版本，如今對大型網站的流量已有可觀比例採用它。一個常見的誤解是：QUIC 既然坐在 UDP 上，就放棄了可靠性——並非如此。UDP 只是它建立其上、那層薄而不加密的底座；QUIC 自己重新實作了可靠性、排序與壅塞控制，再加上強制加密。它真正待在 UDP 上、待在使用者空間的原因是：TCP 早已烤進全世界的作業系統核心與中間設備裡，幾乎不可能更動；建立在 UDP 上讓 QUIC 的設計者能快速演進出一個現代化的傳輸協定，不必等整個網際網路把核心都升級。
一個網頁同時載入圖片、腳本和樣式表。在 TCP 上跑 HTTP/2 時，如果承載某張圖片的單一封包丟了，整條連線就會停住、直到它被重送——其他每一項資源都得等。在 QUIC 上跑 HTTP/3 時，只有那張圖片的資料流會暫停；腳本和樣式表照樣到達，網頁也照樣繼續繪製。
逐流傳遞消除了 TCP 的行頭阻塞。
QUIC 的加密不像 TLS 那樣是事後栓在 TCP 上的選配——它是內建且強制的，連 QUIC 自己大部分的標頭都加密。但 QUIC 並非對所有情況都神奇地更快：在乾淨、低丟失的連結上，調校良好的 TCP 加 TLS 連線表現相近，而 QUIC 的使用者空間處理每位元組可能耗掉更多 CPU。