Googleが発表した 数日前にすでに始まっています ChromeでのHTTP / 3およびIETFQUICの展開 発表の中で、彼は、このアップデートにより、特にQUICのサポートにより、パフォーマンスがさらに向上することを期待していると述べています。
QUICは新しいネットワークトランスポートプロトコルです TCP、TLSなどの機能を組み合わせたものです。 HTTP / 3はHTTPの最新バージョンです、Webトラフィックの大部分を伝送するプロトコル。 HTTP / 3はQUICでのみ機能します。
インターネットエンジニアリングタスクフォース（IETF）は2年にHTTP / 2015を導入し、それが行った大きな改善のXNUMXつは多重化のサポートです。
ただし、トランスポートプロトコルとしてTCPを使用し、TCPの損失回復メカニズムを使用したため、パケットが失われると、アクティブなすべてのトランザクションで遅延が発生する可能性があります。
QUICを採用することにより、HTTP / 3は転送プロセスをさらに改善できますこの場合、失われたパケットは直接影響を受けるトランザクションにのみ影響するためです。
実際には、 QUICはもともとGoogleによって開発されました 2013年に最初に発表されました。それ以来、プロトコルは成熟し、現在、GoogleのトラフィックのXNUMX分のXNUMXを運ぶ責任があります。
その後、2015年に、QUICの開発は、インターネットプロトコルの保守を担当する標準機関であるIETFの手に渡りました。 IETFは、いくつかの変更を加えてQUICを改善しました。 現在までに、XNUMXつの類似しているが異なるプロトコルがあります。それは、GoogleQUICとIETFQUICです。
Googleは、常に独自のバージョンのQUICを使用していることを発表しました、しかし、彼のQUICチームは、IEFTの独自バージョンの実装にも関与しています。 「IETFによる変更に対応するために、過去XNUMX年間でGoogle QUICを進化させるために多大な努力を払ってきました。現在、最新バージョンのGoogle QUICは、IETFQUICと多くの類似点があります」とブログ投稿は述べています。さらに、Googleから まだ足りないものがあることを明らかにした。
例として、これまでのところ ほとんどのChromeユーザーはIETFQUICサーバーと通信できません 一部のコマンドラインオプションを有効にせずに。 同様に、 Googleは、IETFQUICがHTTPを大幅に上回っていることを発見したと付け加えました。 TCPと比較したTLS1.3と比較して。
特に、同社によれば、Googleの検索エンジンの待ち時間は2％以上短縮されています。 YouTubeのバッファリング時間は9％以上短縮されました。 さらに、クライアントのパフォーマンスはデスクトップコンピューターで3％以上向上しました。
携帯電話では、顧客のパフォーマンスが7％以上向上しました。 これらおよびその他の理由は、ChromeがIETFのQUICバージョンに切り替えた背景にあります。 「ChromeがIETFQUIC（具体的には、h3-29パイロットバージョン）のサポートを実装していることをお知らせします。
現在、Chromeの安定バージョンのユーザーの約25％がh3-29を使用しており、パフォーマンスデータを引き続き監視することで、今後数週間でこの数を増やす予定です」と同社のブログ投稿で述べています。 。
「ChromeはIETFQUICh3-29とGoogleQUICバージョン（Q050）の両方を積極的にサポートし、Q050をサポートするサーバーがIETFQUICにアップグレードする時間を確保します」と彼は付け加えました。 Chromem85はまだIETFQUIC 0-RTTをサポートしておらず、Googleは、今後数か月以内にIETF QUIC 0-RTTのサポートをリリースすると、このパフォーマンスがさらに向上すると予想しています。 また、IETF QUICバージョン30および31には、互換性を損なう可能性のある変更が含まれていないため、同社は識別子「over-the-wire」を変更する予定はありません。
つまり、 IETFバージョンの変更を引き続き追跡します。 しかし h3-29 / 0xff00001dとして実装されます。
したがって、Chromeと相互運用する場合は、最終的なRFCが完了するまで、サーバーがh3-29を引き続きサポートすることをお勧めします。 ただし、IETFが将来のプロジェクトで互換性を損なうような変更を加えた場合、Chromeはその決定を覆します。