\r\n\r\n
HTTP/2という言葉を聞いたことがないかもしれませんが、これはHTTPの最新のアップデートです。新しいプロトコル規格は、サーバーとアプリケーション間の通信をより速く、より効率的にするための新しい概念を数多く導入しています。
HTTP/2(Hypertext Transfer Protocol version 2)は、15年ぶりとなるHTTPのメジャーアップデートです。
1997年から使われている以前のプロトコル規格であるHTTP/1.1では、HTTPの限界を改善するために、不器用な解決策が混在していた。
HTTP/1.1の問題点や制限を解決するためにGoogleが始めたオープンソースの実験であるSPDY(「スピーディー」)がベースになっています。
インターネット技術タスクフォース(IETF)は、ハイパーテキスト転送プロトコル17のドラフトバージョン2で同様の変更を指定した。
「HTTP/2は、ヘッダーフィールドの圧縮を導入し、同じ接続で複数の同時交換を可能にすることで、ネットワークリソースをより効率的に使用し、遅延の認識を減らすことを可能にします。
「また、リクエストに優先順位をつけることができるので、より重要なリクエストをより早く完了させ、パフォーマンスをさらに向上させることができます。
"HTTP/2はまた、バイナリメッセージフレームの使用により、より効率的なメッセージの処理を可能にします。"
"この仕様は、HTTP/1.1メッセージ構文の代替であり、廃止するものではありません。HTTPの既存のセマンティクスは変更されません。"
SPDYの普及に伴い、HTTP Working Group(HTTP-WG)は、HTTP規格の更新作業を開始した。
これ以降、SPDYはHTTP/2の新機能の基礎と実験ブランチになった。当時、私たちはSPDYによってブラウジングをどのように改善できるかを検討しました。その後、規格のバージョン2が起草され、承認・発行されています。
SPDYの機能の多くはHTTP/2に統合され、結局、Googleは2016年初めにこのプロトコルのサポートを打ち切りました。
結局ほとんどのブラウザがSPDYをサポートしなくなり、他に選択肢がないため、HTTP/2がデファクトスタンダードになりつつあります。
HTTP/2プロトコル規格は、HTTP/1と完全な後方互換性はありませんが、翻訳によって互換性を実現することができます。HTTP/1.1しか持たないクライアントは、HTTP/2しか持たないサーバーを理解できませんし、その逆も同様です。そのため、新しいバージョンのプロトコルはHTTP/1.2ではなく、HTTP/2になっています。
つまり、HTTP-WGが提供する作業の重要な部分は、HTTP/1とHTTP/2が情報を失うことなく前後に変換できることを保証することです。
また、導入される**機構や機能は、バージョンに依存せず、既存のウェブとの後方互換性が保たれる予定です。
HTTP/2はユーザーが実装できるものではありませんが、ブラウジングのスピードに影響を与えるためにできることはあります。あなたは、これらの神話のどれかがあなたのインターネットブラウジングを高速化することができると信じていますか?
HTTP/2は、HTTP標準にいくつかの大きなアップデートを導入しました。より重要なものとして、バイナリフレーム、多重化、ストリームの優先順位付け、ストリーム制御、サーバープッシュなどがあります。
HTTP2/のアップデートにより、HTTPプロトコルの通信はバイナリコード化されたフレームの交換に分割されました。これらのフレームは、特定のストリームに属するメッセージにマッピングされる。そして、1つのTCPコネクションの中でストリームを多重化(ある意味、織り込み済み)する。
新しいバイナリフレームレイヤーでは、ストリーム、メッセージ、フレームという新しい用語が多数導入されています。
これにより、従来は複数のTCPコネクションが必要だったのが、1つのTCPコネクションで済むようになりました。
HTTP/1.1では、1回の接続で1つのレスポンスしか配信されないことを保証します。クライアントが複数のリクエストを並行して行いたい場合、ブラウザは追加のTCPコネクションを開くことになる。
HTTP/2は、HTTP/1.1のこの制限を取り除き、完全なリクエストとレスポンスの多重化をサポートしています。つまり、クライアントとサーバーはHTTPメッセージを個別のフレームに分割し、これらのフレームをインターリーブして相手側で再集合することができます。
全体として、複数接続がある程度不要になるため、HTTP/2の最も重要な強化点です。これにより、すべてのウェブテクノロジーに多くのパフォーマンス上のメリットがもたらされることになります。
接続数が減ることで、TLS(Transport Layer Security)ハンドシェイクの回数が減り、セッションの再利用性が向上し、クライアントとサーバーのリソース要件が全体的に削減されます。これにより、アプリケーションの展開がより速く、よりシンプルに、より安価になります。
多くの外部アセット(画像やスクリプト)を持つサイトでは、HTTP/2の多重化によって最大のパフォーマンス向上が期待できます。
HTTP/2 では、各ストリームに重み (1 から 256 の間の値) を与え、別のストリームに明示的に依存させることができます。
この依存関係と重みの組み合わせにより、優先順位ツリーが作成され、サーバー・クライアントがどのように応答を受け取りたいかが示される。
サーバーは、優先度ツリーの情報をもとに、CPUやメモリーなどのリソースの割り当てや帯域の割り当てを制御し、クライアントが優先度の高いレスポンスを最適に受け取れるようにします。
HTTP/2におけるフロー制御の問題はHTTP/1.1と同様であるが、HTTP/2のフローは単一のTCPコネクション内で多重化されるため、HTTP/1.1のフロー制御アプローチはもはや有効でない。
つまり、フローが互いに干渉し合って閉塞するのを防ぐために、フロー制御が必要なのです。HTTP/2では、プロトコルを変更することなく、さまざまなフローコントロールアルゴリズムを使用することが可能です。
HTTP/2 ではフロー制御のアルゴリズムは規定されていません。 代わりに、クライアントとサーバーが独自のフロー制御を適用するのに役立つ一連のビルディングブロックが提供されています。
これらの構成要素の詳細は、HTTP/2internetdraftの "Stream Control "のセクションに記載されています。
お客様が初めてページを訪れたとき、ブラウザは通常、サーバーにHTMLドキュメントを要求し、受信します。その後、サーバーはブラウザがHTML文書を解析し、埋め込まれた資産(CSS、JavaScript、画像など)のリクエストを送信するのを待つ必要がある。
HTTP/1.1 では、サーバーはブラウザから要求されるまでこれらの資産を送信できず、各資産は個別の要求(すなわち複数のハンドシェイクと接続)を必要とします。
サーバープッシュ(serverpush)により、サーバーはこれらのリソースをプロンプトなしで送ることができ、クライアントがそれらを必要とすることをすでに知っているので、レイテンシーを減らすことができます。つまり、上記の例では、サーバーはCSS、JavaScript(Webページでよく使われるスクリプト言語)、画像をブラウザにプッシュして、ページを高速に表示させることになるのです。
基本的にサーバープッシュは、1つのクライアントリクエストに対して、サーバーが複数のレスポンスを送信することを可能にします。
手動で行うとはいえ、これは現在、CSSやJSをHTML文書にインライン化することで得られる効果であり、クライアントからのリクエストを待つことなくインラインリソースをクライアントにプッシュすることができる。
これは、現在のHTTPの標準である厳格な1対1のリクエスト・レスポンス型のワークフローとは大きく異なるものである。
SPDYはセキュリティに関するポリシーがやや厳しく、すべての接続にSSL暗号化が必要です。 HTTPS/2は暗号化を必要としませんが、多くのサービスはSSLなしのHTTP/2を提供しません。
すべての主要なブラウザはHTTP/2をサポートしていますが、暗号化なしでサポートしているブラウザはありません。CanIUsのウェブサイトでは、HTTP/2の現在のブラウザサポートの概要を、上記のように表で紹介しています。
HTTP/1.1とHTTP/2の間の後方互換性と変換は、ページの読み込み時間を遅くする。
現時点では、暗号化をデフォルトまたは必須の設定とすべきでない本当の理由はありません。すでにSSL証明書を取得しているサイトでは、HSTSを有効にすることで、HTTPSサイトのセキュリティを向上させることができます。
HTTP/2は2015年半ばに標準規格として提案され、同年末までにほとんどのブラウザがサポートを追加しました。 HTTP/2は、インターネットの仕組みやアプリケーションとサーバーの通信方法に影響を与えています。
HTTP/2の利用は必須ではありませんが、今のところメリットばかりでデメリットはありません。また、ユーザーからすると、あまり気にならない程度のマイナーチェンジです。
W3Techによると、現在上位1000万サイトの31.7%がHTTP/2をサポートしています。 ほとんどの人にとって、WebサイトでHTTP/2を有効にする最も早い方法は、CloudflareのCDNを使用することです。
次に提案された規格(HTTP/3)は、Googleによる別の実験プロジェクトであるQUICをベースとしており、すでに実用化されています。今年10月、IETFのHTTP-WGとQUICワーキンググループは、QUICを新しい世界標準とすることを正式に要請し、HTTP/3と改称した。
もし興味があるなら、Akamai.com はお使いのブラウザが HTTP/2 をサポートしているかどうかを簡単にチェックするツールを提供しています。