視点: HTTP が新たな細いくびれに

インターネットは細いくびれ (narrow waist) のアーキテクチャを持つと形容されてきた。中間にあるユニバーサルなプロトコル (IP) は多くのトランスポートプロトコルとアプリケーションプロトコル (TCP, UDP, RTP, SunRPC, DCE-RPC, gRPC, SMTP, HTTP, SNMP など) を自身の上にサポートでき、同時に多くのネットワークテクノロジ (Ethernet, PPP, Wi-Fi, SONET, ATM など) の上に自身を実装できる。この一般的な構造はインターネットがユビキタスになる上で非常に重要な役割を果たしてきた: 皆が合意する IP 層を最小限にすることで、その上と下の両方に数千の花を咲かせることができる。現在これはユニバーサルな採用を目指す任意のプラットフォームが採用すべき戦略として広く理解されている。

しかし、これ以外のことも過去三十年の間に起こっている。IP はインターネットが成長する中でいずれ直面すると予想された問題 (セキュリティ、輻輳、モビリティ、リアルタイム応答など) を解決しないことを選択したので、時が経つにつれてインターネットアーキテクチャに機能をいくつか追加する必要が生じた。IP のユニバーサルアドレスとベストエフォートサービスモデルは採用を広げる上での必要条件だったものの、人々が構築しようとするアプリケーションの基礎としては十分ではなかった。

こういった問題の解決法の中には本書でまだ触れていないものもある ── 以降の章ではインターネットが輻輳に対処する方法 (第 6 章)、セキュリティを提供する方法 (第 8 章)、リアルタイムのマルチメディアアプリケーションをサポートする方法 (第 7 章 および 第 9 章) を説明する ── ものの、この機会にユニバーサルな細いくびれの価値と長く運用されるシステムで不可避的に発生する進化が現在どのように折り合いをつけているかを説明しておく: アーキテクチャの他の部分によって進化の基盤として利用される「不動点」はソフトウェアスタックに近い新しい地点に移動し、一言で言えば HTTP が新たな細いくびれとなった。HTTP は誰でも使えるグローバルなインフラストラクチャの一部であり、あらゆるネットワークアプリケーションに欠かせないとみなされている。この移行は短い間に起こったわけではないし、誰かが宣言したから起こったわけでもない (こうなると予想した人々は存在したが)。地球科学と生物学の比喩を使うなら、細いくびれはインターネットの進化とともにプロトコルスタックをゆっくりと上に登っていったのである。

ただし、HTTP だけを新たな細いくびれとみなすのは単純化が過ぎるだろう。実際には HTTP, TLS, TCP, IP が組み合わさって現在のインターネットの共通プラットフォームを形成している:

• HTTP はグローバルなオブジェクト識別子 (URI) と単純な GET/PUT インターフェースを提供する。

• TLS はエンドツーエンド通信のセキュリティを提供する。

• TCP は接続管理、確実なデータ転送、そして輻輳制御を提供する。

• IP はグローバルなホストアドレスとネットワーク抽象化層を提供する。

これらのプロトコルが共通プラットフォームであるとは、次のような考え方が成立することとも言える: 輻輳制御アルゴリズムを独自に開発しても構わないものの、TCP は輻輳制御の問題を非常に上手く解決するのだから、TCP の解決策を再利用するのが理にかなっている。同様に、RPC プロトコルを独自に開発しても構わないものの、HTTP は完全に実用可能な (証明済みのセキュリティを持つ上に、エンタープライズのファイアウォールにブロックされないという追加機能も持っている) プロトコルなのだから、わざわざ車輪を再発明せずに HTTP を再利用すればいい。

これよりは明らかでない点として、HTTP はモビリティに対処する優れた基礎も提供する。もしアクセスされたリソースが別の場所へ移動しているなら、サーバーは HTTP のリダイレクトレスポンスを返して新しい場所をクライアントに伝えることができる。同様に HTTP を使えば、クライアントとサーバーの間にキャッシングプロキシ (caching proxy) を配置し、頻繁にアクセスされるコンテンツの複製を複数の場所から配信できる。こうすることでインターネットの遠い場所とやり取りする遅延が削減される (これらの機能はどちらも第 9.1 節で議論される)。最後に、適応ストリーミング (adaptive streaming) と呼ばれるアプローチを使えば HTTP でリアルタイムマルチメディアを転送することもできる。