プログラミング言語を勉強したことがある人なら誰でも経験していることだが，雑誌や書籍の解説を読むだけでなく，実際に自分でプログラムを作ってみると理解は数段深まる。読んだときにはわかったような気になったものでも，案外わかっていないことが多く，自分で試してみることで，あやふやな理解が本物の理解に変わっていくからだ。インターネットを始めとしたネットワーク技術でもこれを同じことが当てはまる。実際に試してみることによって理解が深まるのだ。
　案ずるより産むが易し，ということわざがあるが，仕様書や解説書を読んで勉強するより，実際に試してみた方が手っ取り速く理解できることも多い。また，本で得た知識は時間が経つと忘れてしまうが，自分で試してみたことはなかなか忘れない。
　このように，自分で試してみることにはいろいろなメリットがある。だから，とにかくいろいろと試してみよう，というのがこの連載の趣旨だ。

　初回は，まず手始めとしてHTTPというプロトコルの基本的な枠組みを実験を通して調べてみることで，WWWの仕組みを理解するところから始める。
　WWWはブラウザからサーバにページ読み出しのリクエストを送り，サーバがそれに応えてページデータを返すものであり，そのリクエストやページデータを運ぶときに使うのがHTTPである。こういった概念的な説明は雑誌や書籍などに書いてあるのだが，HTTPというプロトコルがどのような考え方で作られたもので，サーバとブラウザの間で具体的にどのようなやり取りが行われるのかというところまで書いてあるものは少ない。しかし，その具体的な仕組を知らないと概念的な理解を超えることができない。
　ユーザの立場であれば概念的な理解だけでもよいが，実際にシステム構築を担当する技術者がそれでは心もとない。WWWがどういった仕組みで動いているのかを正確に理解できなければ，障害が起こっても自分で原因を究明できないし，対策も立てられないからだ。ファイアウォールやプロキシサーバを使う場合のように，システムが複雑になると，それが顕著になる。
　また，HTTPはWebサーバからページデータを読み出したりするときに使うものだったが，最近はそれ以外の用途にも使われるようになっている。データベースをアクセスしたり，音声や動画データを配信するものがその例だが，こうした使い方が登場してきた理由はHTTPという仕組みそのものを知らないとなかなか理解できないし，仕組みが理解できなければ応用することもできない。
　こういった説明をすると難しく感じるが，そこが案ずるより産むが易しなのだ。実際のHTTPの仕組みはそれほど難しくないし，難しいことだったらこれほど普及するはずもない(*1)。だから，試せばわかる。

Webサーバのセットアップ

　では，実験を始めるが，本番で使っているシステムを使って実験するのは恐いので，実験システムを用意するところから始めることにしよう。といっても今回はWebサーバをセットアップするだけである。手元に実験用として使えるWebサーバがあれば，それを使ってもよい。
　最近のOSには，Webサーバが含まれているものが多く，セットアップ時にオプションを選択しておけば，OSと一緒にWebサーバがセットアップされる。今のWindowsはそうなっているし，それ以外のOSも似たようなものである。
　OSのセットアップ時にWebサーバをセットアップしていなくても大丈夫だ。後でWebサーバだけを追加してセットアップすることもできる。その場合は，最新版をインターネットからダウンロードして，セットアップした方が良いかもしれない。マイクロソフト社のWebサーバの場合は，http://www.microsoft.com/windows/downloads/から最新版が入手できる。UnixなどではApacheというWebサーバを使用することが多いが，それはhttp://www.apache.com/から最新版をダウンロードできる。
　Webサーバには製品やフリーウェアなどいろいろなものがあるが，今回の実験では基本的な機能しか使わないので，どれを使っても良い。必ずしも最新版である必要もない。セットアップに手間取るようだと時間の無駄なので，簡単にセットアップできるものを選んだ方がよい。
　Webサーバによって違いはあるが，ほとんどのものはセットアップ用のプログラムなどを使ってセットアップするとそのまま動いてしまう。無難な値がデフォルトの設定値として予め設定されているからだ。細かな設定項目もあるが，最初はセットアッププログラムが設定してくれるデフォルトの設定でWebサーバ動かしてみよう。設定をいじるのはその後だ。
　これはWebサーバのセットアップに限ったことではなく，どんな作業にも当てははることだが，作業が終わったらそれが意図した結果に終わっているかどうかを確認することが重要だ。確認せずに先に進むと，異常に気づいたところから後戻りしなくてはならなくなる。変更した個所を正確に覚えていればまだよいが，それすらあやふやになってしまうことも多いから，そうなると，設定を変更したことが異常の原因なのか，セットアップ作業自体が異常だったのか判別できなくなる。下手をすると，セットアップ作業のやり直しが必要になることもある。だから，設定を変更する前に，セットアップが正しく終了したかどうか確認するのである。
　確認方法は簡単だ。ブラウザでWebサーバのホームページを読み出してみればよい。WebサーバがDNSに登録されていなければ，IPアドレスを指定すればよい（図1）。これで，ホームページが表示できれば，Webサーバのセットップは正常に終わっている。

telnetで接続

　Webサーバが動き始めたら実験開始だ。まず，telnetというプログラムを使ってWebサーバに接続してみよう。
　そもそも，telnetを使ってWebサーバに接続する，ということはどういうことなのか。そこが疑問かもしれない。そういった疑問がわき起こることが本連載の狙いの一つでもある。telnetの話題は本題から外れるので囲み記事に簡単にまとめておくが，要するにtelnetを使えば相手と文字データを送受信できる。それで，Webサーバに文字データを送り，Webサーバがどういう反応を示すかを観察しようというのだ。実は，WebブラウザでWebサーバにアクセスする場合も，両者の間で交換されるデータは文字データが基本となっている。Webブラウザではその文字データのやり取りが直接見えないので，telnetでやり取りの様子を直接観察しようというのがtelnetを使う意味である。そうして，やり取りの様子を直接見れば，WWWやHTTPの仕組みがよくわかるというわけだ。
　接続操作は図2のように行う。ここで指定する項目はWebサーバのIPアドレスとポート番号だ。ポート番号というのは相手のコンピュータ内で動いているプログラムを選ぶためのものだ（図3）。普通，コンピュータの内部には多数のプログラムが動いているから，IPアドレスを指定するだけでは，その中のどのプログラムと接続すればよいのかが判別できない。そこで，どのプログラムと接続したいのかを相手に知らせるための仕組みが必要となる。その仕組みがポート番号なのである。telnetは接続操作のときにポート番号を指定しないと，telnetdという端末制御プログラムのポート番号を使うようになっているので，接続時にポート番号を指定してWebサーバに接続する。それが図2の操作だ。80というポート番号はWebサーバのデフォルトのポート番号である。Webサーバの設定によって80以外のポート番号を使うこともできるので，Webサーバ側が80以外のポート番号を使うように設定されている場合は，その番号を使うようにする。
　そうして接続すると，telnetのウインドウタイトルが図2の下のように変わるはずだ。ウインドウの中には何も表示されないがそれでかまわない。Webサーバはクライアントからの処理要求を受け取って，その要求に従って処理を実行するので，こちら側から要求を送らなければ何もしない。だから，telnet画面に何も出てこないのだ。

ホームページの読み出し

　Webサーバは処理要求が来るのを待っているわけだから，それをこちらから送ってみよう。処理要求はHTTPではリクエストと呼び，書式が決められているが，細かことは後回しにして，とりあえず図4aのようにタイプしてみよう。ここでタイプしたものが処理要求となってWebサーバに送られる。
　このとき，telnetのターミナル設定オプションを設定して，ローカルエコーをオンにしておく。ローカルエコーをオンにしないと，タイプした文字が画面に出てこないので，正しくタイプできているかどうかも確認できないからだ。とはいっても，タイプミスしたからといって，バックスペースで修正することはできない。HTTPの仕様ではリクエストの途中にバックスペースというデータが入ってくることを想定しておらず，フォーマットエラーになってしまうからだ。タイプミスしたら一度切断し，もう一度接続操作からやり直さないといけない。
　リクエストの文字列をタイプし終わったら，改行キーを2回押す。すると，画面に何か表示され，telnetは切断されるはずだ。もし，何も表示されなかったら，一旦切断してもう一度接続からやり直さないといけない。そして，改行キーの代わりに，CTRL-Jを使ってみよう。telnetのバージョンによっては改行キーを押したときに送信する文字コードに違いがあるからだ。CTRL-Jならどんなバージョンでも同じコードを送信してくれる。それから，英文字はすべて大文字を使うこと，そして，タイプミスがないかどうかも確認しよう。
　これで表示されたものがホームページのデータである。セットアップした直後のホームページのデータはWebサーバがデフォルトで用意してあったものだが，多分，データ量が多く，あっという間に最初の方が消えてしまい，データの最後の方しか画面に残らないだろう。それではよくわからないので，ホームページのファイルを図5aのようなものに置き換えてみる。
　そして，もう一度，Webサーバに接続して図4aのリクエストを送ってみる。すると，今度は置き換えたファイルの内容が表示されることがはっきりとわかるだろう（図5b）。

HTTPの基本動作

　最初の実験はこれで終わりだ。これで，HTTPという仕組みの骨格がわかる。
　今の実験をおさらいすると，まず，telnetからWebサーバにリクエストを送り，Webサーバがその内容に従って処理し，その結果をtelnetに送り返してきたことになる。HTTPの用語ではこれをレスポンスという。簡単ではあるが，これがHTTPとWebサーバの基本動作だ(*4)。ネットワークのプロトコルというと複雑なものと思っている人もいるが，HTTPの場合の基本はこれだけである。
　このように，サーバに対してリクエストを送り，サーバがそれを処理して結果を返す，という動作モデルをクライアントサーバモデル（C/Sモデル）と呼ぶ。だから，HTTPの基本的な仕組みはC/Sモデルだともいえる。telnetは端末用ソフトなのにクライアントサーバモデルというのはおかしいと感じたら，それは本質を見誤っている。telnetは端末用に作られたものではあるが，この実験のようにサーバに対してリクエストを送るという用途に使えば，その役割は端末ではなくクライアントになってしまう。使い方によって役割は変わるのだ。また，Webサーバのクライアントはブラウザだと固定して考えるのもよくない。自動巡回ソフトなどもWebサーバのクライアントとして使えるのだから，ブラウザだけがクライアントとなるわけではないのだ。
　HTTPという仕組みの用途もWWWだけに固定して考えてはいけない。HTTPのベースとなっているC/Sモデルはシンプルであるにも関わらず，サーバ側で用意しておく機能次第でいろいろな用途に応用できる。この性質のため，今のネットワークシステムは何らかの形でこの動作モデルを使っているものが多い。データベースサーバを使ったいわゆるC/SシステムがC/Sモデルを使う代表格だが，それだけでなく，ファイルサーバへのアクセス，メールサーバやニュースサーバからのメッセージのメール読み出しなどにもC/Sモデルは使われている。むしろ，このモデルを使っていないものの方が少ないくらいだ。そのC/Sモデルをベースにしているのだから，HTTPの適用範囲も当然C/Sモデルと同じように広い。WWW以外にも使える理由はここにある(*5)。

実験で使ったリクエストの意味

　HTTPはリクエストとレスポンスによって処理を進めるのだから，リクエストとレスポンスの内容を理解することが一番重要だ。最初は実験でサーバに送ったリクエストの意味から説明しよう。
　リクエストの最初にある"GET"はページを読み出すという意味のコマンドを表している。HTTPの仕様ではコマンドのことをメソッドと呼び，それがリクエストの先頭にあるものと決められている。なお，HTTPのバージョンによって異なるが，メソッドには表1のようなものがある。
　次の"/"は読み出すファイルを指定するものだ(*6)。正確にいうと，ここはURI（Uniform Resouce Identifier）という考え方に基づいてファイルを指定するのだが，URIはHTTPだけでなく他のインターネット技術とも関わってくるものなので別の機会に説明する。ここではファイルのパス名だと思えばよい。"/"というのはUnix流の表記法を用いたもので，ルートディレクトリを表している。これだけではファイルを指定したことにならないが，Webサーバにはファイル名を省略したときのためにデフォルトのファイル名が設定できるようになっており，この例のようにディレクトリだけが指定され，ファイル名が省略された場合は，そのデフォルトのファイル（デフォルトドキュメント）を読み出すようになっている。index.html，default.htmといった名前のファイルがそれだ。だから，ルートディレクトリにあるデフォルトドキュメント，すなわち，ホームページが出てきたのである。また，ここでいうルートディレクトリはコンピュータの本当のルートディレクトリではない。Webサーバに設定されている，公開用ディレクトリのことである。これはWebサーバの設定によって変わるので，"/"という指定で読み出されるファイルはサーバ側の設定次第である。
　次の"HTTP/1.0"はHTTPプロトコルのバージョン番号だ。HTTPには0.9，1.0，1.1という三つのバージョンがあり，今普通に使われているのは1.0と1.1である。最新版は1.1だが，1.0の方がシンプルなので，この実験では1.0を使うことにする。
　リクエストの後に空白行が一つあるが，これがリクエストの終了を表している。そして，その後に続くのが，サーバからのレスポンスである。

表1 HTTPのメソッド

○：仕様として定義されているもの。△：正式な仕様ではなく付加機能としてAppendixに記述されているもの。

レスポンスの意味

　レスポンスの最初の行はステータスラインというもので，処理結果が正常だったか何らかの異常があったか，といった結果の状況を表すものだ。そのフォーマットは，行の最初にHTTPのバージョンがあり，次にステータスコード，最後に理由を表す文字列となっている。ステータスコードは3桁と決められており，左端の桁で概要がわかるようになっている（表2）。エラーが発生すると図6のようにエラーメッセージが表示されるが，そこに出てくる番号がステータスコードである。
　次の行からServer:...，Date:...，というように":"で区切られた，<フィールド名>:<フィールド値>という形式の行が6行ほど続いている。この行の一つ一つがいろいろな付加的情報を表すもので，その個々をHTTPの仕様ではヘッダフィールドと呼ぶ。このヘッダフィールドはレスポンスだけでなく，リクエストにも付加される。telnetだとタイプするのが面倒だから省略したが，ブラウザからWebサーバにリクエストを送ると，リクエストにもヘッダが付加され，ブラウザのバージョンなどの情報をサーバに通知できるようになっている。この内容はサーバやクライアントの動作にも影響する重要なものだが，ひとまずレスポンスの全体像を見るために，説明は省略する（表3）。
　次に，また1行空白行がある。これがレスポンスの制御情報の終わりを表す。リクエストのときも空白行が終わりを表したが，それと同じである。
　そして，その後に続く<html>から</html>までの行が読み出したファイルの中身である。HTTPではこれをエンティティと呼ぶ。ブラウザでWebサーバにアクセスすると，この部分がHTMLのタグのルールに従ってレイアウトされて画面に表示されることになる（図5c）。
　実験ではファイルの中身にいわゆるHTMLドキュメントを入れておいたが，ファイルの中身はHTMLドキュメントである必要はない。テキストファイルでもよいし，画像ファイルや音声のデータファイルやプログラムの実行形式のようなバイナリデータが入っているファイルでもよい。要するに，何でもよいのだ。HTTPはファイルの中身をそのまま送るだけである。そして，ファイルの中身がどういうデータであるのかを，ヘッダのContent-Typeというフィールドに格納する。実験ではファイルの中身がHTMLドキュメントだったので，これが"text/html"となっているが，テキストファイルであれば"text/plain"となるし，画像データなら"image/gif"や"image/jpeg"となる。(*7)。
　また，レスポンスに付加されるヘッダフィールドはWebサーバによって異なる。いろいろなバージョンのWebサーバで試してみると，その違いがわかる。これが結構面白い。

表2 HTTPのステータスコードの概要

表3 HTTPで使われるヘッダフィールド

○：仕様として定義されているもの。△：正式な仕様ではなく付加機能としてAppendixに記述されているもの。

ブラウザとサーバの役割

　こうして，HTTPの基本的な仕組みがわかると，Webサーバとブラウザの役割も自ずと見えてくる。
　ブラウザはURLの入力欄にURLが入力されたり，HTMLドキュメント中に埋め込まれたハイパーリンクがクリックされたときに，それをHTTPのGETというメソッドを使ってサーバにリクエストを送る。すると，サーバはそのリクエストの内容を調べて指定されたファイルを読み出し，それをHTTPのレスポンスとしてブラウザに返す。レスポンスを受け取ったブラウザはHTMLドキュメントのタグを調べて，ドキュメントをレイアウトして画面に表示するのだ。
　ドキュメント中に画像などが埋め込まれている場合はどうだろう。HTTPではURIは一つしか指定できないから，文章と画像を一度にリクエストすることはできない。そこで，まずHTMLで書いた文章をリクエストし，それを受け取ってから中に埋め込まれた画像を調べ，それをサーバにリクエストするのである。ブラウザはHTMLドキュメントの受信が終わる前に，受信した部分に埋め込まれた画像を調べ，それをリクエストする。これを受信動作と並行して実行する。見かけ上は文章の表示と画像の表示が同時に行われるが，その内部ではこのような仕掛けでサーバとのやり取りが行われているのだ。
　こういった仕組みがわかると，個々の技術要素がどのように関連して全体のシステムができあがるのかがわかる。逆にいえば，個々の技術要素を理解しなければ，システムの具体的な動作は見えてこないのである。

　WWWの使い方は単純なページの表示だけでなく，フォームによってデータをサーバに送信したり，バックエンドのデータベースと連動したり，掲示板のように定期的に表示するページを更新したり，ページプロキシサーバやファイアウォールを使ったり，自動巡回ソフトでWebサーバからページデータを一括ダウンロードしたり，といったようにいろいろなバリエーションがある。今回は単純なページ読み出しの，しかも，そのさわりの部分しか試せなかったが，そうしたバリエーションはまた別の機会に試してみたい。
　次回以降も，このような形で実験を通してインターネットやネットワークの技術を紹介していく予定だ。

(*1)
過去の経験では，難しい技術は製品開発や技術サポートなどあらゆる部分でコスト高になり，結局普及しないことが多い。もちろん例外もある。

(*2)
確かに，RFCの中には分厚く難解なものもある。それは，書いてある技術の内容自身が複雑で難解なのが原因であることが多い。そういった技術は，結局，他の解説書を読んでもすぐには理解できないので，時間をかけて少しずつ理解していくしかない。

(*3)
telnetは画面スクロール，カーソル移動，文字の反転や高輝度表示といった画面制御コードを受け付けることもできるが，そうした画面表示の変化によって，相手からのデータを判読するのは難しい。また，そういった制御コードは，接続相手がその意味で使っているとは限らない。だから，端末として使う本来の用途以外では文字データ以外のデータの受信は実用性がないといえる。また，telnetからデータを送信する場合，CTRLキーと一緒にアルファベットキーを押すと，制御コードを送信することもできる。たとえば，CTRLとAを一緒に押せば，16進表記で'01'のデータを送信できるし，CTRLとBを押せば'02'を送信できる。C以降も同様だ。しかし，それで送信できるデータには限りがあるので，自由にバイナリデータを送信できるわけではない。やはり文字データ以外は限界がある。

(*4)
もちろん，プロキシサーバやファイアウォールを使うといった，バリエーションもあるから基本動作だけがすべてではない

(*5)
HTTPはプロキシサーバやファイアウォールを考慮して作られている点が特徴であり，また，プロキーサーバやファイアウォールもHTTPに対応していないものはない。だから，そうした環境でC/Sモデルを実現する際にはHTTPが便利だといえる。それがHTTPを使用する例が増えている理由といえる。

(*6)
CGIプログラムのようにプログラムを呼び出したりするものもあり，ファイルを指定するものだとは限らない。しかし，そこまで考えると複雑になるので，今回はファイル以外のものは考えないことにする。

(*7)
このデータの種類を表す方法には，メールでも使われるMIMEという仕様が使われる