この記事は David Schinazi - Chrome QUIC テックリード、Fan Yang - Google Front End QUIC テックリード、Ian Swett - ウェブ パフォーマンス テックリード マネージャーによる Chromium Blog の記事 "Chrome is deploying HTTP/3 and IETF QUIC" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
QUIC は、TCP や TLS などの機能を組み合わせた新しいネットワーク転送プロトコルです。HTTP/3 は、ウェブ トラフィックの大半を扱っているプロトコルである HTTP の最新バージョンです。HTTP/3 は QUIC 上でのみ動作します。
QUIC はもともと Google によって開発され、2013 年に初めて発表されました。その後、このプロトコルは成熟し、現在は Google のトラフィックの 3 分の 1 以上を扱うほどになっています。Google は 2015 年に QUIC を IETF(インターネットのプロトコルを管理する標準団体)に提唱し、IETF は QUIC にたくさんの変更を加えて改善してきました。現時点では、Google QUIC と IETF QUIC という、似て非なる 2 つのプロトコルが存在しています。Google の QUIC チームは当初から IETF プロセスに関与していましたが、IETF QUIC の実装が進む間も Chrome では Google QUIC が使われ続けています。ここ 5 年間にわたり、私たちは IETF の変更に追従して Google QUIC を進化させるために膨大な作業を続けてきました。現在の最新版の Google QUIC バージョン(Q050)は、多くの点で IETF QUIC と共通しています。しかしこれまで、大多数の Chrome ユーザーは、いくつかのコマンドライン オプションを有効化しなければ IETF QUIC サーバーと通信できませんでした。
本日からは違います。TCP と TLS 1.3 で HTTP を使う場合よりも、IETF QUIC を使う方が圧倒的にパフォーマンスがいいことがわかっています。特に、Google 検索にかかる時間は 2% 以上短くなります。YouTube の再バッファリング時間は 9% 以上も短くなり、クライアントのスループットは PC で 3% 以上、モバイルで 7% 以上増加します。そこで、Chrome で IETF QUIC(具体的には、ドラフト バージョン h3-29)のサポートがリリースされることをお知らせします。現在、Chrome 安定版ユーザーの 25% が h3-29 を使っており、今後数週間で、パフォーマンス データを監視しながらその数を増やす予定です。Google QUIC Q050 をサポートするサーバーが IETF QUIC にアップデートできるように、Chrome は IETF QUIC h3-29 と Google QUIC Q050 の両方をサポートする予定です。
Chrome 85 はまだ IETF QUIC 0-RTT をサポートしていないので、数か月後に IETF QUIC の 0-RTT サポートがリリースされれば、パフォーマンスの数値はさらに向上するはずです。
続く IETF ドラフト 30 および 31 には互換性に影響を与える変更はないため、今のところ over-the-wire 識別子を変更する予定はありません。つまり、IETF 仕様の変更には追従するものの、変更は h3-29/0xff00001d という名前で展開する予定です。そのため、Chrome との相互運用性を確保したいサーバーは、確定版の RFC が完成するまで h3-29 のサポートを続けることを推奨します。ただし、IETF が今後のドラフトで互換性に影響する変更を行った場合は、Chrome でもこの判断が再考される可能性があります。
このブログの執筆者一同は、このお知らせにつながる懸命な作業を行ってくれた Google の QUIC チーム全員に感謝します。私たちがともに成し遂げたことを誇りに思っています。IETF で QUIC に貢献してくださった皆さんと、Google の QUIC チームの元メンバー全員にも感謝を捧げます。皆さんがいなければ、ここでお知らせしたことは実現できませんでした。
Reviewed by Eiji Kitamura - Developer Relations Team
QUIC は、TCP や TLS などの機能を組み合わせた新しいネットワーク転送プロトコルです。HTTP/3 は、ウェブ トラフィックの大半を扱っているプロトコルである HTTP の最新バージョンです。HTTP/3 は QUIC 上でのみ動作します。
QUIC はもともと Google によって開発され、2013 年に初めて発表されました。その後、このプロトコルは成熟し、現在は Google のトラフィックの 3 分の 1 以上を扱うほどになっています。Google は 2015 年に QUIC を IETF(インターネットのプロトコルを管理する標準団体)に提唱し、IETF は QUIC にたくさんの変更を加えて改善してきました。現時点では、Google QUIC と IETF QUIC という、似て非なる 2 つのプロトコルが存在しています。Google の QUIC チームは当初から IETF プロセスに関与していましたが、IETF QUIC の実装が進む間も Chrome では Google QUIC が使われ続けています。ここ 5 年間にわたり、私たちは IETF の変更に追従して Google QUIC を進化させるために膨大な作業を続けてきました。現在の最新版の Google QUIC バージョン(Q050)は、多くの点で IETF QUIC と共通しています。しかしこれまで、大多数の Chrome ユーザーは、いくつかのコマンドライン オプションを有効化しなければ IETF QUIC サーバーと通信できませんでした。
本日からは違います。TCP と TLS 1.3 で HTTP を使う場合よりも、IETF QUIC を使う方が圧倒的にパフォーマンスがいいことがわかっています。特に、Google 検索にかかる時間は 2% 以上短くなります。YouTube の再バッファリング時間は 9% 以上も短くなり、クライアントのスループットは PC で 3% 以上、モバイルで 7% 以上増加します。そこで、Chrome で IETF QUIC(具体的には、ドラフト バージョン h3-29)のサポートがリリースされることをお知らせします。現在、Chrome 安定版ユーザーの 25% が h3-29 を使っており、今後数週間で、パフォーマンス データを監視しながらその数を増やす予定です。Google QUIC Q050 をサポートするサーバーが IETF QUIC にアップデートできるように、Chrome は IETF QUIC h3-29 と Google QUIC Q050 の両方をサポートする予定です。
Chrome 85 はまだ IETF QUIC 0-RTT をサポートしていないので、数か月後に IETF QUIC の 0-RTT サポートがリリースされれば、パフォーマンスの数値はさらに向上するはずです。
続く IETF ドラフト 30 および 31 には互換性に影響を与える変更はないため、今のところ over-the-wire 識別子を変更する予定はありません。つまり、IETF 仕様の変更には追従するものの、変更は h3-29/0xff00001d という名前で展開する予定です。そのため、Chrome との相互運用性を確保したいサーバーは、確定版の RFC が完成するまで h3-29 のサポートを続けることを推奨します。ただし、IETF が今後のドラフトで互換性に影響する変更を行った場合は、Chrome でもこの判断が再考される可能性があります。
このブログの執筆者一同は、このお知らせにつながる懸命な作業を行ってくれた Google の QUIC チーム全員に感謝します。私たちがともに成し遂げたことを誇りに思っています。IETF で QUIC に貢献してくださった皆さんと、Google の QUIC チームの元メンバー全員にも感謝を捧げます。皆さんがいなければ、ここでお知らせしたことは実現できませんでした。
Reviewed by Eiji Kitamura - Developer Relations Team