🥇HTTP over UDP——充分利用 QUIC 協定

QUIC（快速 UDP Internet 連線）是一種基於 UDP 的協議，支援 TCP、TLS 和 HTTP/2 的所有功能並解決它們的大部分問題。它通常被稱為新的或「實驗性」協議，但它早已超越了實驗階段：開發已經持續了 7 年多。在此期間，該協議並未成為標準，但仍廣泛傳播。例如，Google 和 Facebook 等巨頭使用 QUIC 來加速流量並減少行動網路中的延遲，IETF 宣布該協議的分支是 HTTP/3 標準的基礎（儘管 HTTP/2 使用只有44.8% 站點）。

概念

QUIC 是作為傳統 TCP 的替代品而開發的，後者最初是為低損耗有線網路設計的。 TCP 會依序傳送資料包，因此如果遺失一個資料包，整個佇列就會停止（隊頭阻塞），這會對連接的品質和穩定性產生負面影響。為了避免巨大的損失，蜂窩網路訴諸於使用大緩衝區，這反過來又導致協議的冗餘和誤報響應（緩衝膨脹）。此外，TCP 花費大量時間建立連線：SYN/ACK 和 TLS 請求是分開處理的，需要 XNUMX 次往返，而不是像 QUIC 那樣需要 XNUMX 次往返。

由於 QUIC 結合了 TCP 替代和 TLS 1.3 的實現，因此所有連接始終都是加密的，並且解密此類流量並不比透過 HTTPS 傳輸更容易。此外，QUIC 是在應用程式層級實現的，因為完全替換 TCP 堆疊需要永恆.

儘管 HTTP/2 支援多路復用，但由於需要按順序傳送資料包，隊頭阻塞問題仍然存在。 QUIC 是在 UDP 之上實現的，因此原則上沒有阻塞，並且為了防止資料包永遠丟失，它們被編號並可以包含部分“鄰居”，從而提供冗餘。此外，QUIC 將整體佇列拆分為多個線程，用於單一連線中不同類型的請求。因此，如果資料包遺失，則僅一個佇列可能會出現問題（例如，傳輸特定檔案）：

使用

最初，QUIC 是在 Google 內部開發的，主要是為在公司內部使用而量身訂製的。 2013年，它被轉移到IETF進行標準化（目前仍在進行中），現在每個人都可以透過提出自己缺少的內容來參與協議的開發。 IETF 工作小組組織年度會議，批准新標準並討論創新。 QUIC 的這項實現被認為是主要的實現，HTTP/3 標準正是在其基礎上獲得認證。

到目前為止，還沒有討論將 HTTP/3 作為主要協議，因為它還沒有完成並且幾乎不被支援：

但 QUIC 可以作為應用程式和伺服器之間的傳輸來實現，Uber 已經成功做到了這一點：

Uber對引入QUIC的評論

為了在連接不良的環境中成功嵌入 QUIC 並提高應用程式效能，我們用 QUIC 協定取代了舊堆疊（基於 TLS/TCP 的 HTTP/2）。我們使用了網路圖書館克羅內特的鉻項目，其中包含原始的 Google 版本協議 - gQUIC。該實作也在不斷改進，以遵循最新的 IETF 規範。

我們首先將 Cronet 整合到我們的 Android-應用程式新增QUIC支援。實施此整合是為了最大限度地降低遷移成本。而不是完全替換使用該庫的舊網路協定棧。好的http，我們在 OkHttp API 框架下整合了 Cronet。透過這種方式進行集成，我們避免了對網路呼叫的變更（這些呼叫由翻新）在 API 層級。

與此方法類似 Android-設備，我們在 Uber iOS 應用中實現了 Cronet，用於攔截來自網路的 HTTP 流量。 API使用 NSURL協定。這種抽象由 iOS 基金會提供，可處理特定於協議的 URL 數據，並確保我們可以將 Cronet 整合到我們的 iOS 應用程式中，而無需大量遷移成本。

取自這個翻譯優步文章

在後端，他們透過 Google Cloud lb 捕獲了 QUIC 連接，這支援協議自2018年中期以來。

谷歌雲端與Google開發的協定配合得很好，這並不奇怪，但還有什麼替代方案呢？

Nginx的

不久前 CloudFlare 我嘗試穿越 nginx（預設不支援 HTTP/3）及其 Quiche 工具。此實作可作為單一 .patch 檔案使用，該檔案附帶安裝教學課程：

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

如有必要，您可以在此處連接模組

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

剩下的就是啟用 HTTP/3 支持

events {
    worker_connections  1024;
}

http {
    server {
        # Enable QUIC and HTTP/3.
        listen 443 quic reuseport;

        # Enable HTTP/2 (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Request buffering in not currently supported for HTTP/3.
        proxy_request_buffering off;

        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

目前還無法在常規瀏覽器中透過 HTTP/3 連接，但您可以使用鍍鉻加那利並用標誌運行它 --enable-quic，前往您的伺服器或例如 quic.rocks 站點，然後在開發人員工具中查看連線類型：

它不是 HTTP/3，而是這樣寫的 http2+quic/99，但本質上是一樣的。

其他技術

QUIC也支持 LiteSpeed （大張旗鼓地透過 HTTP/3 連接到 Facebook）和漸進式盒。 Apache 還不能做到，但工作正在進行中全面展開.
21 月 XNUMX 日更新 WebRTC 標準草案
就在微軟剛開幕的那天 msquic實作程式碼，其中尚未提供 IETF 標準的所有功能，但這已經是一個很大的突破。