1.1 アプリケーション

多くの人はインターネットをそのアプリケーションを通して知る: いくつか例を挙げるだけでも、ワールドワイドウェブ、メール、ソーシャルメディア、音楽や映像のストリーミング、ビデオ会議、インスタントメッセージ、ファイル共有がある。言い方を変えれば、インターネットと関わるとき我々の多くはネットワークのユーザーとなる。インターネットのユーザーはインターネットと何らかの形で関わる人々の中で最も大きなグループを構成するものの、他にも重要なグループがいくつかある。

まず、アプリケーションを作成する人々のグループがある ── スマートフォンなどの新しいデバイスや強力なプログラミングプラットフォームが登場し、アプリケーションを素早く開発して大きなマーケットに届ける新しい機会が生まれたので、近年このグループは非常に大きくなっている。

次に、ネットワークを運用あるいは管理する人々のグループがある ── 主に舞台裏の仕事であるものの、非常に重要で、たいていは非常に複雑な仕事である。ホームネットワークの普及と共に、多少でもネットワークを運用する立場にある人の数はますます増えている。

最後に、インターネットを構成するデバイスやプロトコルを設計そして作成する人々のグループがある。この最後のグループは本書のようなネットワークの教科書の伝統的な対象読者であり、本書でも我々が主に想定する読者であり続ける。しかし本書ではアプリケーション開発者やネットワーク運用者の視点も折に触れて考える。

これらの視点を考えれば、ネットワークが応えなければならない多様な要件をより良く理解できるはずである。さらに、アプリケーション開発者がネットワーク内部の技術およびネットワークとアプリケーションがどう対話するかを理解すれば、より良く動作するアプリケーションを作成できるようになるだろう。そこで、ネットワークの構築方法を考える前に、まずは現代のネットワークがサポートするアプリケーションの分類について詳しく見ていく。

1.1.1 アプリケーションの分類

主に科学者とエンジニアが使う難解なツールだったインターネットを、突如として現在のような社会の主軸へと変貌させたインターネットのアプリケーションがワールドワイドウェブ (World Wide Web, ウェブ) である。ウェブはあまりにも大きなプラットフォームになったためにインターネットと混同されることも多く、ウェブはインターネットのアプリケーションの一つだと主張するには少し勇気が必要になる。

その基本的な形態において、ウェブは直感的に分かりやすいインターフェースをしている。ユーザーが目にするページは文章や画像を表示するオブジェクトが多く集まって構成され、詳しく知りたいオブジェクトをユーザーがクリックすると対応する新しいページが表示される。ページ上で選択可能なオブジェクトにはクリックしたときに表示される別のページあるいはオブジェクトを表す識別子が付いていることを多くの人は知っているだろう。この識別子は URL (Uniform Resource Locator) と呼ばれ、ユーザーのウェブブラウザから閲覧可能な任意のオブジェクトを特定する手段を提供する。例えば

http://www.cs.princeton.edu/~llp/index.html

は本書の著者の一人 (Larry Peterson) に関する情報が載ったページの URL である: 文字列 httpHTTP (Hypertext Transfer Protocol) というプロトコルを使ってページをダウンロードすべきであることを示し、www.cs.princeton.edu はページを提供するマシンの名前を表し、/~llp/index.html は Larry のサイトにある彼のホームページを一意に特定する。

一方で多くのウェブユーザーが気付いていないのは、そういった URL を一つクリックするだけでも 10 を超えるメッセージがインターネットを通してやり取りされ、ウェブページに埋め込まれたオブジェクトがたくさんある場合にはさらに多くのメッセージがやり取りされる事実である。このやり取りにはサーバー名 (www.cs.princeton.edu) を IP (Internet Protocol, インターネットプロトコル) におけるアドレス (128.112.136.35) に変換するための最大 6 個のメッセージ、サーバーとブラウザの間で TCP (Transmission Control Protocol) の接続を初期化するための 3 つのメッセージ、ブラウザが HTTP の GET リクエストをサーバーに送信して要求したページをレスポンスとして受け取る (さらにメッセージの受信を双方が通知する) ための 4 つのメッセージ、そして TCP 接続を終了するための 4 つのメッセージが含まれる。もちろん、この他にもインターネットノードは様々な通信を行う。例えば、自身がウェブページの提供 (サーブ)、ウェブページの名前からアドレスへの変換、メッセージの最終的な宛先に向けた転送を行う準備が整っているノードであることを周りに伝えるためだけに、インターネットノードは一日に数百万のメッセージをやり取りする。

広く使われているインターネットのアプリケーションのもう一つの部類として、「ストリーミング」の音声や映像を配信するアプリケーションがある。例えばビデオ・オン・デマンドインターネットラジオといったサービスがこの技術を使っている。ストリーミングセッションの開始はウェブサイトで行われることが多いのに対して、その後の音声と映像の配信はテキストと画像からなる単純なウェブページの取得とはいくつかの重要な点で異なる。例えば、冒頭の映像を見る前に (数分をかけて) 映像ファイル全体をダウンロードしたい状況はあまりない。音声と映像のストリーミングで送信側は利用される寸前のタイミングでメッセージを送信し、受信側は受信した映像や映像をほぼ間を空けずに再生しなければならない。

音声および映像のストリーミングとそれより伝統的なテキストや画像の配信との違いは、人間が音声や映像を連続的に消費する点、そして不連続性 ── 音声が飛んだり映像が固まったりすること ── が受け入れられない点にある。これに対して、通常の (ストリーミングでない) ページはパーツごとに少しずつ転送されたとしても人間は読むことができる。この違いはネットワークがどのようにアプリケーションをサポートするかに影響する。

これとは少し異なるアプリケーションの部類にリアルタイムな音声および映像のストリーミングがある。この部類に属するアプリケーションはストリーミングアプリケーションと比べてはるかに厳しいタイミング制約を持つ。Skype のようなボイスオーバー IP アプリケーション、あるいはビデオ会議アプリケーションを使うとき、参加者同士の対話に遅延は許されない。ある参加者がジェスチャーをしたなら、その動作は他の参加者にできるだけ早く伝えられる必要がある1

あるいは、ある人物が他の人物の発言を遮ろうとしたとき、発言している人物は遮ろうとする動作をすぐに認識し、発言を止めるか続けるかを判断しなければならない。こういった状況で遅延が大きすぎると、システムが全く利用不可能になってしまう。これとは対照的に、ビデオ・オン・デマンドではユーザーが映像の再生を指示してから最初の画像が表示されるまでに数秒かかったとしても十分だとされる。また、対話的アプリケーションでは音声と映像を両方向に動かせるのが当然とされるのに対して、ストリーミングアプリケーションでは音声と映像を一方向にしか流せない可能性が高い。

ビデオ会議が行えるマルチメディアプリケーション
図 1.
ビデオ会議が行えるマルチメディアプリケーション

インターネットを利用するビデオ会議ツールは 1990 年代初頭から存在したものの、広く使われるようになったのはここ数年のことであり、現在ではマーケットにいくつかの商用製品が存在する。そういったシステムの例を図 1 に示す。ウェブページをダウンロードするだけでも見た目以上に複雑な処理が関わっているのと同じように、ビデオ会議にも様々な処理が関係する。例えばユーザーエクスペリエンスを高めるために比較的小さな帯域のネットワークに合わせて映像を圧縮すること、あるいは映像と音声が同じタイミングで滑らかに再生されるようにすることは、どちらもネットワークとプロトコルの設計者が考えなければならない問題である。本書の後半ではこういった問題をはじめとしたマルチメディアアプリケーションに関連する様々な問題を見ていく。

ウェブからのページのダウンロードとビデオ会議の開催は二つの例に過ぎないものの、インターネットの上に構築できるアプリケーションの多様性を示しており、そしてインターネットの設計が持つ複雑性をほのめかしてもいる。本書の後半では、ネットワークを構築、運用、利用する中で下される重要な設計判断の議論を整理するために、より完全なアプリケーションの分類体系を示す。本書の最後では本節で見た二つの具体的なアプリケーションに再び戻り、その他のアプリケーションと共に、現代のインターネットで可能なことの幅広さを見る。

今のところは、こうして典型的なアプリケーションをいくつか見ておけば、多様なアプリケーションをサポートするネットワークを構築するときに解決しなければならない問題をこれから見ていく準備が整うだろう。


  1. 「できるだけ早く」というのは正確でない...。人間工学の研究によると、電話通話で人間が不満を覚えずにいられるラウンドトリップ遅延の最大値はおよそ 300 ms であり、100 ms 程度の遅延なら問題はないという。 ↩︎

広告