HTTP/1.1 対 HTTP/2: フレーミング、マルチプレクシング、パフォーマンス

イントロダクション

HTTP/1.1 と HTTP/2 は異なるワイヤフォーマットを通じて同じアプリケーションセマンティクスを持ちます。GET はまだ GET であり、ステータスコードはその意味を保持し、URI は同じリソースを特定します。最大の変更は、メッセージが接続を共有する方法です。

HTTP/1.1 は各接続でテキストメッセージを直列化します。HTTP/2 はメッセージをストリームに割り当てられたバイナリフレームに分割し、多くの交換が1つの接続で進行できるようにします。これにより、いくつかの HTTP レイヤーのスケジューリング制限が解除されますが、両方のバージョンは依然として TCP に依存しており、一部のトランスポート動作を共有します。

テキストメッセージとバイナリフレームの違い

HTTP/1.1 はスタートライン、テキストフィールド、空行、およびオプションのコンテンツを定義します。メッセージの長さは Content-Length、転送コーディング、接続の終了、またはメソッドとステータスのセマンティクスなどのルールを介して決定されます。解析エラーは、実装が境界について意見が一致しない場合に接続を非同期にする可能性があります。

RFC 9112 は HTTP/1.1 メッセージングを定義します。HTTP/2 はそのテキストワイヤ構文を型付きバイナリフレームに置き換えます。HEADERS フレームと DATA フレームは番号付きストリームを介してメッセージを運び、制御フレームは設定、フロー、および接続状態を管理します。

同時実行性とマルチプレクシング

HTTP/1.1 接続は通常、レスポンスの順序を保持するため、クライアントは並列性を得るためにいくつかの接続を開くか、慎重に制御されたパイプラインを使用します。各追加接続には設定とインフラコストがあり、ブラウザはどれだけ積極的にこれらを使用するかを制限します。

HTTP/2 は1つの TCP 接続上でストリームをマルチプレクシングします。遅いレスポンスは、フレームがインタリーブできるため、HTTP レイヤーで後のレスポンスをブロックする必要がありません。 HTTP/2 仕様 は、受信者が飛行中のデータ量を制限できるように、ストリームごとの接続フロー制御も定義します。

HPACK を使用したヘッダー圧縮

ウェブリクエストは、クッキー、ユーザーエージェント、コンテンツタイプ、およびキャッシュディレクティブなど、フィールド名と値を繰り返します。HTTP/1.1 は、それぞれのリクエストでテキスト形式を送信し、他の圧縮は異なるレイヤーでのみ適用されます。

HTTP/2 は HPACK を使用して、静的および動的テーブルを使用してヘッダーリストをエンコードします。繰り返しの値はコンパクトな参照になることができ、敏感なフィールドはインデックス化を避けるためにマークされる場合があります。圧縮状態は接続に属するため、中間者はプロトコルに参加せずに任意のストリームを単純に接続できません。

TCP ヘッド・オブ・ラインの挙動

HTTP/2 は HTTP メッセージ間の順序の圧力を解決しますが、すべてのストリームは依然として1つの信頼できる TCP バイトストリームを共有します。TCP セグメントが失われた場合、ギャップが修復されるまで後のバイトを HTTP/2 レイヤーに配信できないため、無関係なストリームが一緒に一時停止する可能性があります。

この違いは、マルチプレクシングが魔法でなく貴重である理由を説明します。クリーンで低遅延のパスでは、1つの温かい接続が効率的です。損失の下では、アクティブなストリームのグループが停止を共有する場合があります。HTTP/3 は、損失修復をストリームによって分離できるようにするためにトランスポートマッピングを QUIC に変更します。

互換性と交渉

HTTPS クライアントは、TLS ハンドシェイク中に ALPN を使用して一般的に HTTP/2 を交渉します。両方の側がそれを選択した場合、アプリケーションは HTTP/2 を使用します。それ以外の場合は、HTTP/1.1 で続行できます。これにより、デプロイメントは主にエッジ、サーバー、およびクライアントの構成タスクとなり、API の再設計ではなくなります。

古い中間者や専門のクライアントは HTTP/1.1 のみをサポートしている場合があります。フォールバックを健康に保ちながら、正しいホストと権限のルーティングを保持し、観測ツールが交渉されたバージョンをデコードできることを確認してください。 MDN の HTTP 進化ガイド は、バージョンをそのデプロイメントコンテキストに配置します。

HTTP/2 が最も役立つ時

HTTP/2 は、多くのリクエストを同じオリジンに発行するページや API、膨大なヘッダーセットを繰り返す、または接続セットアップのオーバーヘッドに苦しむ場合に役立つ傾向があります。また、サーバーにフロー制御とキャンセルのためのより明確なストリームモデルを提供します。

単一の大きなダウンロードはあまり利点を見ないかもしれません。優先順位が不十分、アプリケーションハンドラーが遅い、キャッシングが欠如している、大きすぎるコンテンツ、または過負荷のオリジンがプロトコルの利点を支配することがあります。HTTP/2 のみにパフォーマンスの変化を割り当てる前に、交渉されたプロトコル、ファーストバイトまでの時間、転送時間、接続再利用、損失、サーバーの飽和状態を測定してください。

HTTP/1.1対HTTP/2検証プラン

HTTPセマンティクスは安定に保たれる。アプリケーションは通常、HTTP/2のためにルートやメソッドを再編成しない。その主張を完全な製品パス全体で検証する。小さな代表的な交換から始め、クライアントとエッジでの交渉された動作を記録し、アプリケーションが同じゲートウェイ、プロキシ、証明書終端ポイント、および実際のトラフィックで使用されるネットワークポリシーを通じて期待するフィールド、フレーム、またはイベントを受信することを確認する。

最初の設計仮定を失敗演習に変える：TLSエッジでHTTP/2を有効にする。その後、2番目の仮定の周りのリソースプレッシャーを調査する：HTTP/1.1のフォールバックがテストされていることを確認する。正しい実装は、文書化された制限内で失敗し、接続およびバッファの状態をリリースし、資格情報やプライベートペイロードを露出することなく結果を説明するトレースを残すべきだ。

アセットが重いページとAPIゲートウェイは設計の異なる部分を運用するため、互換性テストには該当するトラフィックシェイプの両方が含まれるべきである。現在のブラウザー、非ブラウザークライアント、遅いネットワークパス、および最も古いサポートされた中間者を追加する。バージョン選択、接続寿命、メッセージまたはレスポンスの年齢、キューの深さ、および優先パスとそのフォールバックの閉鎖理由を記録する。

テスト中はセマンティクスとトランスポートを別のレイヤーとしてレビューする。成功した接続は、アプリケーションが順序付け、認証、キャンセル、キャッシング、再送、または状態回復を正しく処理したことを証明するものではない。同様に、アプリケーションエラーは交渉されたプロトコルが失敗したことを証明するものではない。リソース、ユーザーの範囲、論理演算、および接続識別子で観察をタグ付けし、各エンドポイントが何が起こったと考えたかを比較する。この分離により、容量作業がより有用になる：チームはレイテンシーが接続セットアップ、ネットワーク配信、キューイング、アプリケーション処理、シリアル化、または遅い受信者から来るかを確認できる。ルーチンのテレメトリからプライベートなコンテンツを除外しながら、決定を再現するのに十分なタイミングと結果データを保持する。

HTTP/1.1とHTTP/2が実際に現れる場所

HTTP/1.1対HTTP/2製品チェックリスト

• TLSエッジでHTTP/2を有効にする。 このポイントを文書化された受け入れテストに変換し、レビュアーが意図された動作を偶発的な実装の詳細から区別できるようにする。
• HTTP/1.1のフォールバックがテストされていることを確認する。 設定を所有するコンポーネントの名前と、その観察された動作が変更された場合に応答する人またはチームの名前を付ける。
• 診断でALPN交渉を確認する。 関連する信号をログまたはトレースにキャプチャし、その信号が実際のパスのすべてのプロキシ、ゲートウェイ、およびサービス境界を超えて生き残ることを確認する。
• 古い接続制限のためだけに追加されたドメインシャーディングを削除する。 通常のケース、遅いピア、閉じた接続、オーバーサイズの入力、およびバージョンまたは機能の不一致で決定をテストする。
• オリジンごとのリクエストの並行性を測定する。 安全なデフォルトと例外を許可する正確な条件を文書化する；隠れた例外は後の変更中に相互運用問題を生じる。
• ストリームと接続のフロー制御ウィンドウを監視する。 ローカルユニットテストやサーバーサイドの設定画面だけに依存せず、代表的なブラウザーまたはクライアントからこの動作を確認する。
• ヘッダーサイズを文書化された制限内に保つ。 有限のリソース制限を設定し、その結果としての拒否をオペレーターと呼び出しアプリケーションの両方に見えるようにする。
• バイナリフレームを使用して中間者を検証する。 クライアント、エッジ、アプリケーション、および任意の非同期ワーカー間で1つの論理交換を相関させるのに十分な識別子を保持する。
• マルチストリームのスタルとパケット損失を相関させる。 トラフィックシェイプが変化した後に選択をレビューする。接続カウント、ペイロードサイズ、およびメッセージの頻度は、正しい設計に影響を与える可能性がある。
• 展開前後の実際の作業負荷を比較する。 フォールバックパスが観測可能でテストされていることを確認し、互換性が静かに機能を停止した古いパスに依存しないようにします。

結論

HTTPセマンティクスは安定したままです。アプリケーションは通常、HTTP/2用にルートやメソッドを再構築しません。HTTP/2は普遍的な速度保証ではありません。ペイロードの形状、レイテンシ、損失、サーバーの調整、およびキャッシングが結果を決定します。これら2つの事実を明示的な制限、観測可能な状態、および設定から仮定するのではなく、代表的なクライアントによってテストされたフォールバックとともに適用します。

参考文献

• Scrapeless Scraping Browserのドキュメント
• Scrapeless Scraping Browserの製品概要
• Scrapeless WebSocketフレームキャプチャガイド