ヘッダーはもっともよく使われるヘッダーとなります。リクエストごとに変わるかもしれませんが、大部分はリクエストごとに同じか、限られた数のバリエーションを送信します。ヘッダーなど)を何度も送信することがよくあります。したがって、影響を考慮するためには、ページが行っているリクエストの数に注目する必要があります。画像を見る図24.16の説明を表示パーセンタイル毎のHTTPリクエスト数を示す棒グラフ。90%パーセンタイルでは、デスクトップが178、モバイルが171となっています。パーセンタイル毎のHTTPリクエスト数。デスクトップ用サイトの中央値は74リクエスト、モバイル用サイトの中央値は69リクエストです。1ページあたりのリクエスト数が数千を超えるサイトも何百とありました。高かったのは、合計17,923リクエストで、次いで10,224リクエストとなっています。HTTP/2は、以前のリクエストで送信されたヘッダーを圧縮して再利用することで、繰り返されるリクエストの影響を軽減しています。この分析では、ブラウザのネットワークスタックの奥深くに埋もれているため、ヘッダー圧縮の正確な影響を測定することはできませんが、圧縮されていないヘッダーサイズを見ることで、潜在的なメリットの指標を示すことはできます。画像を見る図24.17の説明を表示HTTPレスポンスヘッダーサイズを示す棒グラフ。デスクトップのヘッダーサイズは、モバイルよりも若干大きくなっています。HTTPレスポンスヘッダーサイズ。ウェブページの中央値では、デスクトップで34KB、モバイルで31KB相当のヘッダーが返されます。90パーセンタイルでは、デスクトップで98KB、モバイルで94KBに増加します。レスポンスヘッダーの最大のインスタンスは5.38MB以上でした。多くのサイトで、1MBを超えるレスポンスヘッダーが発見されました。ヘッダーが原因であり、ウェブサイト間でこれらのヘッダーの複雑さや誤った管理を示唆しています。設定を重複させるアプリケーションの設定ミスやエラーが原因で、ヘッダーが過大になっています。優先順位付けまた、あるストリームを別のストリームに依存させることでストリームをリンクさせたり、1〜256の整数を割り当てて重み付けをしたりすることもできます。これらの依存関係や重み付けによって、サーバーは特定のキーストリームを優先し、他のストリームよりも先に応答データを送信できます。HTTP/2が導入されて以来、優先順位付けはウェブのさまざまな部分で矛盾なく実装されています。Davisは、この矛盾が、ウェブ上のユーザーに最適とはいえない体験をもたらす可能性があることを発見しました。これは、サーバーが優先順位付けを無視して、先着順でサービスを提供することが多いからです。実際、Andyの研究は、主要なCDNの多くがHTTP/2の優先順位付けを正しく実装していないことを強調しています。これには、人気のあるクラウドロードバランサーも多数含まれています。2021年のデータでは、優先順位付けを正しく実装しているCDNはわずか6社で、例年と同様の調査結果となっています。これには、Akamai、Fastly、Cloudflare、Automattic、section.io、Facebook独自のCDNが含まれています。あり、サーバー側での優先順位付けを改善できるだろうと提案しています。この不整合はクライアントレベルでも存在し、ブラウザベンダーによってこの動作の実装が異なります。Safariは、アセットタイプに応じて優先順位付けを行う静的なアプローチを実装しており、依存関係をマッピングしません。Chrome、Edge、Firefoxは、ストリーム全体の論理的な依存関係を構築する、より高度なアプローチを持っており、発見された優先順位に基づいてストリーム上の要求されたアセットの優先順位を変更できます。結果を調べる画像を見る図24.18の説明を表示WebPageTestのリソースを示すスクリーンショット。優先順位の高いリソースが早期に読み込みを終了している。WebPageTestのウォーターフォール例。いう提案で、優先順位付けに対する最新の提案がなされています。フレームを追加することが含まれます。フレームは、HTTP/3においても提案されています。基本動作を改善する取り組みとして注目されています。HTTP/2プッシュの死?もう1つの大きな特徴は、サーバープッシュの仕組みが導入されたことです。HTTP/2のサーバープッシュでは、サーバーがクライアントのリクエストに応答して複数のリソースを送信できます。このため、クライアントがその存在を気づく前に、サーバーはクライアントが必要とする可能性のあるアセットを通知する。一般的な使用例としては、ブラウザがベースHTMLを解析してそれらの重要な資産を特定し、その後自ら要求する前に、JavaScriptやCSSなどの重要な資産をクライアントにプッシュすることが挙げられます。クライアントには、プッシュメッセージを拒否するオプションもあります。ゼロ・ラウンドトリップ、先制的な重要資産、パフォーマンス向上の可能性などの約束にもかかわらず、HTTP/2プッシュは誇大広告に見合うものではありません。HTTP/2プッシュを使用しているサイト。2019年に分析したところ、HTTP/2はほとんど採用されておらず、平均0.5%程度でした。翌2020年には、デスクトップで0.85%、モバイルでは1.06%の採用率に増加しました。今年2021年はデスクトップで1.03%、モバイルで1.25%とわずかに増加しています。相対的にモバイルは前年比で大幅に増加していますが、HTTP/2の採用率は全体で1.25%と、まだ無視できるレベルです。ページレベルでは、デスクトップが64kリクエスト、モバイルが93kリクエストとなっています。モバイルで13.4%、デスクトップでは12.5%。プッシュするためのシグナルとして再利用していました。場合によっては、開発者がアセットをプリロードしたいが、HTTP/2プッシュメカニズムで配信されるのは嫌だと判断することがあります。ディレクティブを使って、プッシュを試みないように合図したいかもしれません。今年のデータでは、20万件以上のプリロードヘッダーが使用され、そのうちの平均12%がnopush属性で発行されたことが分かっています。ディレクティブを導入することです。データと分析を使ってこの動的プッシュの設定を決定する実装例を示しているものの、ウェブ全体での実装が限定されていることがデータからうかがえます。研究によると、正しく適用すればHTTP/2プッシュはウェブパフォーマンスに明確な利益をもたらすことが示唆されています。他のCDNプロバイダーやサーバー実装からの投資は、HTTP/2プッシュのための設計が困難であることを証明しています。Archibaldは、2017年の時点でこれらの課題のいくつかを説明しています。これらは、プッシュキャッシュの問題、ブラウザの不整合、クライアントがプッシュを必要としないと判断した場合にサーバーから送信される余分なバイトに焦点を当てたものです。ダイジェストがユーザーの特定に使われるかもしれないプライバシーとセキュリティの懸念に関する問題から、主に放棄されました。Hintsで、問題点のいくつかを取り上げています。その投稿では、Pushは通常、HTMLやその他のレンダーブロッキングアセットを遅延させる結果になると詳しく説明しています。画像を見る図24.21の説明を表示さまざまなパーセンタイルでモバイルとデスクトップにプッシュされたキロバイト数を示す棒グラフ。10パーセンタイルではデスクトップとモバイルの両方で0バイト、25パーセンタイルではデスクトップで19バイト、モバイルで0バイト、50パーセンタイルではそれぞれ146と48、75パーセンタイルでは295と222、そして最後に90パーセンタイルではデスクトップで373バイト、モバイルで323バイトがプッシュされています。kilobytes.アイテムがプッシュされた場合のバイトサイズの中央値は、デスクトップで145KB、モバイルで48KBでした。これが75パーセンタイルになると、デスクトップでは294KBとほぼ倍増し、モバイルでは221KBと4倍以上になっています。トップエンドでは、90パーセンタイルで372KB、モバイルでは323KBがプッシュされていることがわかります。この90%台の数字は問題ないように見えますが、プッシュ回数を見直すようになると、プッシュ機能の誤用が浮き彫りになってくるのです。画像を見る図24.22の説明を表示さまざまなパーセンタイルでモバイルとデスクトップにプッシュされたアセットの数を示す棒グラフ。10パーセンタイルではデスクトップとモバイルの両方で1つのリソースがプッシュされ、25パーセンタイルではそれぞれ2と1、50パーセンタイルでは4と3、75パーセンタイルでは8と8、90パーセンタイルでは21と16になっています。HTTP/2はキロバイトをプッシュしています。プッシュ回数の中央値は、デスクトップとモバイルでそれぞれ4回と3回です。75パーセンタイルでは8回、90パーセンタイルでは21回と16回に跳ね上がります。100パーセンタイルでは、517回と630回という驚くべきプッシュが一部のサイトで行われており、とくにプッシュが本来リクエストの初期に少数の重要なアセットを提供するために設計されたことを考えると、この機能の危険性が浮き彫りになっています。画像を見る図24.23の説明を表示さまざまなパーセンタイルでモバイルとデスクトップにプッシュされたアセットの数を示す棒グラフ。10パーセンタイルではデスクトップとモバイルの両方で1つのリソースがプッシュされ、25パーセンタイルではそれぞれ2と1、50パーセンタイルでは4と3、75パーセンタイルでは8と8、90パーセンタイルでは21と16になっています。HTTP/2のプッシュ回数。コンテンツの種類別に分析すると、フォントがもっとも多く、次いで画像、CSS、スクリプト、動画の順になっています。この数字は、アセットタイプのサイズを見ると、異なるストーリーを描いています。フォントは依然としてもっとも多く利用されているアセットですが、スクリプトも遠く及ばない程度に利用されています。画像、動画、CSSの順です。したがって、より多くのCSSファイルがプッシュされているにもかかわらず、そのサイズは小さいということになります。スクリプトは、フォント、画像、CSSほど頻繁にプッシュされていませんが、プッシュされたデータの中ではより大きなボリュームを占めています。上記の数字が示すように、また以前の記事でも紹介したように、HTTPプッシュは十分に活用されていません。利用されていても、誤用されたり、意図したとおりに使われなかったりすることが多く、エンドユーザーにとってパフォーマンスの障害となる可能性が高いのです。Googleは、Chromeからプッシュを削除する意向を表明しています。Pushの有効性については、まだ継続的な議論が続いていました。この削除はまだ実現しておらず、Pushを正しく実装しているCDNを通じて活用できることが大きく示唆されています。ディレクティブの活用を推奨していますが、それでも1RTTが発生するため、Pushが解決しようとすることは同じです。GoogleもHTTP/3にPushを実装していないと報告しており、Cloudflareのような他の企業も同様です。プッシュの代替Pushの代わりによく提案されるのが、アーリーヒントを使うことです。ヒントを含めることで動作します。すべきアセットを報告できます。as="style"FastlyやCloudflareなどのCDNは、アーリーヒントヒントの実験を行っていますが、アーリーヒントヒントはまだ日が浅いです。あり、他のブラウザベンダーはアーリーヒントのサポートを発表し、Cloudflareは野放し状態でサポートを導入していますが、他の多くのベンダーはまだ具体的に実装していない状態です。HTTP/2プッシュの採用が年々増えているにもかかわらず、Googleや他のブラウザベンダーはプッシュのサポートを放棄し、アーリーヒントのような代替手段を選ぶと思われる。CDNからのサポートと相まって、アーリーヒントがその代替となる可能性が高い。昨年、私たちはHTTP/2プッシュに別れを告げるかどうかという問題を提案しました。今年は、少なくともウェブブラウジングのユースケースでは、HTTP/2のメインストリーム利用は死んだと提案します。HTTP/3HTTP/3は、HTTP/2の次の進化であり、その基礎の上に、プロトコル全体にさらなる変更を加えて構築されています。最大の変化は、TCPからQUICと呼ばれるUDPベースのトランスポートプロトコルに移行したことです。これにより、インターネット全体に浸透しているTCPの実装がサポートされるのを待つことなく、HTTPの迅速な進歩が可能になりました。HTTP/2は独立したストリームの概念を導入しましたが、TCPレベルではこれらはまだ1つのTCPストリームの一部であり、本当の意味で独立したものではありません。これをサポートするためにTCPを変更することは、安全に使用できるほど広くサポートされるようになるまで、かなりの時間を要するでしょう。そのため、HTTP/3は代替のトランスポートプロトコルに切り替えています。QUICは多くの点でTCPに似ており、基本的にTCPの多くの便利な機能をすべて再構築し、新しい機能を追加しています。QUICは暗号化され、よくサポートされている軽量のUDPトランスポートプロトコルで配信されます。画像を見る図24.24の説明を表示ランキング別のトップページのHTTP/3対応状況を示す棒グラフ。上位1,000サイトでは13.3%、上位1万サイトで17.4%、上位10万サイトでは19.5%、上位100万サイトは19.2%がHTTP/3を利用しており、全体では15.0%となっています。デスクトップの数字も非常によく似ています。ランキングによるトップページのHTTP/3対応。この章の前半で、上位にランクされたサイトほどHTTP/2の採用率が、高いことがわかりました。意外なことに、HTTP/3ではその逆が当てはまります。上位1000サイトのサポートは上位100万サイトよりも少なく、モバイルサイトでのサポートがわずかに多く実装されていることがわかります。上位10万サイトと上位100万サイトでの分布は、デスクトップが18%、モバイルは19%。上位1万サイトでは、16%と17%に低下しています。上位1,000サイトでは、デスクトップとモバイルでそれぞれ11%と13%となっています。上位100万サイトを超えるサイトでは、ホームページへの導入率は15%程度です。全体として、これは非常に強力な採用であり、おそらくいくつかの主要なCDNからのサポートが先導しているのでしょう。このことは、上位のウェブサイトがHTTP/2を主流として採用している一方で、多くのウェブサイトがHTTP/3をまだ探求していないことを示唆しています。HTTP/3対応HTTP/3へのWebサーバーの対応は、まだ市場でも限られています。Nginxはウェブ上でもっとも一般的なHTTPサーバーであり、HTTP/2サイトの約3分の2がNginxのバージョンを使用しています。完全サポートを展開し、2021年末までに完全サポートを実現することを目指しています。それに比べ、Apacheサーバーは、HTTP/3がいつサポートされるのか、まだ何のガイダンスも出していない。HTTP/3をサポートすることを発表しました。して利用できるようにしました。Node.jsのサポートは、OpenSSLのサポートがないため、保留されています。多くのCDNがHTTP/3のサポートを表明しています。Cloudflareは、2019年からHTTP/3の実験を行っており、その中で多くの事例でパフォーマンスが向上していることを報告しています。quicheライブラリも公開しています。Fastlyは、HTTP/3のサポートについても議論しており、BETAサービスとして利用できるようにしています。HTTPサーバ用に設計されています。HTTP/3のブラウザサポートは、現在も進化を続けています。mobileについてはモバイル全体で部分的に利用可能です。Surに限定されており、「実験的機能」を介して有効にする必要があります、iOSのサポートもフラグの後ろにある実験的機能としてのみ利用可能です。HTTP/3のネゴシエーションHTTP/3は従来のTCPベースのHTTPと完全に、異なるトランスポート層にあるので、HTTPSネゴシエーションを通じてHTTP/2で起こるような、接続設定の一部としてHTTP/3をネゴシエートすることはできません。この段階で、あなたはすでにトランスポートプロトコルを選んでいます!HTTP/3は代わりにalt-svcヘッダーを必要とします。ヘッダーを通して、このサーバーはUDPとQUIC上のHTTP/3もサポートしていると通知できます。ブラウザはそれを使って接続を試みることを決定できます。HTTP/3のいくつかの繰り返しのために、このヘッダーは、クライアントとサーバーがどのバージョンのHTTP/3に決定することができるかということでもあります。そのため、最初のケースでは、最初のリクエストでHTTP/2が使用されます。ヘッダーを検出すると、プロトコルを切り替えてHTTP/3を使用し始めることができます。ヘッダーをキャッシュし、次回はHTTP/3を試すために直接ジャンプできます。結果を調べる画像を見る図24.25の説明を表示WebPageTestのスクリーンショット。検出された後、HTTP3に切り替わります。ページロード中にHTTP2からHTTP3に切り替わる様子を示すWebPageTestの例。コネクション合体(コネクションの再利用)により、2つのホスト名がDNS上で同じIPに解決し、同じTLS証明書とバージョンを使用する場合、クライアントは両方のホスト名で同じコネクションを再利用できる場合があります。リクエストを目にすることは珍しくありません。ヘッダーを提供します。これらはQUICを提供する構文、さまざまなH3プレリリースバージョンの1つ(公式にはHTTP/3は執筆時点で標準化されていませんが、非常に最終段階にあります)間で異なります。ように複数のバージョンのQUICのサポートを宣伝していますが、中には1つのバージョンしか提供しないサイトもあります。応答に対して11%に及んでいます。24時間であることをクライアントに指示します。alt-svcがある場合、ほとんどのサイトは新しいプロトコルのバージョンをサポートするようにバージョン番号を追加していますが、clearディレクティブを使って以前に宣伝したサポートを無効にしているケースも多く見られました。この記事の執筆時点では、HTTP/3仕様の最新バージョンは34です。この最新バージョンを報告している回答は、わずか0.01%です。詳細を見る場合、レスポンスヘッダーでもっともよく要求されるバージョンは27であす。サーバーは左から右の順に優先されるバージョンを表示します。優先され、同じレスポンスで28と29が代替バージョンとして提供されると報告されます。アップグレードのための唯一の優先バージョンとして提供します。正式リリースを待ってバージョンを凍結していました。24時間しかないと報告しています。これは、指定しない場合のデフォルトです。30日または2592000秒でした。レスポンスヘッダーを表示しています。HTTP/3に関する考察と懸念HTTP/3の長所が多く語られる一方で、懸念や批判も指摘されている。なったため、今ようやくHTTP/2から導入した変更に慣れてきたというところです。場合によっては、開発者とサイトオーナーは、HTTP/3による増分の利益は、ウェブサーバーの大規模なアップグレードに見合わないかもしれないと主張するかもしれません。HTTP/3が、優先順位付けやサーバープッシュの効果的な使用など、HTTP/2で特定された問題をすべて解決していない場合はなおさらです。そのため、採用はウェブアプリケーション内ではなく、CDNレベルで推進されるかもしれません。これは、いくつかのサーバーがHTTP/3をサポートしないか、OpenSSLのサポート不足によってブロックされる場合、とくにそうなる可能性があります。この章を通して説明したように、QUICはUDPプロトコルに依存しています。HTTP/3の導入に伴い、UDPのトラフィックはウェブ全体で増加する予定です。現状ではUDPはリフレクション攻撃などの攻撃ベクトルとしてよく利用されています。QUICはいくつかの保護メカニズムを備えていますが、これは、ウェブ上でのUDPの扱いの変更と、あるネットワークとファイアウォールで許可されるUDPトラフィックの量の変更を意味するかもしれません。同じ例で、TCPヘッダーとパケットの非暗号化部分がファイアウォールやウェブ上の他のミドルボックスで使用されている場合、採用の後押しがあるかもしれません。QUICはパケットの多くの部分を暗号化するため、パケットに関する検査の可視性が低くなり、追加のセキュリティチェックを行う能力など、これらのミドルボックスの動作が、制限される可能性があります。QUICはサーバー側でパフォーマンスの問題が、発生することが懸念されています。これは、UDPを扱う際に必要となるCPU要件が高くなるためです。HTTP/2と比較した場合、2倍のCPUが必要になるとの試算もあります。CPUパフォーマンスを最適化する試みは現在進行形で数多く行われています。このような懸念はあるものの、本当のメリットはウェブのエンドユーザーから受けることになります。QUICは、ネットワーク接続を切り替えても接続を維持できるため、モバイルファーストの世界でもモバイルファーストの体験を可能にします。ヘッドオブラインブロッキングの改善により、ページロードがより向上し、1ミリ秒が重要であることを私たちは知っています。QUICが導入する強化された暗号化により、より安全でセキュアなWebを実現できます。HTTP/3では0-RTTが可能であるため、パフォーマンスの向上も期待できます。本章を通じて、私たちはHTTP/2の採用が増加していることと、より新しいバージョンのプロトコルが提供する利点に主な焦点を当てながら、HTTPの進化を見てきました。続いて、HTTP/3について詳しく見ていき、バージョン3がウェブ上で数年間HTTP/2が使用された後に特定された懸念の多くをどのように解決することを目指しているかを見てきました。Archiveのデータによると、今年はHTTP/2の採用が大きく進み、リクエストの72%がHTTP/2を使用し、ベースとなるHTMLページの59%がHTTP/2を使用していることがわかります。この採用は、CDNプロバイダーによる採用の増加が主な要因となっています。HTTP/1.1はウェブ上で少数派となっています。HTTP/2の普及にもかかわらずHTTP/2のプッシュ機能は、実装の複雑さのために十分に活用されていないままであり、私たちは、プッシュは実際に到着時に死んでいる可能性があることを示唆しています。同時に、リソースの優先順位付けに関する継続的な懸念や、主要なCDNベンダー以外の不正な実装が見られます。優先順位付けの複雑さは、HTTP/3仕様から削除されるほど、依然として広まっています。2021年は、HTTP/3の採用に関しても詳しく検証することができました。GoogleやFacebookなどの主要プレイヤーは、数年前からHTTP/3のサポートを独自に展開しています。HTTP/3のより広い採用は、ウェブの他の部分に対するHTTP/3のサポートへ公に取り組んできたAkamai、Cloudflare、Fastlyによって影響されています。1.3のより厳密なカプセル化により、プロトコルスタックのより多くの部分の安全性を確保することを目的としています。HTTP/3はまだ初期段階です。私たちは2022年にHTTP/3の採用を測定することを楽しみにしており、HTTP/2のサポートが主流になり、人々が現在の展開よりもさらなる改善を得たいと考えるようになるにつれて、さらに牽引される可能性が高いと信じています。HTTP/3にはいくつかの懸念が示されていますが、これらの懸念のいずれもが、エンドユーザーへ得られるパフォーマンスによって打ち消されるはずです。HTTP/3の採用は、HTTP/2で見られたように、CDNが独自の実装に向けて取り組むことで、CDNのロールアウトによって促進される可能性もあります。主要なウェブフレームワークでの実装はまだ確認されていません。今後数年間は、HTTP/2とHTTP/3が混在することになると思われます。ソリューション・エンジニアリング・マネージャーで、ウェブ上でのサイトのパフォーマンスと安全性を高めることに長年取り組んでいます。ツイッターでは@dominiclovell、またはLinkedInで彼とつながることができます。AlmanacTwitterGitHub。