Deprecated : The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
Google Developers Japan: QUIC
この記事は 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
[この記事は SYN、SYN-ACK、ACK (Alyssa Wilk、Ryan Hamilton、Ian Swett) による Chromium Blog の記事 "A QUIC update on Google’s experimental transport " を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]
Google では昨年、最新のインターネットに対する UDP ベースのトランスポート プロトコル、QUIC を公開 しました。 それから 四半期、QUIC を使用した Google サービスへのトラフィックを徐々に増やし、規模を拡大しながら QUIC のパフォーマンスを分析してきました。現在までのところ結果は良好で、QUIC の低遅延接続確立、優れた輻輳制御や切断時の接続回復といった機能によって、TCP よりも優れたパフォーマンスを示し続けています。
ウェブ検索などの待ち時間に影響を受けるサービスにとって、ほぼ同時に送受信接続を確立できることは最大のメリットです。これまでの標準では、ウェブ ブラウジングのセキュアな通信は TCP + TLS を使用して行うものでした。この形式では、セキュリティを確保するため、ブラウザが実際にウェブページを要求するまでにサーバーと 2 ~ 3 回の送受信を行う必要がありました。QUIC ではあらかじめクライアントから所定のサーバーと通信を行うことで送受信の回数を減らし、ウェブページ読み込みの迅速化を実現しています。データによると、実に 75% もの接続が QUIC のゼロ・ラウンドトリップ機能によって恩恵を受けることができると示されています。接続が事前に確立される Google 検索のような効率化されたサイトですら、QUIC によってページの読み込み時間が 3% ほど向上することが示されています。
QUIC ではさらに、輻輳制御と切断回復機能の向上という多大な利点があります。パケットの再送信時に、パケット シーケンス番号が再利用されることはありません。これによって不明瞭なパケット受信が発生せず、再通信タイムアウトを回避できます。結果として、接続状況が良好でない状況において QUIC は TCP よりも優れた接続を行うことができます。最も遅い 1% の接続状況においても、Google 検索ページの読み込みを大幅に削減できます。 こうしたメリットは、Youtube などの動画サービスではより顕著になります。QUIC 接続での動画視聴の際に、再バッファ時間が 30% 削減されるという報告もなされており、視聴時間が短縮されることで、繰り返し、より多くの動画を視聴できるようになっています。
現在、Chrome から Google サーバーへのおよそ半数のリクエストが QUIC で行われており、今後も QUIC のトラフィックを増やしていく方針です。最終的には QUIC を、Chrome とモバイルアプリの双方で、Google のクライアントから Google のサーバーへの通信規格のデフォルトにする予定です。インターネット標準として IETF に QUIC を正式に提案する予定ですが、その前にワイヤーフォーマットを変更したり、リファレンス実装を SPDY - QUIC から HTTP2 - QUIC に更新したりするなど、いくつかの解決すべき点があります。今後数か月で、応答確認時のオーバーヘッドを低減しサーバー側での拡張性を高め、前方誤り訂正や輻輳制御の向上、マルチパス接続のサポートの追加などに取り組む予定です。
状況を確認したり実際に試すには、コード やこちらのページ をご確認ください。また、proto-quic@chromium.org にもご参加ください。一歩ずつ、インターネットを改良し続けます。
Posted by Eiji Kitamura - Developer Relations Team