🥇HTTP over UDP - QUIC プロトコルを使用するとメリット

QUIC (Quick UDP Internet Connections) は、TCP、TLS、HTTP/2 のすべての機能をサポートし、それらの問題のほとんどを解決する UDP 上のプロトコルです。これは新しいプロトコルまたは「実験的」プロトコルと呼ばれることが多いですが、実験段階をはるかに超えて開発が 7 年以上続いています。この間、このプロトコルは標準にはなりませんでしたが、それでも広く普及しました。たとえば、QUIC は、Google や Facebook などの大手企業によってトラフィックを高速化し、モバイルネットワークの遅延を軽減するために使用されており、IETF は、このプロトコルのフォークが HTTP/3 標準の基礎であると宣言しました (HTTP/2 ではわずか44.8％サイト）。

コンセプト

QUIC は、もともと低損失の有線ネットワーク用に設計された従来の TCP の代替として開発されました。 TCP はパケットを順番に配信するため、XNUMX つのパケットが失われるとキュー全体が停止します (行頭ブロック）、接続の品質と安定性に悪影響を及ぼします。多大な損失を避けるために、携帯電話ネットワークは大きなバッファを使用することに頼っていますが、その結果、プロトコルの冗長性と偽陰性応答が発生します(バッファブロート）。さらに、TCP は接続の確立に多くの時間を費やします。SYN/ACK および TLS リクエストは個別に処理され、QUIC のように XNUMX 回ではなく XNUMX 回のラウンドトリップが必要になります。

QUIC は TCP の代替と TLS 1.3 の実装を組み合わせているため、すべての接続は常に暗号化され、そのようなトラフィックの復号化は HTTPS 経由の場合よりも簡単です。さらに、TCP スタックの完全な置き換えには時間がかかるため、QUIC はアプリケーションレベルで実装されます。永遠.

HTTP/2 では多重化がサポートされていますが、パケットを順番に配信する必要があるため、ヘッドオブラインブロッキングの問題が依然として残っていました。 QUIC は UDP 上に実装されるため、原則としてブロッキングがありません。パケットが永久に失われるのを防ぐために、パケットには番号が付けられ、「隣接」の一部を含めることができ、冗長性を提供します。さらに、QUIC は、単一の接続内のさまざまなタイプのリクエストに対応するために、モノリシックキューを複数のスレッドに分割します。したがって、パケットが失われた場合、問題は XNUMX つのキューでのみ発生する可能性があります (たとえば、特定のファイルの転送など)。

使用

当初、QUIC は Google 内で開発され、主に社内での使用に合わせて調整されていました。 2013 年に標準化のために IETF に移管され (現在も進行中)、誰もが欠けているものを提案することでプロトコルの開発に参加できるようになりました。 IETF ワーキンググループは年次会議を開催し、そこで新しい規格が承認され、革新性が議論されます。 QUIC のこの実装は主要な実装とみなされ、これに基づいて HTTP/3 標準が認定されます。

これまでのところ、HTTP/3 をメインプロトコルとして含めるという話はありません。これは、HTTP/XNUMX がまだ完成しておらず、ほとんどサポートされていないためです。

しかし、QUIC はアプリケーションとサーバー間のトランスポートとして実装でき、Uber ではこれが成功しました。

QUIC導入に関するUberのコメント

QUIC をうまく埋め込み、接続状態が悪い環境でアプリケーションのパフォーマンスを向上させるために、古いスタック (TLS/TCP 上の HTTP/2) を QUIC プロトコルに置き換えました。ネットワークライブラリを利用しましたクロネットのクロムプロジェクト、これには、元の Google バージョンのプロトコル - gQUIC が含まれています。この実装も、最新の IETF 仕様に準拠するために継続的に改善されています。

まず、QUIC のサポートを追加するために Cronet を Android アプリに統合しました。統合は、移行コストを可能な限り削減する方法で実行されました。ライブラリを使用していた古いネットワークスタックを完全に置き換えるのではなく、 OKHTTP、OkHttp API フレームワークの下に Cronet を統合しました。この方法で統合を行うことで、ネットワーク呼び出し ( 組み込む) API レベルで。

Android デバイスのアプローチと同様に、iOS 上の Uber アプリに Cronet を実装し、ネットワークからの HTTP トラフィックを傍受しました。 API使い方 NSURLプロトコル。 iOS Foundation によって提供されるこの抽象化は、プロトコル固有の URL データを処理し、多額の移行コストをかけずに Cronet を iOS アプリケーションに統合できるようにします。

から撮影この翻訳ウーバーの記事

バックエンドでは、Google Cloud lb 経由で QUIC 接続をキャッチしました。プロトコルをサポート 2018年半ばから。

Google Cloud が 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にも対応ライトスピード (鳴り物入りで HTTP/3 経由で Facebook に接続しました) およびプログレッシブキャディー。 Apache ではまだ実行できませんが、作業は進行中です本格的に.
21月XNUMX日更新 WebRTC の標準ドラフト
つい先日マイクロソフトがオープンしました msquicの実装コード、IETF 標準のすべての機能がまだ利用できるわけではありませんが、これはすでに大きな進歩です。

まとめ

QUIC への関心は不安定ではありますが、高まっており、標準化に向けた作業が進行中です。このプロトコルの新しい実装はほぼ毎月登場し、QUIC が未来であると確信する開発者が年々増えています。このプロトコルを TCP スタックの将来のバージョンに組み込むことも可能です。これは、遅かれ早かれインターネット全体がより安定した高速接続に移行することを意味します。

すでに、インフラストラクチャに QUIC インタラクションを設定したり、ブラウザに提供したりすることができます。どのブラウザもこのプロトコルのサポートを追加する予定であり、caniuse に関する悲しい統計がより明るくなるでしょう。

出所： habr.com

HTTP over UDP - QUIC プロトコルを活用する

コンセプト

使用

QUIC導入に関するUberのコメント

nginx

その他の技術

まとめ

コメントを追加します返信をキャンセル

HTTP over UDP - QUIC プロトコルを活用する

コンセプト

使用

QUIC導入に関するUberのコメント

nginx

その他の技術

まとめ

コメントを追加します 返信をキャンセル

コメントを追加します返信をキャンセル