主持人 > 博客 > 管理 > HTTP over UDP - 充分利用 QUIC 協議

HTTP over UDP - 充分利用 QUIC 協議

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 次往返。

HTTP over UDP - 充分利用 QUIC 協議

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

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

HTTP over UDP - 充分利用 QUIC 協議

使用

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

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

HTTP over UDP - 充分利用 QUIC 協議

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

Uber對引入QUIC的評論

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

我們首先將 Cronet 整合到我們的 Android 應用程式中以新增對 QUIC 的支援。 整合的方式是盡可能降低遷移成本。 而不是完全替換使用該庫的舊網路堆疊 好的http，我們在 OkHttp API 框架下整合了 Cronet。 透過這種方式進行集成，我們避免了對網路呼叫的變更（這些呼叫由 翻新）在 API 層級。

與 Android 裝置的方法類似，我們在 iOS 上的 Uber 應用程式中實作了 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 over UDP - 充分利用 QUIC 協議
它不是 HTTP/3，而是這樣寫的 http2+quic/99，但本質上是一樣的。

其他技術

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

結論

HTTP over UDP - 充分利用 QUIC 協議

對 QUIC 的興趣不穩定，但正在增長，並且正在進行標準化工作。 該協議的新實現幾乎每個月都會出現，每年都有越來越多的開發人員相信 QUIC 是未來。 甚至有可能將該協定包含在 TCP 堆疊的未來版本中，這意味著整個網路遲早會轉向更穩定、更快的連線。

現在您已經可以為您的基礎設施配置 QUIC 交互，甚至將其提供給瀏覽器 - 他們都計劃添加對該協議的支持，而 caniuse 的悲傷統計數據將變得更加令人高興。

HTTP over UDP - 充分利用 QUIC 協議

來源： www.habr.com

添加評論