HTTP/1.1 vs HTTP/2

テキストメッセージとバイナリフレームは同じ処理を表現する

HTTP/1.1 はリクエストラインまたはステータスライン、フィールド、およびメッセージボディのフレーミングからなるテキストベースのメッセージ構造を使用します。 HTTP/1.1 メッセージ仕様 は、受信者がそれらのメッセージをどのようにパースし境界を判断するかを定義しています。永続的な接続により、1 本の接続上で複数のリクエストを扱うことができます。

HTTP/2 は通信をバイナリフレームとストリームで表現します。 HTTP/2 フレーミングおよびストリーム仕様 は、メッセージがその構造へどのようにマッピングされるかを定義します。バイナリ表現によってアプリケーションの値がより正しくなるわけではなく、プロトコルがそれらをどのように転送するかが変わるだけです。

表現の境界をアプリケーションペイロードから切り離して考えてください。JSON レスポンスはどちらのバージョンでも転送できます。その JSON のパースエラーは、単にワイヤ上に HTTP/2 フレームが存在することだけでは説明できません。トランスポートのフレーミング、表現のデコード、ビジネススキーマの検証をそれぞれ独立した段階として診断し、それぞれ独自の観測可能な結果を持たせてください。

マルチプレキシングは HTTP レベルのレスポンス順序制約を軽減する

HTTP/2 のマルチプレキシングにより、異なるストリームのフレームが 1 本の接続を共有できます。大きなレスポンスは、他のストリームが進行する前にアプリケーションレベルのレスポンスシーケンス全体を占有する必要はありません。HTTP/1.1 では、1 本の接続上でパイプライン化されたレスポンスはリクエスト順に従う必要があり、クライアントは一般的に同時処理のために複数接続を使用します。

この違いは、同じオリジンから複数のリソースを要求するワークロードに役立つ可能性があります。とはいえ、無制限の並列処理が無料になるわけではありません。サーバーは制限を告知し、ストリームはトランスポート容量を共有し、アプリケーション自身にもボトルネックがあるかもしれません。クライアントとサーバーのフロー制御と同時実行の挙動を尊重してください。

コレクターにとっては、HTTP の同時実行性とビジネスタスクの同時実行性を切り分けて考えてください。複数のストリームが素早く完了しても、それらが供給する抽出ステージやデータベースステージが追いつけない場合があります。同時作業を増やす前にキュー経路全体を計測してください。詰まった処理ステージにより早くデータを届けても、有効レコードの処理速度を改善しないままメモリプレッシャーを高めることがあります。

HPACK はレスポンスボディではなくヘッダーを圧縮する

HTTP/2 は HPACK を使用してヘッダーフィールドを効率的にエンコードします。 HPACK ヘッダー圧縮フォーマット は、静的テーブルと動的テーブル、およびエンコード規則を定義します。繰り返し現れるヘッダー情報は、同じテキストフィールドを何度も送信するよりもコンパクトに表現できます。

ヘッダー圧縮はレスポンスボディの圧縮とは別物です。サーバーは、ヘッダー表現とペイロードエンコーディングの違いに関係なく、コンテンツエンコーディングを通じて HTML や JSON を圧縮できます。転送バイト数を計測する際は、それぞれのレイヤーを個別に比較してください。

すべてのレスポンスが同じように恩恵を受けると仮定しないでください。大きな共通ヘッダーを持つ小さな繰り返しリクエストは、再利用可能なヘッダーがほとんどない大きなレスポンスボディとは異なる特性を持ちます。中間装置が接続を変更した場合、圧縮コンテキストは経路全体に自動的に引き継がれるのではなく、その接続に属します。測定した区間を追跡し、バイト節約分を1つの機能だけに帰属させないようにしてください。

TCP は依然として HTTP/2 ストリーム間の配信を結合する

HTTP/2 はアプリケーションストリームを多重化しますが、TCP の順序付き配信動作を取り除くものではありません。欠落した伝送データが後続バイトの配信を遅らせると、同じ TCP コネクション上の複数のストリームが影響を受ける可能性があります。これが、アプリケーションレベルの多重化とトランスポートレベルのヘッドオブライン動作について、別々の説明が必要な理由です。

影響はネットワーク状況とワークロードによって異なります。多くの小さなリソースを運ぶ安定した接続は、容量共有から大きな利益を得る場合があります。損失が発生している接続では、異なるトレードオフが現れます。どちらの観測結果も、あるプロトコルが常にあらゆる経路で勝ることを証明するものではありません。

遅いリクエスト1つだけからトランスポートの問題を診断するのは避けてください。ネゴシエートされたバージョン、接続再利用、各タイミング段階、および利用可能な場合は関連するサーバー側の観測値を収集しましょう。遅いアプリケーションクエリ、遅延した DNS ルックアップ、トランスポート損失はいずれも経過時間を増加させますが、必要とされる対処は異なります。測定によって実際に得られた証拠に結論を限定してください。

HTTP セマンティクスと TLS は別のレイヤー

HTTP メソッドやステータスの意味はバージョンをまたいで適用されます。 バージョン非依存の HTTP セマンティクス が共通のモデルを提供します。HTTP/2 へ切り替えても、不正な資格情報が解決されるわけでも、禁止されたリソースが許可されるわけでも、レスポンスボディの内容が期待どおりであることが保証されるわけでもありません。

TLS はさらに別のレイヤーです。HTTPS のデプロイでは、TLS の仕組みを通じて HTTP/2 をネゴシエートすることが一般的ですが、プロトコルのバイナリフレーミング自体は暗号化ではありません。機密性と認証については、バージョン番号を完全なセキュリティ特性として扱うのではなく、関連する TLS とアプリケーション構成に基づいて説明してください。

互換性は、実際のクライアントとデプロイされた経路で確認する必要があります。サーバーが HTTP/2 をサポートしていても、特定のライブラリビルドや中間装置が HTTP/1.1 を使用している場合があります。観測されたプロトコルを環境の詳細とともに保持してください。オリジン側の機能チェックボックスだけでは、特定のリクエストをどのプロトコルが運んだかを証明できません。

プロキシやプロバイダーのワークフローのあらゆる区間をマップする

中間装置は、1 つのエンドツーエンドなバージョンラベルではなく、複数のプロトコル関係を作り出します。クライアントはプロキシや API プロバイダーとあるバージョンをネゴシエートし、そのサービスは別の接続を使って宛先へアクセスしている場合があります。CONNECT トンネルは、プロキシのトランスポートとトンネル内のトラフィックとの間に、さらに別の区別を導入します。

「 Scrapeless Web Unlocker」では、API へのリクエストとプロバイダーによるターゲット取得を区別してください。クライアント接続で観測されたバージョンから、ドキュメント化されていないターゲット側プロトコルの挙動を推測しないでください。 Web データ収集におけるトランスポートレイヤー の議論は、リクエスト経路の各区間を分離するための関連コンテキストを提供します。

プロバイダー利用を計画する際は、最新の Scrapeless 料金 を用い、クライアント接続は個別に計測してください。API の受付ステータスとターゲット取得の結果は、それぞれ異なる境界を表します。ネゴシエートされたプロトコルは、それらどちらかの代わりではなく、並列する別個の観測値として扱ってください。

制御されたワークロードでバージョンを評価する

有用な比較を行うには、要求コンテンツと受け入れ基準を一定に保つことが重要です。クライアントのバージョンと構成、宛先、ネゴシエートされたプロトコル、接続再利用、各段階の経過時間、および測定インターフェースで取得可能なバイト数を記録してください。接続確立と、すでに確立された接続での繰り返しリクエストを分けて扱いましょう。

重要なワークロードを含めてください。単一の API レスポンス、同一オリジンの多くのリソースを持つページ、あるいは収集リクエストのシーケンスなどです。1 つの形状で得られた結果を別の形状へ一般化すべきではありません。遅延を比較する前に出力の完全性を確認し、不完全なレスポンスが「仕事量が少ない」という理由で勝ってしまわないようにしてください。

まずはクライアントがサポートするデフォルト設定から始め、特定の制約を特定してから初めてチューニングしてください。トランスポート指標とあわせて、サーバーの制限やアプリケーション処理を確認しましょう。HTTP/2 を有効化または優先する判断は、互換性や可観測性を損なうことなく、測定されたワークロードを改善するものであるべきです。クライアントやサーバーを更新した後でも比較を再現できるだけの環境情報を保持してください。

結論

HTTP/1.1 vs HTTP/2 の議論は、特定の接続とワークロードに結び付けてこそ有用です。フレーミング、多重化、ヘッダー圧縮を理解したうえで、デプロイされたクライアントの経路を計測してください。TCP の挙動、TLS、プロバイダーの境界、アプリケーションの正当性は分けて考えましょう。プロトコルバージョンはトランスポートに関する証拠であり、有効なレスポンスはタスクに関する証拠である、という関係です。

参考文献

• Web Unlocker API 取得境界
• Scrapeless Web Unlocker
• Webデータワークフローにおけるトランスポート層