👩🏽‍🤝‍👩🏼 🤘🏻 👨‍🎨 QUICプロトコル：TCPからUDPへのWeb移行 ♌️ 🏇🏽 🌠

QUICプロトコル（名前はQuick UDP Internet Connectionsの略）は、一般に受け入れられているTCPの使用の代わりに、UDPプロトコルの上に構築された、インターネット上で情報を送信するまったく新しい方法です。一部の人々はそれを（冗談めかして） TCP / 2と呼んでいます。 UDPへの切り替えは、このプロトコルの最も興味深い強力な機能であり、他の機能もそれに続くものです。

今日のWebは、信頼性と保証されたパケット配信のために選択されたTCPプロトコルに基づいて構築されています。 TCP接続を開くには、いわゆる「トリプルハンドシェイク」が使用されます。これは、新しい接続ごとに送信/受信サイクルが追加されることを意味し、遅延が増加します。

安全なTLS接続を確立する場合は、さらにパケットを転送する必要があります。

TCP Fast Openなどのいくつかの技術革新により、状況のいくつかの側面が改善されますが、このテクノロジーはまだあまり普及していません。

一方、UDPプロトコルは、「パケットを送信して忘れる」という考えに基づいて構築されています。 UDP経由で送信されたメッセージは、受信者に配信されます（保証はされませんが、成功する可能性があります）。ここでの明らかな利点は、接続セットアップ時間が短いことであり、同様の大きな欠点は、保証された配信の欠如またはパケットが受信者に到着する順序です。つまり、信頼性を確保するには、UDPの上にメカニズムを構築して、パケット配信を保証する必要があります。

そして、GoogleのQUICが登場します。

QUICプロトコルは、接続を開き、すべてのTLSパラメーター（HTTP）を1または2パケットでネゴシエートできます（1または2-接続が新しいサーバーとフレンドのどちらで開かれるかによって異なります）。

これにより、接続のオープンとデータロードの開始が非常に高速になります。

なぜQUICが必要なのですか？

QUICプロトコル開発チームの計画は非常に野心的なものです。プロトコルはUDP速度とTCP信頼性を組み合わせようとします。

ウィキペディアがそれについて書いていることは次のとおりです。

TCPプロトコルの改善はGoogleの長期的な目標であり、QUICは独立したTCP接続と同等になるように設計されていますが、遅延が少なく、SPDY拡張多重化サポートがあります。 QUICが有効な場合、これらの機能はTCPおよびTLSプロトコルの次のバージョンに含まれる可能性があります（開発に時間がかかります）。

この引用には重要な点があります： QUICがその有効性を証明した場合、その中でテストされたアイデアがTCPの次のバージョンの一部になる可能性があります 。

TCPは非常に形式化されています。その実装は、WindowsおよびLinuxカーネル、すべてのモバイルOS、およびより単純な多くのデバイスにあります。これらの実装はすべてTCPをサポートする必要があるため、TCPの改善は簡単ではありません。

UDPは比較的単純なプロトコルです。理論的なアイデアをテストしたり、混雑したネットワークで作業したり、失われたパケットによってブロックされたプロセスフローなどを行うために、UDPを介して新しいプロトコルを開発する方がはるかに高速です。これらのポイントが明確になると、QUICの最良の部分を次のバージョンのTCPに転送する作業を開始できるようになります。

今日のQUICの場所はどこですか？

最新のHTTP接続を構成するレイヤーを見ると、QUICがTLSスタック全体とHTTP / 2の一部を置き換えていることがわかります。

はい、QUICプロトコルは独自の暗号化層を実装しており、TLS 1.2の使用を回避しています。

QUICの上に、HTTP / 2 APIの小さなレイヤーが使用され、リモートサーバーとの通信に使用されます。多重化と接続セットアップはすでにQUICで実装されているため、完全なHTTP / 2実装よりも小さくなります。残っているのは、HTTPプロトコルの実装だけです。

キューの先頭をブロックする（行頭ブロッキング）

SPDYおよびHTTP / 2プロトコルは、ページごとに個別の接続ではなく、サーバーへの同じTCP接続を使用します。この単一の接続は、独立した要求および個々のリソースの取得に使用できます。

データ交換全体が同じTCP接続上に構築されるようになったため、Head-of-lineブロッキングという欠点が自動的に発生します。 TCPでは、パケットが正しい順序で到着する（または処理される）必要があります。パケットがサーバーから\に向かう途中で失われた場合-再送信する必要があります。この時点でのTCP接続は待機（ブロック）する必要があり、失われたパケットを再度受信した後にのみ、キュー内のすべてのパケットの処理が続行されます。

QUICプロトコルは、この問題を根本的に解決します-UDPを優先してTCPプロトコルを放棄し、受信パケットの処理順序への準拠を必要としません。もちろん、パケット損失は依然として可能ですが、これは失われたパッケージが属するリソース（個々のHTML \ CSS \ JSファイル）の処理にのみ影響します。

QUICは、SPDY \ HTTP2（多重化）の最良の部分とノンブロッキングトランスポートプロトコルを非常にエレガントに組み合わせています。

転送されるパケットの数を減らすことが非常に重要な理由

高速インターネット接続を使用している場合、コンピューターとリモートサーバー間のパケット伝送遅延は約10〜50ミリ秒です。ネットワーク経由で送信された各パケットは、この期間が経過するとサーバーによって受信されます。この規模の場合、QUICの利点はあまり明確ではないかもしれません。しかし、別の大陸のサーバーとデータを交換したり、モバイルネットワークを使用したりする問題を考慮すると、すでに100〜150ミリ秒のオーダーの遅延があります。

その結果、モバイルデバイスで、遠くにあるサーバーにアクセスするとき、4つのTCP + TLSパケットと1つのQUICパケットの差は約300ミリ秒になる可能性があり、これはすでに肉眼で観察されるかなりの量です。

予防的なエラー修正

QUICプロトコルのエレガントな機能は、前方誤り訂正（FEC）です。転送された各パケットには、他のパケットからの一定量のデータが含まれているため、失われたパケットの転送を要求したり、コンテンツを待機したりすることなく、近隣のデータから失われたパケットを再構築できます。これは基本的に、ネットワークレベルでのRAID 5の実装です。

しかし、あなた自身はすでにこのソリューションの欠点を認識しています。各パッケージは少し大きくなります。現在の実装では、このオーバーヘッドを10％に設定しています。各パケットの転送を10％増やしたため、パケットが失われるのは10個に1個以下であれば、再要求することなくデータを回復できます。

この冗長性は、遅延を減らすためのネットワーク帯域幅の支払いです（接続速度とチャネル帯域幅が絶えず成長しているため、論理的に思われますが、惑星の反対側へのデータ転送に100ミリ秒かかるという事実は、根本的でなくとも何らかの方法で変更できる可能性は低いです）物理学のクーデター）。

セッション再開と並行ダウンロード

UDPプロトコルを使用するもう1つの興味深い機能は、IPサーバーに縛られなくなったことです。 TCPでは、接続は4つのパラメーターで定義されます：サーバーとクライアントのIPアドレス、サーバーとクライアントのポート。 Linuxでは、netstatコマンドを使用して、確立された接続ごとにこれらのオプションを表示できます。

$ netstat -anlp | grep ':443' ... tcp6 0 0 2a03:a800:a1:1952::f:443 2604:a580:2:1::7:57940 TIME_WAIT - tcp 0 0 31.193.180.217:443 81.82.98.95:59355 TIME_WAIT - ...

これら4つのパラメーターのいずれかを変更する必要がある場合、新しいTCP接続を開く必要があります。そのため、Wi-Fiと3G / LTEを切り替えるときにモバイルデバイスで安定した接続を維持するのは困難です。

QUICでは、UDPを使用するため、このパラメーターセットは使用できなくなりました。 QUICは、接続UUIDと呼ばれる接続識別子の概念を導入します。接続UUIDを維持したままWiFiからLTEに切り替える機会があるため、接続を再作成するコストを回避できます。 Mosh Shellも同様に機能し、IPアドレスを変更するときにSSH接続をアクティブに保ちます。

また、このアプローチは、コンテンツを要求するために複数のソースを使用する可能性への扉を開きます。 Connection UUIDを使用してWiFiからモバイルネットワークに切り替えることができる場合、理論的には両方を同時に使用してデータを並行して受信できます。より多くの通信チャネル-より多くの帯域幅。

QUICの実用的な実装

Chromeブラウザーは、2014年から実験的なQUICをサポートしています。 QUICをテストする場合は、ChromeでQUICのサポートを有効にして、それをサポートするGoogleサービスを使用してみてください。これはGoogleの大きな利点です。ブラウザと独自のWebリソースを組み合わせて使用できることです。世界で最も人気のあるブラウザー（Chrome）および負荷の高いサイト（Youtube.com、Google.com）でQUICを有効にすることで、プロトコルの使用に関する大規模で明確な統計を取得でき、QUICの実際の使用に関するすべての重要な問題が明らかになります。

Chrome用のプラグインがあり、サーバーがHTTP / 2およびQUICプロトコルをサポートするアイコンとして表示されます。

chrome：// net-internals /＃quicタブを開いて、QUIC接続が開いていることを確認することもできます（前述のConnection UUIDパラメーターに注意してください）

さらに進んで、開いているすべての接続とそれらを介して送信されたすべてのパケットを見ることができます：chrome：// net-internals /＃events＆q = type：QUIC_SESSION％20is：active。

ファイアウォールはどのように機能しますか？

あなたがシステム管理者またはネットワークエンジニアである場合、QUICがTCPではなくUDPを使用していることを聞いたとき、少し気を引かれるかもしれません。はい、おそらく独自の理由があります。おそらく（たとえば、当社の場合）、Webサーバーにアクセスするための設定は次のようになります。

もちろん、ここで最も重要なことは、「TCP」と明確に記載されているプロトコルの列です。同様の設定は、合理的であるため、世界中の数千のWebサーバーで使用されています。 80および443ポート、TCPのみ-本番Webサーバーではこれ以上許可しないでください。 UDPなし。

QUICを使用する場合は、UDP接続の解決を443番目のポートに追加する必要があります。大規模なエンタープライズネットワークでは、これが問題になる可能性があります。 Googleの統計が示すように、UDPはいくつかの場所でブロックされています。

これらの数値は、スウェーデンの最近の調査で得られたものです。いくつかの重要な点に注意しましょう。

QUICはGoogleサービスでのみテストされているため、サーバーでファイアウォールが正しく構成されていないために利用できないことはないと想定できます。
数値は、ユーザーから443番目のUDPポートへの発信要求の成功を反映しています。
QUICは、さまざまな理由でChromeで無効にできます。念のため、一部のエンタープライズ環境ではプロアクティブにオフにされたと思います。
QUICはデフォルトで暗号化を使用するため、443番目のポートへのアクセスのみを心配する必要があり、80番目のポートの可用性またはアクセス不能性は影響を及ぼしません。

デフォルトの暗号化の利点は、さまざまなディープパケットインスペクションツールが暗号化された情報を解読してデータを変更することはできず、バイナリストリームを表示し、それをスキップするだけだということです。

サーバー側でのQUICの使用

QUICは現在、 Caddy Webサーバーでサポートされています（バージョン0.9以降）。 QUICのクライアントとサーバーの両方の実装はまだ実験的なサポート段階にあるため、QUICの実用的なアプリケーションには注意してください。 QUICがデフォルトで有効になっているユーザーはいないので、おそらくサーバーで有効にしてブラウザーで実験しても安全です（Chromeでは、バージョン52からQUICがデフォルトで有効になっています）。

QUICパフォーマンス

2015年に、GoogleはいくつかのQUICパフォーマンス測定値を公開しました。

予想どおり、QUICは通信速度の悪い通信路で従来のTCPを隠し、最も遅い接続の1％でスタートページwww.google.comを読み込むと0.5秒のゲインが得られます。この利点は、YouTubeなどのビデオサービスでさらに顕著です。ユーザーは、QUICを使用して動画を視聴する際のバッファリングによる遅延についての不満を30％少なくしました。

YouTubeの統計は特に興味深いものです。この規模の改善が本当に可能であれば、少なくともVimeoなどのビデオサービスの分野や「アダルトビデオ」市場で、QUICの非常に迅速な適応が見られるでしょう。

結論

個人的には、QUICプロトコルは完全に魅力的です！開発者が行った膨大な量の作業は無駄ではありませんでした-今日、インターネット上の最大のサイトがQUICをサポートしているという事実は少し圧倒的です。最終的なQUIC仕様、およびすべてのブラウザとWebサーバーによるそのさらなる実装を待つことができません。

QUICの開発者の1人であるJim Roskindによる記事の解説

私は何年もかけてQUICプロトコルの実装の研究、設計、開発を行ってきましたが、この記事にいくつかの考えを加えたいと思います。テキストは、UDPプロトコルに関する厳格な企業ポリシーが原因で、一部のユーザーがQUICプロトコルを使用できない可能性があることを正しく指摘しています。これが、平均プロトコル可用性が93％である理由です。

少し過去に戻ると、最近では、企業システムがポート80への発信トラフィックでさえ禁止することがよくあります。「これにより、従業員が仕事に悪影響を与えるためにサーフィンに費やす時間を短縮できます」という議論があります。後でわかるように、Webサイトへのアクセス（生産目的を含む）の利点により、ほとんどの企業は、通常の従業員の職場からのインターネットアクセスを許可することにより、規則を改訂することを余儀なくされました。 QUICプロトコルと同様のことを期待しています。新しいプロトコルとの通信が高速になることが明らかになると、タスクはより迅速に実行され、企業に侵入します。

QUICがTCPを大幅に置き換えることを願っています。これは、TCPの次のバージョンに多くのアイデアを提示するという事実に加えてです。事実、TCPはオペレーティングシステムのカーネル、ハードウェアに実装されているため、新しいバージョンへの適応には5〜15年かかる場合がありますが、QUICは、少数の単一の製品/サービスで一般に利用可能で一般的にサポートされているUDPの上に実装できます数週間または数ヶ月。

トピックの詳細：

QUICプロトコル：TCPからUDPへのWeb移行