最近の開発者 後ろにいる人 グーグルクロームウェブブラウザ、HTTP / 3プロトコルのサポートの追加のニュースをリリースしました ChromeCanaryの実験的なビルドに HTTP overQUICを有効にするプラグインを実装します。
QUICプロトコル自体はXNUMX年前にブラウザに追加されました それ以来、Googleサービスとの連携を最適化するために使用されてきました。 同時に、Chromeで使用されているGoogleのQUICバージョンは、IETF仕様のバージョンとは細部が多少異なりますが、実装は同期しています。
Google Chrome Canaryは、（非常に）実験的なものを統合した最初の（利用可能な）ブラウザになりました #クイック およびHTTP / 3のサポート！
フラグ「–enable-quic –quic-version = h3-23」を追加すると、「http / 2 + quic / 99」がdevtoolsに表示されます。これは、実際にはhttp3に変装しています。 pic.twitter.com/5Fhui46h3x
-ロビン・マルクス（@programmingart） 2019 年 9 月 19 日
それを強調することが重要です GoogleはQUICを開発しました（クイックUDPインターネット接続） 2013年以降、Web用のTCP + TLSパッケージの代替として、TCP接続の長い構成とネゴシエーション時間の問題を解決し、データ転送中のパケット損失の遅延を排除します。
QUICは、複数の接続の多重化をサポートするUDPプロトコルを補完するものです TLS / SSLと同等の暗号化方式を提供します。
問題のプロトコルはすでにGoogleのサーバーインフラストラクチャに組み込まれており、Chromeの一部であり、Firefoxに含める予定であり、Googleのサーバーで顧客のリクエストを処理するために積極的に使用されています。
目立つQUICの主な特徴は次のとおりです。
- TLSと同様の高いセキュリティ（実際、QUICはTLS over UDPを使用する機能を提供します）
- パケット損失を防ぐフロー整合性制御
- 即座に接続を確立し（0-RTT、約75％の場合、データは接続セットアップパケットの送信直後に送信できます）、要求の送信から応答の受信までの遅延を最小限に抑える機能（RTT、ラウンドトリップ時間）
- パケットを再送信するときに同じシーケンス番号を使用しない。これにより、受信したパケットを判別する際のあいまいさが回避され、待機時間がなくなります。
- パケットを失うと、それに関連付けられたストリームのみの配信に影響し、現在の接続を介して並行して送信されるストリームでのデータの配信を停止しません。
- 失われたパケットの再送信による遅延を最小限に抑えるエラー訂正ツール。
- 失われたパケットデータの再送信を必要とする状況を減らすための特別なパケットレベルのエラー訂正コードの使用。
- ブロックの暗号化制限はQUICパケットの制限と一致し、次のパケットのコンテンツのデコードに対するパケット損失の影響を減らします
- TCPキューのブロックに問題はありません
- モバイルクライアントの再接続を確立する時間を短縮する接続識別子のサポート
- 高度なメカニズムを接続して接続の過負荷を制御する機能
また、各方向の帯域幅を予測する手法を利用していることも強調されています。 最適なパケット配信強度を確保し、パケット損失が観察される輻輳状態に到達しないようにします。
と同様 TCPを超える顕著なパフォーマンスとパフォーマンスの向上。 YouTubeのようなビデオサービスの場合、QUICはビデオを視聴する際の再バッファリング操作が30％削減されたことを示しました。
HTTP / 3プロトコルは、HTTP / 2のトランスポートとしてのQUICの使用を標準化します。 HTTP / 3および23ドラフトIETF仕様のQUICバージョンを有効にするには、Chromeをオプション「–enable-quic –quic-version = h3-23」で実行し、quicテストサイトが開いたときに.rocks：4433 in開発者ツールのネットワーク検査モードでは、HTTP / 3アクティビティは「http / 2 + quic / 99」と表示されます。
並列HTTP接続によって失われたパケットと比較して、多くの接続のうち1つだけが停止されます。つまり、QUICは順不同の配信をサポートできるため、失われたパケットの影響は少なくなります。
Si あなたはそれについてもっと知りたい これについては、相談することができます 次のリンク.