HTTPは至るところで使われています。テレビも、スマートフォンも、タブレットも、自動車もHTTPで通信します。ネットワークに接続するデバイスなら、おそらく皆さまが母語を話すのと同じくらい流暢にHTTPを使いこなしています。

HTTPは柔軟性に富んでいます。ネットワーク上で隣り合うTCPやIPとは異なり、ポイントAからポイントBへ伝送できる情報には、ほとんど制限がありません。IPとTCPでは、使用可能な値がビット単位で定義された非常に厳格で融通の利かない標準に従う必要がありますが、HTTPは伝送するデータに対して自由度の高いアプローチを採用しています。テキスト。バイナリ。JSON。XML。暗号化データ。プレーンテキスト。
ラーテルのように、HTTPは気にしません。何でも運びます。それ以上のものさえも。
HTTPがその名のとおり柔軟性を発揮する仕組みの1つが、ユーザーの目に触れることの少ないヘッダーです。これは、すべてのHTTPリクエストとレスポンスに含まれるメタデータです。コンテンツタイプやコンテンツ長、認証トークンから、ユーザーが誰でどこにアクセスしたかを明かす痕跡まで、望むと望まざるとにかかわらず、あらゆる情報を伝えます。
これは重要な点です。コンテナ分野で見られるように、HTTPヘッダーは、クライアントとサービス間でデータを転送する仕組みとしてだけでなく、変化の速い環境を極めて効率的にスケールさせるメタデータを共有する手段としても、利用が拡大しているためです。
サービスメッシュという概念と、それに伴う運用情報を伝達するカスタムHTTPヘッダーの追加が、ますます注目されています。こちらのBuoyantのブログでは、主要な2つのオープンソースのサービスメッシュ実装のうち1つを開発する同社が、単一のHTTPリクエストとレスポンスのペアを構成する、サービス間の極めて複雑な一連のトランザクションを把握しやすくするトレースの相関付けに必要なテレメトリの共有が、HTTPヘッダーに依存していることを示しています。
前述のブログをすべて読む時間がない方のために、最も関連性の高い箇所を以下に抜粋します。強調は筆者によるものです。
Buoyantでは、linkerdが提供する追加のトレースデータをすべて「マイクロサービスに振りかける魔法のテレメトリ」と表現していますが、実際には、トレース同士を関連付けるために少量のリクエストコンテキストが必要です。このリクエストコンテキストは、linkerdがリクエストを受信した時点で確立されます。HTTPリクエストの場合、linkerdがアプリケーションにリクエストをプロキシする際に、HTTPヘッダーを介して渡されます。アプリケーションでリクエストコンテキストを維持するには、受信したすべての「l5d-ctx-*」HTTPヘッダーを変更せずに、アプリケーションが送信するすべてのリクエストに含める必要があります。
ここで言及したカスタムHTTPヘッダーは、このような高度に分散されたシステムでテレメトリを共有するために使用される複数のヘッダーの1つにすぎない点に注意が必要です。ブログに記載されているように、l5d-sampleヘッダーを使用してトレースのサンプリングレートを調整できます。つまり、このヘッダーは情報の共有だけでなく、システムの運用制御にも使用されます。
この点について、少し考えてみてください。HTTPヘッダーは、運用システムの動作を制御するために使用されています。このことを覚えておいてください。数段落後に重要になります。
この場合、コントロールプレーンとデータプレーンを分離するのではなく、両方を同時に転送し、エンドポイント側で、いわば形式と機能を切り分けます。このソリューションは、サービスから送受信されるすべてのリクエストがプロキシを経由するサービスメッシュの概念に基づいているため、これは容易に実現できます。プロキシは、運用制御用のHTTPヘッダーをフィルタリングしてその指示を実行した後、リクエスト(またはレスポンス)を本来の宛先に転送できます。また、運用上の指示を追加したり、後でトレースを対応付けるためのテレメトリを挿入したりすることもできます。
コンテナ環境でも、アプリケーションネットワーキングが一般的になりつつあります。以前から存在していたものの(少なくとも、プログラマブルプロキシの世界に携わる人々にとっては)、柔軟性へのニーズが高まるにつれ、利用される機会が増えています。Ingress controllerは本質的にプログラマブルプロキシであり、IPアドレスやFQDNだけでなく、一般にHTTPヘッダーで伝達されるアプリケーション固有のデータに基づくルーティングも可能にします。バージョニング、トラフィック制御、スケーリング。Ingress controllerのこうした機能はすべて、HTTPがHTTPヘッダーの内容を問わない仕組みによって実現されています。
残念ながら、HTTPヘッダー自体も攻撃経路になり得ます。そのため、運用データの共有だけでなく、運用動作の制御にもHTTPヘッダーを利用することの影響を慎重に検討する必要があります。HTTPヘッダーは柔軟性が非常に高く(本当に、BNFを読んでみてください)、基本的にすべてテキストベースです。そのため、容易に変更できるだけでなく、悪意のあるコマンドを含むよう細工することも可能です。こうしたコマンドを処理する中間デバイスやエンドポイントのデバイスおよびシステムは増え続けています。
それを恐ろしいと思わないのであれば、問題を十分に認識していないということです。
幸い、HTTPヘッダーをコントロールプレーンとデータプレーンの両方の手段として使用するケースは、主にコンテナ化されたシステムに限られます。つまり、通常は、複数の外部公開された制御ポイントの背後に配置されており、組織はそこで、過度に寛容なHTTPヘッダーの性質がもたらす脅威を軽減できます。セキュアな受信経路(南北方向)を組み合わせたアーキテクチャアプローチにより、悪用に対して必要な保護を実現できます。実際にこれを試みた事例は、まだ確認されていません。しかし、HTTPヘッダーに起因する侵害はすでにあまりにも多く発生しています。後悔するより、用心するに越したことはありません。
HTTPは、アプリ、サービス、デバイスの主要プロトコルとしてだけでなく、テレメトリ、追跡、運用コマンドの伝送にも使われるようになっています。期待が高まる一方で、運用上の惨事を避けるには、「何でもできる」という発想を「ただし、安全に実現しよう」という意識で律する必要があります。
著者について

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事

F5 Application Study Tool:OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版:リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。