QUIC (Quick UDP Internet Connections) は、TCP、TLS、HTTP/2 のすべての機能をサポートし、それらの問題のほとんどを解決する UDP 上のプロトコルです。 これは新しいプロトコルまたは「実験的」プロトコルと呼ばれることが多いですが、実験段階をはるかに超えて開発が 7 年以上続いています。 この間、このプロトコルは標準にはなりませんでしたが、それでも広く普及しました。 たとえば、QUIC は、Google や Facebook などの大手企業によってトラフィックを高速化し、モバイル ネットワークの遅延を軽減するために使用されており、IETF は、このプロトコルのフォークが HTTP/3 標準の基礎であると宣言しました (HTTP/2 では
コンセプト
QUIC は、もともと低損失の有線ネットワーク用に設計された従来の TCP の代替として開発されました。 TCP はパケットを順番に配信するため、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 接続をキャッチしました。
Google Cloud が Google が開発したプロトコルとうまく連携するのは当然のことですが、代替手段は何でしょうか?
nginx
少し前のCloudFlare
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