世界規模のデジタル図書館をいつも手元に-WWW

　WWW（World Wide Webの略称。単にWebと呼ばれることが多い）は、インターネット上で提供されているハイパーリンクシステムです。ハイパーリンク（hyperlink）とは、文書内に埋め込まれた外部の情報資源への参照情報です。参照先の識別情報や所在情報を特定の記法で記述しているために、コンピュータシステムによって参照先を呼び出したり紹介したりできるようになっています。このようなハイパーリンクの仕組みを利用して様々な文書や情報資源を相互に結び付けた情報メディアをハイパーテキスト（hypertext）、あるいはハイパーメディア（hypermedia）といいます。

　Webシステムを作るためにはハイパーテキストを作成するためのツールが必要となります。ハイパーテキストを作成するためのツールはハイパーテキスト記述言語と呼ばれます。ハイパーテキスト記述言語にはHTML（Hyper Text Markup Language、略称はエイチティーエムエル）やXHTML（Extensible HTML）などの言語があります。それから、他の文書（ドキュメント）への参照（ハイパーリンク）は、URL（Uniform Resource Locator）を埋め込むことで示します。更に、WWWを実現するためには、URLが指し示す場所にあるドキュメントを手元に持ってくるための手法が必要になります。URLが指し示す場所にあるドキュメントをインターネットを使って持ってくるための通信プロトコルをHTTP（Hypertext Transfer Protocol）といいます。

　つまり、World Wide Webを実現するためにはHTTP、URL、HTMLが必要ということになります。

• 1　WWWの歴史
• 2　Webの概要
• 3　URL
• 4　マークアップ言語
• 5　HTTP
• 6　Cookie

1　WWWの歴史

1．1　ハイパーテキストの歴史

　ハイパーテキストとはコンピュータを利用した文書作成・閲覧システムの1つで、文書内の任意の場所や要素に、他の文書への参照を埋め込んで、複数の文書を相互に連携したものです。このような他の文書への参照情報をハイパーリンクといいます。

　ハイパーテキストの歴史はどこまでさかのぼればいいのかなかなか明確にはできません。遡ろうとすればどこまでも遡れそうです。例えば辞書や百科事典にその萌芽がすでに現れているといっていいかもしれません。文章中の用語に矢印（⇒）や指差し絵文字などを付けて、脚注の説明文と結びつける手法などもハイパーテキストのモデルとなっているといっていいかもしれません。

　1945年にヴァーネヴァー・ブッシュ（MIT）がMemexという未来のデバイスについての論文を書いています。Memexで使用するテクノロジはマイクロフィルムと電気機械式制御システムで、個人が所有する全ての本、記録、通信内容などをマイクロフィルムに保存し、それを高速に取り出して閲覧できるようになっています。ブッシュの考案したMemexはマイクロフィルムのコマとコマにリンクを設定することができました。マイクロフィルムの格納の順番とは関係なしに自由にリンクを生成することができますので、人間の脳内で行われている連想と似た情報蓄積方法が可能でした。殆どの専門家はこれが真のハイパーテキストだとは考えていないようですが、一般にハイパーテキストの発明者とみなされているテッド・ネルソン（「ハイパーテキスト」、「ハイパーメディア」という言葉もネルソンが作っています）と、ダグラス・エンゲルバートに直接の影響を与えています。

※ダグラス・エンゲルハード率いるスタンフォード研究所のチームはNLS（oN-Line System）という奇妙な名前のマルチユーザ連携のハイパーテキストシステムを開発しました。

　ネルソンは1960年に世界で最初のハイパーテキストプロジェクトであるXanadu（ザナドゥ）の開発プロジェクトをスタートさせました。ネルソンのXanaduプロジェクトは双方向リンク、引用、著作権管理、ユーザ認証、課金管理などを目指す野心的で壮大なプロジェクトでした。そのため、なかなかプロジェクトは完成せず、何度も仲間の離反、スポンサーからの切り捨てなどを経験しています。

※ネルソンは2015年の4月にOpenXanaduというソフトウェアをリリースしています。もしかしたら、現在のインターネットでの基本システムになっていたかもしれないものですが、残念ながら時間がかかりすぎてしまいました。しかし、ネルソンはまだ望みを捨てていません。Xanaduは何らかのソースを元に文書を作成した際は、テキストが双方向リンクとなりますので、ネルソンは「Xanaduは何らかの変化でリンクが壊れることがないので、完全な文献となるかもしれません。このシステムでは複数の文章が緊密に比較され、各テキストは注釈をつけられたようになり、全てのテキストの引用元を見ることも可能となります。なので、文学・法律・ビジネスのどの側面とも友好的なコピーライトシステムになりえます」と言っています。また、ネルソンは次のようにも言っています。「WebはオリジナルのXanaduを陳腐化したものだ。Webの一方向リンクは途切れやすく、また再利用やコピーライトに関する問題をはらんでいる。」。

※ネルソンは1968年にHypertext Editing System（HES）を開発しました。HESでは、データを「リンク」と、「分岐するテキスト」で構成しています。分岐するテキストは自動でメニューを作成し、所定の領域内のポイントは「ラベル」と呼ばれる名前を持つことができ、その名前でスクリーン上でアクセスが可能です。HESはIBMのSystem/360/モデル50（メインフレーム）上で動作しましたが、このシステムはHESのような革新的なシステムを動かすには能力が低すぎました。

　1980年代までに様々な実験的なハイパーテキストのシステムが登場しています。Guideはパーソナルコンピュータ用の初めてのハイパーテキストシステムです。最初はUNIX向けに開発されましたが、のちにMS-DOSにも移植されています。1987年にはMacintosh用に開発されたHyperCardが登場しています。HyperCardは直ぐに商業的な成功をおさめます。

　1980年にはティム・バーナーズ=リーがENQUIREを開発しています。ENQUIREはHyperCardに似ています。ENQUIREはカードと呼ばれるページ群からなり、各カード内にハイパーリンクがあります。誰でも新たなカードを追加できるのですが、既存のカードからリンクする形でなくてはなりません。これが、World Wed Webの下地になっています。

1．2　WWWの歴史

　欧州原子力研究機構（CERN）の計算機科学者ティム・バーナーズ=リーはENQUIREをインターネット上で稼働させるというアイデアを持ちます。リーは、ハイパーテキストとインターネットの双方の技術コミュニティが協同することの重要性を認識して、双方のコミュニティに働きかけますが、誰もこの提案に賛同する者がありません。リーはやむなく自分自らプロジェクトを実行することになりました。

※CERNは欧州原子力研究機構の開設準備のために設けられた組織のフランス語名称（Conseil Européen pour la Recherche nucléaire）の頭文字をとったもの

　リーはENQUIREのままではだめだと考えました。ENQUIREは双方向リンクであったために、カードを作成するときにリンク先のカードも編集する必要がありました。これでは誰でも利用できるシステムにはなれません。これを変更したのがWorld Wide Webです。

　World Wide Webは単方向のリンクを使用しますので、資源の所有者と連絡を取らなくてもリンクを張ることが可能となりました。それと同時に、ネルソンが批判するように、リンク先の資源がいつの間にかなくなっているという問題を発生させることになりました。

※リーはこの開発の過程で資源のありかを示すURLという識別子を考案しました。URIは後にURLの考え方を拡張したものです。

　開発当初、WWWは文字情報を扱うだけの比較的単純なものでしたが、1993年に、イリノイ大学の国立スーパーコンピュータ応用研究所（NCSA）に所属するマーク・アンドリューセンらの学生たちが、NCSA Mosaic（モザイク）というブラウザをリリースしました。NCSA Mosaicはテキストと画像を同一のウィンドウに混在して表示できました。それ以前は、テキストを表示するだけのものが殆どです。画像を扱うことができるシステムもなかったわけではありませんが、画像とテキストは別々に扱うことしかできませんでした。NCSA Mosaicのテキストと画像を混在させたままで表示できるという機能はまさに画期的だったといえます。アンドリューセンたちはソフトに改良を加えるため無料でソースコードを公開しました。また、同じころCERNがWWWの利用を開放したため、Mosaicはたちまちのうちにインターネット上で普及していきました。
　
　Mosaicの開発に携わったマーク・アンドリーセンらの学生たちは、シリコングラフィックス社の創設者のジム・クラークと共にモザイク・コミュニケーション社を立ち上げます（後にネットスケープコミュニケーション社に社名変更）。アンドリューセンはMosaic関連の書類を全て破棄したうえで、新たにNetscape Navigatorブラウザを開発しました。このブラウザは非常に成功しました。

　NCSAはMosaicのライセンスをスパイグラス社に与え、更にスパイグラス社からライセンスを受けたマイクロソフト社は、Mosaicのコードを元にしてInternet Explorerを開発しました。

　当初成功したネットスケープ社のNavigatorはマイクロソフト社のInternet Explorerの激しい追い上げを受け、徐々にシェアを下げ、会社の業績も下がり、1998年にAOLに買収されることとなりました。

2　Webの概要

　Webはどんなものでしょうか？ここではWebの大まかなイメージを持っていただきたいのでWebの概要について説明します。Webはクライアントサーバシステムを採用していますので、WebサーバとWebクライアントが必要になります。代表的なWebクライアントはWebブラウザです。Webクライアントからのドキュメントの要求に応答するのがWebサーバです。

　Webブラウザとしては、IE、Chrome、Firefox、Safari、Edgeなどがあります。IE（Internet Explorer）はマイクロソフト社（Microsoft）、ChromeはGoogle、FirefoxはMozilla Foundation、Safariはアップル社（OS Xの標準ブラウザ）、Edgeはマイクロソフト社が、それぞれ開発しています。
　EdgeはマイクロソフトがWindows 10用に開発したIEの後継ブラウザです。ChromeはGoogleが開発するブラウザで、Windows用だけでなく、Mac OS X用、Linux用もあります。アップルではMac OS X用のSafariをiPhone、iPod touch、iPad用にもカスタマイズしています。

　Webサーバはティム・バーナーズ=リーが作った「CERN HTTPD」が元になっています。これを元にしてイリノイ大学NCSAのロバート・マックールらが「NCSA HTTPD」を開発しています。この時点では「CERN HTTPD」と「NCSA HTTPD」がWebサーバの主役でしたが、なかなか改修が進まないという不満があり、NCSA HTTPDを修正するためのパッチ（patch）を集積するためのプロジェクトが始まりました。このプロジェクトはApache Groupと名乗っていました。そして、NCSA HTTPDのメンテを主とする活動の中からApache HTTPDが誕生し、これがやがて主役としての立場を奪っていくことになります。

　Webサーバは、WebクライアントであるWebブラウザからURLで指定されたドキュメントを送信します。WebクライアントとWebサーバの通信手順は通常はTCP上の、HTTPです。HTTPはポート番号80番を使います。セキュアな通信を行いたい場合はHTTPSが使われます。HTTPSではポート番号443番が使われます。

　Webブラウザ上で、「http://ja.wikipedia.org/wiki/Moodle」へのリンクをクリックした場合について具体的に考えてみましょう。

●　ブラウザはユーザの指定にしたがって、「http://ja.wiki.pedia.org/wiki/Moodle」をURLとする。
●　ブラウザはhttp://と次の/の間の「ja.wikipedia.org」をWebサーバのドメイン名と解釈し、DNSサーバに対して、「ja.wikipedia.org」の名前解決をし、その結果203.212.189.250という回答を得たとする。
●　ブラウザは、203.212.189.250のポート番号80番にTCP接続を試みる。
●　ブラウザは/wiki/Moodleというファイルを要求
●　ブラウザはサーバ（ja.wikipedia.org）から、/wiki/Moodleというファイルを受信
●　tcp接続の解放
●　ブラウザは/wiki/Moodleの全てのテキストを画面表示
●　ブラウザはこのファイルに含まれる全ての画像を取得し、画面に表示

　全てのブラウザは、あらゆるWebページを表示できなくてはなりません。そのためにはWebページが標準的な言語で記述されていなくてはなりません。Webページを記述するために使用する標準的な言語にはHTMLがあります。Webページ全体がHTMLで書かれていれば問題はないのですが、そうもいかないこともあります。PDF形式の文書、GIF形式のアイコン、JPEGの写真、MP3の音楽、MPEG形式の動画、その他のファイル形式などで書かれたものはどうでしょうか。ブラウザが解釈できなければ、ページで扱うことはできません。

　クライアントからの要求に対して、Webサーバはファイルの内容を返すだけでなく、そのファイルがどんなファイルかなどの情報を合わせて返しますので、Webブラウザはデータを適切な表示方法で扱うことができます。

3　URL

URL（Uniform Resource Locator）はインターネット上のリソースを特定するための識別子です。ここでいうリソースはデータやサービスなどを指します。

※URL：ティム・バーナーズ=リーが1991年に発表した論文ではUniversal Resource Locatorと命名され、最初はこの名前が使われましたが、現在の正式名称はUniform Resource Locatorです。

3．1　スキーム

　一般的なURLの例は次のようなものです。

上のURLのhttpはスキーム名といいます。一般的には、スキーム（scheme）とは「何かを達成しようとする試み」のことですが、いろいろの分野の専門用語としても利用されています。コンピュータサイエンスの分野では、特定のリソースに到達するための手段を表す言葉として利用されています。このスキーム名にはそのスキームのプロトコル名が使われます。一般的にはhttp、ftpなどが使われますが、RFC1738はこれ以外にも、gopher、mailto、news、nntp、telnet、wais、file、prosperoなどを規定しています。

※gopher（ゴーファー）：テキストベースの情報検索システム（1991年ミネソタ大学で開発）。WWWが普及したこと、日本語等のマルチバイト文字環境に対応していないことなどが理由で現在はほとんど利用されていない。
※mailto：電子メールの宛先を示すためのスキーム
※news：ネットニュース（Usenet）のためのスキーム
※nntp：NNTP（Network News Transfer Protocol）；ネットニュース（Usenet）の記事を読むことと、記事に投稿するために利用
※telnet：端末間のプロセス通信のプロトコル。IPネットワークにおいて、端末からリモートサーバにログインして操作するためのソフトウェア、あるいはそれを可能とするプロトコル
※wais：WAIS（Wide Area Information Servers）；分散型テキスト情報検索システム。Gopherサーバの全文検索システムとしてよく利用されたが、WWWの普及に伴い現在はほとんど利用されていない。
※file：オペレーティングシステムのファイルシステムの中を参照するためのスキーム
※prospero：Prospero Directory Service（1980年代にワシントン大学で開発されたバーチャルシステムモデル上の名前システム）

　一般にURLは「（スキーム名）：（スキームごとに定められた何かの表現形式）」という形をしています。スキーム名以降の部分はスキーム毎に定められた規則に従いますが、基本構文は次のようになっています。

<スキーム名>://<user>:<password>@<host>:<port>/<url-path>

　＜host＞はネットワークホストのドメイン名、あるいはドッと区切りの10進表示のIPアドレスで表します。
　＜port＞は接続するためのポート番号です。ほとんどのスキームはデフォルトのポート番号を持っています。省略するとデフォルトのポート番号を指定したことになります。この場合はコロンも省略します。
　＜url-path＞はどのようにリソースにアクセスするかを示しています。

ただし、上のパラメータのいくつか、あるいは全部は除外される可能性があります。とりあえず、スキーム毎に違うと思っておいたほうがいいかもしれません。

※gopher、wais、prosperoはほとんど利用されていませんので省略しました。どうしても知りたいという方は、rfc1738をご覧ください。　

3．2　URI

　最近URL以外に、URIという言葉もよく利用されます。URIが正しい呼び方で、実はURLは間違った使い方であるという認識の人も最近増えているようです。厳密にいうとURIはURLを包含する概念です。似たような言葉にURNがありますが、URNもURIに包含されています。

　URIという上位概念がなぜ必要かというとそれはIETFの壮大な目標に関係しています。IETFはインターネット上で総合的な情報サービスを提供するという目標を持っています。そのためには、情報資源を記述したり、操作したりする枠組みが必要となると考えています。インターネット上にあるWWW、FTP、Gopher、WAISなどの種々の情報資源探索のシステムを全部一つのものに統合して提供する方が、より人間に分かり易いシステムになると考えています。IETFが構想している情報サービスの仕組みは概ね次のような4つの階層構造に集約されます。

　第1層に新しい資源が追加されたり、移動されたりすると、「自動応答システム」が第2層、第3層に最新の情報を伝えます。

　この総合的な情報サービスにおいて用いられる、統一的なインターネットの情報資源の記述方式、それを利用する組織、提供のメカニズムを定めるものがURI（Uniform Resource Identifier）です。URIには、情報資源のネットワーク上の物理的な配置場所の書き方のルールを示すURL（Uniform Resource Locator）と、情報資源の一意の名前付けのルールを定めるURN（Uniform Resource Name）、情報資源の特性に関するメタ情報（著者、データ形式、アクセス制限、価格、場合によっては主題情報など）を示すURC（Uniform Resource Characteristics）などが含まれます。つまり、URIはURL、URN、URCなどの上位概念で、これらを包括するようなルールを定めることで、上に述べた4層構造の情報サービスを保証しようとするものです。従って、URLやURN、URCはURIの定めるルールの範囲内で、それぞれ情報資源の場所、永続的な名前、特性・属性を定めるルールを規定しているということになります。

　URLについては既に説明しましたので、次にURNとURCについて若干の説明を追加します。



■　URN
　WWWの問題点として、URLがネットワークの物理的な場所と密接に関連しているために、ドキュメントの置き場所が変わると、リンクが切れてしまうというのがあります。しかも、そのリンクは一方向のリンクです。つまり、リンク先のドキュメントの所有者に断りもなく張っているだけです。リンクを張られた方はそのことを知らずにドキュメントの場所を移動すると簡単にリンクが切れてしまうということになります。また、同じ内容の情報資源に異なったURLが与えられてしまうこともあります。URNが使われるようになれば、同じ情報資源には同じ名前が与えられることが保証されます。

　URNが有効に機能するためには、その機能に関する要件と、記法に関する要件をクリアしなくてはなりません。

　URNが機能するために満たすべき要件としては、「インターネットの世界でユニークであること」「永続性を持つこと」「あらゆるタイプの資源に適用できること」などがあります。また、記法の要件としては「一意性を持つこと」「比較対照が容易であること」「人間が表記しやすいこと」「各種プロトコルで移動が可能なこと」などがあります。

　URNの基本機能や記法が満たすべき条件が明らかになったとしても、それを実際にどのように実現していくことができるかを考えると前途には多くに難問が横たわっています。誰がどのような形で、情報資源の一意性を保証するのでしょうか。出版社や学会によって管理されている冊子体の出版物だけでも、まだ情報資源の一意性を確保できていないのに、それ以外の情報資源についてはどのようにしたらいいのでしょうか。本来、冊子体よりもはるかに曖昧な世界であるネットワーク上の情報資源に対してある程度うまくいくURN運用体制を作ることは相当に難しいことだと思われます。

※図書に関してはISBN（International Standard Book Number）があり、ISBNの次に10桁のコードが続くISBN-10と、現行のISBNの次に13桁のコードが続くISBN-13が、混在している状態（一般社団法人の日本出版インフラセンター日本図書コード管理センターが管理）。逐次刊行物を識別するためのコード番号としては、ISSNがある（国立国会図書館がISSN日本センターとして活動）。ISSNコードは申請に基づいて付与される。

　URNの書式は次のようになります。

NIDは名前空間の識別子です。英数字で始まり英数字とハイフンで構成される32文字以内の文字列で、大文字小文字を区別しません。NIDは登録制です。NSSは名前空間に固有のリソースを識別する文字列です。

　現在登録されているURNはいくつかあります。

　OASIS空間は、XMLやSGMLによる様々な標準仕様を定めているOASISが、文書やリソースを識別する方法として登録している名前空間です。

　IETF空間はIETF文書を管理するために定義された空間です（最初に登録されたURN）。IETF名前空間は、ietfというURN空間のもとに、RFC、RFCの分類カテゴリである参考情報（FYI: For Your Information）、インターネット標準（std：standard）、現状（bcp、Best Current Practice）、RFC以前のドラフトであるInternet Draft（id）、会議議事録(mtg）などをサブクラスとして持っています。ietfの名前空間は次のようになります。

　書籍に関するISBNも正式に登録されています。


■　URC
　URCに関しては議論が始まったところです。基本となる文献もRFCのドラフトの段階です。このドラフトの中では、URCが持つべき基本機能と、それを実現するための必要な方法の方向性が示されているだけです。これによると、URCの役割は大きく2つあり、第一はURNとURLを結びつけること、第二は情報資源のメタ情報を提供することです。

※URCに関するドラフト標準：Daniel, Ron.; Mealling, Michael. "URC Scenarios and Requirements". Internet Engineering Task Force, March 24, 1995. Internet Draft (draft-ietf-uri-urc-req-01.txt). Expires September 22, 1995.

3．3　クエリ文字列

　HTTPの構文は次のようになります。

<path>の次の?<searchpart>の部分をクエリ文字列といいます。クエリ文字列は、サーバに情報を送るためにURLに付加する変数のことです。"?"をURLの末尾に付けて、その後に追加します。

　クエリ文字列の基本構文は次の通りです。

複数の値を指定する場合は&（アンパサンド）を使います。

例えば、「学籍番号=2016123456」とか、「page=2」、[msg=yes」のように使います。

4　マークアップ言語

4．1　HTML

　地球規模での配信を目的に情報を公開するためには、全てのコンピュータが潜在的に理解可能な言語が必要です。その候補として挙げられるのがマークアップ言語です。マークアップ言語（markup language）は、見栄え（フォントサイズなど）や、見栄えに現れない文書構造などを明確に示すための形式言語です。markupとはもともとは英語圏の出版業界で使用されたもので、著者、編集者、印刷者の間で指示を与える方法として使用されていたものです。この方法をインターネットのWebシステムで利用できるようにしているのがHTML（Hyper Text Markup Language、略称はエイチティーエムエル）です。

　HTMLファイルを表示する役割を担うのがWebブラウザです。HTMLファイルは見た目や文書構造に関する指示をコマンドの形で与えます。このコマンドは文法に沿って使用されます。ブラウザはその種類にかかわらず、HTMLの方法（文法）を理解すれば、HTMLで書かれたファイルを正しく画面上に表示することができます。

　標準化ということはどのような環境でもリソースをブラウザ上に表示できなくてはならないということです。例えば、文書の見出し語をMicrosoft Wordの[MSゴシック」の16ポイントで書いたとしましょう。しかし、これをそのまま指示したのではブラウザは困ってしまうこともあります。場合によってはWordが使えない場合もありますし、「MSゴシック」というフォントを持っていない場合もあります（例えばMacintosh）。また、小さなモノクロ画面の携帯端末でページを見ている人もいるかもしれません。そこで誰でも情報を共有できるようにするために、環境に依存する方法ではなく、「見出し」（例えば、「見出し1」とか、「見出し2」など）という意味上の位置づけだけを与えておいて、それを見たソフトウエア（Webブラウザ）が自分の環境に合わせて自由に表示する方法が採用されました。

　HTML文書はブラウザに対する指示と、そのブラウザを介して、表示され、ユーザによって閲覧される本文からなります。ブラウザに対する指示はhead要素、ユーザに表示される部分はbody要素といいます。この両者を合わせたものがhtml要素です。

　どこが要素かということはブラウザに分かるようにしてやらないとブラウザはどのように表示していいか分かりません。そこで、要素をブラウザに分かるようにしてやるための目印が必要となります。この目印を「タグ」といい、目印をつけることを「markup」といいます。

　タグは要素の名前を山括弧（"<"と">"）で囲んだものです。タグが1つでは、ここからここまでというマークアップができませんので、通常は2つのタグをペアにして使います。「ここから」を示すタグを「開始タグ」、「ここまで」を表すタグを「終了タグ」といいます。終了タグは、開始タグと区別するために最初の括弧を、"</"と表します。
　
　タグは一般的に次のように使います。

タグに囲まれた部分は「内容」といいます。

一部のタグには属性（attribute）と呼ばれる名前付きのパラメータを取るものもあります。
例：<img src="abc" alt="foobar">
これは、パラメータsrcにabcを、パラメータaltにfoobarを与えるということを意味します。

次によく利用されるタグについて説明します。

■　＜img＞タグ
　<img>はページの現在の位置に画像を取り込むことを指示します。<img>タグではいくつかの属性が使われます。

■　ハイパーリンク
　他のURLなどへのハイパーリンク（が設定された文字列）をアンカー（anchor）と呼び、それを記述するための要素のことをアンカータグといいます。アンカータグは<a></a>で表します。アンカーでもいくつかの属性を使いますので、次に説明します。

<a href="http://www.nasa.gov">NASAのホームページ</a>のように使います。この場合は、"NASAのホームページ"のように、表示され、ユーザがこのテキスト部分をクリックすると、NASAのホームページ（http://www.nasa.govというURLのページ）を取得して、画面に表示します。スペースシャトルの写真（shuttle.gif）を示し、これをクリックすると、NASAのページを表示するという場合は、<a href="http://www.nasa.gov"><img src="shuttle.gif" alt="NASA"></a>となります。

■　HTMLの骨格
　HTML文の大体の形は次のようになります。

　ヘッダ部分は大体次のようになります。

titleは本の背表紙のようなものです。本の背表紙は、本棚に立てたときに一目見てその本がどんな本か分かるようなものでなくてはなりません。Webページのタイトルも同様です。検索エンジンのページにリンクとして表示されるのは基本的にこのタイトルです。タイトルがWelcomeとかChapter1では、中身がどんなものかが分かりませんので、たとえ検索にヒットしたとしても訪問してもらえません。ブラウザのヒストリ（閲覧履歴）やブックマークに登録されるのもこのタイトルです。

　次は本体の大体の形です。

本体を表す<body>・・・</body>の中に、段落を表す<p>・・・</p>が入れ子の状態になっています。<p>・・・</p>の中が更に入れ子の状態になっていることもあります。

　読みやすい文書にするには見出しも大切です。次は見出しを追加した例です。

　さらにリストを追加してみます。

　更にリンクを追加します。

画像やファイルへのリンクを張る場合はhref=に続いてパス（URL）を指定してください。指定方法には絶対パスと相対パスという2つの方法があります。
　
　絶対パスは自分が今どこにいるかによって左右されない書き方です。http://で書き始めて、http://www.yahoo.co.jpのようになります。主に他のサイトへのリンクに使用します。

　これに対して、相対パスは、自分がどこにいるかによって左右される書き方です。自分（今作業している、あるいは見ているファイル）から見て（相対的に見て）どこにいるかを指定します。abc.htmlという名前のファイルを例にとって説明します。同じフォルダの中のファイルは"./ファイル名"で指定しますので、同じフォルダ内のabc.htmlファイルは"./abc.html"と表示します。フォルダを1つ上がることを".."で表しますので、1つ上のフォルダにある場合は"../abc.html"となります。2つ上の場合は"../../abc.html"となります。同じフォルダ内にwxyzというフォルダがあり、そこにあるファイルを指定する場合は、"./wxyz/abc.html"となります。同じフォルダ内のwxyz/abc.htmlという意味です。

4．2　HTML標準化の歴史

　WebシステムはWebページの著者とユーザエージェントのベンダが同じHTML規約を共有することによって成り立ちます。このためにはHTML規約を標準化しなくてはなりません。HTML仕様を標準化すれば、ブラウザやプラットフォームの違いを超えてHTML文書をうまく表示することができるようになります。HTML仕様が標準化されていれば、コンテンツのプロバイダは1種類の文書を作成すれば済みますので、コストの削減になります。

　このように考えると、HTMLの開発方針は次のようなものになるはずです。まず、仕様のバージョンアップによってコンテンツのプロバイダの努力が無駄にならないようにしなくてはなりません。できるだけ長い間文書は読み取り可能でなくてはなりません。どんな環境でもWebを利用できるように、様々な解像度や色深度のグラフィックディスプレイ、携帯電話、モバイル機器、音声入力機器、帯域などに対応できなくてはなりません。

　HTMLが著者に提供する機能としては、見出し、テキスト、表、リスト、写真などのオンライン文書が出版できること、ハイパーテキストリンクを通じて、オンライン情報をボタンクリックで取得できること、情報検索、予約、商品の発注などの遠隔サービスのトランザクションに用いるフォームを設計できること、表計算シートやビデオクリップ、音声クリップ、その他のアプリケーションを埋め込むことができること、などがあげられます。

　CERNのティム・バーナーズ=リーがHTMLを作ったのは1989年です。情報の管理と整理が目的だったので、とりあえず文書構造さえしっかりしていればいいという程度だったようです。開発当初は文書間のリンク、見出し、段落、リストなどの文書の構造を示すことくらいしかできませんでした。

　その後リーはWebサーバとWebブラウザを作ります。WebクライアントとWebブラウザがHTTPという通信手段を使ってクライアントがURLで指定したファイルを、サーバからクライアントに送信し、ブラウザでそれをきれいに成形して表示することができました。URL、HTTPを作ったのもリーです。1993年に、画像表示のできるブラウザMosaicを作ったのがイリノイ大学の学生だったマーク・アンドリューセンです。

　インターネットが急速に普及し、一般企業や家庭でも使われるようになると、機能性だけでなく美しさも求められるようになり、色、壁紙、フォント、配置などを設定する装飾系（見栄え）のタグが増えていきます。更にそれだけでなく、ブラウザ毎に独自のタグを追加するなど、複雑さが増していき、ブラウザによって見た目が大きく変わってしまうなどの弊害も目立ってきました。

　1994年にティム・バーナーズ=リーがW3Cという非営利団体を立ち上げます。これはWebをみんなで使えるように、使う人や場所や環境に左右されないような仕様や技術書を作成しようという団体です。

　1996年にW3CはCSS1.0勧告を出します。今までは、HTMLの中で文書の構造だけでなく、見栄えに関することも記述していましたが、見栄えの部分に関してはCSSを使って別のファイルを作ろうという趣旨です。

　1997年にはW3CはHTML4.0について勧告しています。ここでは、HTMLは構造を記述するもの、CSSは体裁（見栄え）を整えるものと明確に切り分けています。
　HTML4.0（4.1は改訂版）では、スタイルシート（CSS）、スクリプト、フレームの割り付け、埋め込みオブジェクト、右から左へのテキストおよび混在方向のテキストのサポート、高度な表（単純な表はHTML3.0から）、フォームの拡張、障害者からのアクセス性の向上などの機能を持っています。
　HTML4.0はあらゆる言語で文書を書き、世界中に搬送できるように機能を追加しました。そのため、HTML文書の文字集合をISO/IEC:10646標準に対応させました。ISO/IEC：10646標準は、国際文字、テキスト方向、句読点、その他の世界の言語に関係する問題の表現について、世界で最も広範囲をカバーする規格で、これに対応したことで1つの文書に様々な異なる言語を混在させることができるようになりました。

　1998年にはW3CはHTMLの発展形としてXMLという規格を勧告しています。

※XML（eXtensible Markup Language）もHTMLもSGML（Standard Generalized Markup Language）というマークアップ言語から派生した言語です。このうち、HTMLはブラウザに読み込ませてその内容を表示させるということに特化しています。これに対して、XMLの場合は、これを読み込むソフトも限定されていなければ、どんな機能を実現するかという点も特定されていません。いろいろのソフトに読み込ませることを想定しています。従来は、いろいろのソフトに読み込ませるということになると、それぞれのソフトに対応した記述方法に従う必要がありましたが、XMLではXMLの基本ルールに従いさえすれば、どのようなソフトでも読み込めるようになっています。また、XMLは用途が決まっていませんので、ブラウザに表示させることだけでなく、それ以外の様々なソフトで使えるようになるということです。
※企業内には様々なアプリケーションが稼働しています。例えば、顧客管理、売り上げ管理、営業履歴、在庫管理などなど。メインフレームが稼働していることもありますし、UNIXやWindows、Macが働いていることもあります。企業が自社のビジネスを正確に把握しようとすれば、これらのデータを連携させる必要があります。アプリケーション間では異なるデータフォーマットを使っていますので、XMLはこのような異なるデータフォーマットの中間言語としての役割が期待されます。また、Webパブリッシング、ビジネスtoビジネス（BtoB）、データベース、Webサービス等での利用が期待されています。
※自分の書いた論文を何百年も先でも世界中の人に読んでもらいたいなどの希望がある場合は、HTMLで書いておくよりも、XMLで書いておくほうがいいということがよくわかると思います。
※HTMLはブラウザが解釈しますので、ブラウザに分かるように書かなくてはなりません。そのためにはタグはブラウザに解釈できるものでなくてはなりません。これに対して、XMLは誰に解釈をさせるかがハッキリしていませんので、解釈するソフトに予め合わせるということはできません。そのため、XMLではタグは自由に定義することが可能です。その代わり、XML文書をアプリケーションから操作するための標準的なインターフェース（API=Application Program Interface）をいろいろと揃えておく必要があります。これらのAPIを揃えたソフトウェアは一般に「XMLパーサ」と呼ばれています。
※XMLパーサ（parser=構文解析プログラム）とは、XML文書を、アプリケーションソフトが利用しやすい形に変換するソフトウェアです。そのためには、XML文書は、XMLの文法に従って書かれている必要があります。
　
　2000年には、W3Cはデータのやり取りにはXMLが最適だとして、HTMLの仕様を新しくXMLに準拠したものに書き直し、これをXHTML1.0として勧告しました（HTML4.0をXMLで書き直したもの）。

　2001年、CSS2.1を勧告（ブログでXHTML＋CSSが流行）
　
　2004年、XHTMLが浸透しましたが用途はXMLよりもHTMLとしての利用だったので、Mozilla(firefox）やApple（safari）はHTMLを中心に開発をしていくことを提案しました。しかし、W3CはあくまでXML普及を優先して拒否しました。そこで、Mozilla、Apple、Operaに所属するメンバーによって[WHATWG」が設立されました。WHATWGは現状のHTML機能を拡張させる取り組みを独自に進めていきます。

　2006年、WHATWGの仕様は評価されますが、世界をXMLにスイッチしようとするW3Cの試みは失敗だったとみなされるようになります。そこで、翌年の2007年から、W3CとWHATWGは共同でHTML5の標準化に取り掛かり、2008年にはHTML5の草案が発表されることとなりました。

■　HTML5の特徴
　HTML5は現在普及しているWebサイトでよく使うものを簡単に使えるようにしています。例えば、グローバルメニュー、サイドバー、ヘッダ、フッタなどは殆どのサイトで使われています。これに関して従来は、<div>タグにIDやCLASSをしていたのですが、HTML5ではこれに基づいたタグが予め用意されていますので、直感的にレイアウトの枠組みを組むことができます。

　従来プラグインを使って実現していた映像や音声が、<video>や<audio>などのタグを使うことで、<img>タグと同じ感覚で扱うことができるようになりました。
※従来は映像や音声は<embed>タグを使って埋め込んでいましたが、<embed>タグで埋め込んだデータは再生の際にプラグイン（ソフト）が別途必要となることが多く、しかも訪問者の中にはプラグインを組み込む方法を知らない人もいますし、プラグインをインストールする環境にない人もいます。そのため、このようなファイルを埋め込む場合は、必要なプラグイン名を記述し、配布元にリンクを張るなどの配慮も必要でした。

　今まで製作者を悩ませていたブラウザ毎の互換性を気にする必要がなくなるかもしれません。HTML5はこの点について配慮し、細かい処理規定を定義していますので、ブラウザ毎の互換性の問題が少し解消してくれるかもしれません。

4．3　CSS

　HTMLには文書の構造を定義する部分と、Webページの見栄えを制御する部分があります。文書の見栄えの部分はユーザ側のブラウザによって左右されるところがありますので、閲覧環境によっては著者の意図に反して表示されてしまう場合もあります。HTMLで公開するWebページは大切な情報資産ですので、今後長い間多くの人に利用さることが期待されます。しかし、Webブラウザのバージョンに合わせて書いたものは、何年か後にバージョンが変わってしまったり、そのブラウザそのものが市場から消えてしまった場合にうまく表示されないかもしれません。

　大切な情報資産を多くの人に利用できるようにするためには文書の構造の部分と見栄えの部分を切り離してしまうべきです（1997年のW3C勧告）。

　1997年のW3C勧告は、見出し、段落、表、リストなどの文書の構造に関するものは従来通りにHTMLで記述し、フォントや、文字色、背景色、などの見栄えに関する部分は別に記述することを要求しています。見栄えの部分を記述する言語として期待されるのがCSS（Cascading Style Sheets、カスケーディングスタイルシート）です。

　文書の構造を制御する部分と、文書の見栄えを制御する部分に分け、文書の見栄えに関する部分をCSSで記述するといくつかのメリットがあります。

　見栄えに関する部分をCSSに移すとHTTPの構造がすっきりします。HTMLで見栄え部分を記述していると、見栄え部分の記述で文書の構造がハッキリしなくなってしまいますが、CSSで見栄え部分を分離すると文書構造がハッキリと分かるようになります。
　
　見栄え部分をCSSで記述するとメンテナンス性が大幅にアップします。HTMLで見出し部分を記述する場合を考えてみましょう。例えば、見出しのフォントやサイズ、色などを変更しようとすると、1つ1つ変更しなくてはなりません。これに対して、CSSで見栄えを管理している場合はどうでしょうか。CSSでは、このような文書の見栄えを一括して管理することができます。また、複数の文書の見栄えを共有することも可能です。見栄えに関することを共有のCSSで管理している場合は、共通のCSSを変更すれば一度に複数ファイルの見出しを変更することができます。

　HTMLによる見栄え制御を止めて情報を適切にマークアップすると検索エンジンに正しく解釈してもらえる可能性が高くなります。また、HTMLから余分なマークアップを1つのCSSに集積することで、Webページの軽量化を実現でき、アクセシビリティの向上が期待できます。

　HTML5では文書の構造の部分だけを残し、それ以外の見栄えに関するタグは廃止される予定ですので、見栄えに関する部分はCSSに移しておいた方がいいかもしれません。

4．4　MIME

　情報資産としてのファイルには様々な形式のものがあり、その種類はどんどん増えています。HTMLにだけ対処できますというわけにはいきません。しかし、HTML以外のファイルを使うのならどこかにその目印がないとWebブラウザは困ってしまいます。

　拡張子でファイルの種類が分かるんじゃないかという人がいるかもしれませんね。しかし、URLでサーバサイドのプログラムを呼び出している場合は、拡張子はプログラムの様式が指定している拡張子で、返ってくる文書の記法を表している拡張子ではありません。

　このように考えると、拡張子だけではファイルの種類を特定することはできません。何らかの方法でファイルの記法をブラウザに渡してあげないといけないでしょう。そこで候補に挙がってくるのがMIMEです。電子メールにUS-ASCII文字以外のデータを含める方法としてMIMEがありますが、この方法はWebページの送受信にも大きな力を発揮します。

　Webサーバにはいろいろのものがあって一概には言えないのですが、最もよく利用されているApacheサーバでは、".htaccess"というファイルを持っていて、このファイルにMIMEタイプを指定しています。データファイルがあるディレクトリ（フォルダ）に".htaccess"という名前のファイルを用意して、設定します。次に設定例を示します。

これは、Webサーバに対して、.htmlという拡張子が付いているファイルを送信する場合は、MIMEタイプとしてtext/htmlという指定をして送ってくださいね、という依頼をしたことになります。".html"や".gif"などに関してはプロバイダ側で既にその設定を行ってくれているはずですのでわざわざ指定する必要もありませんが、CGIを設定したり、RealAudioなどのようにちょっと特殊なファイルを設置する場合には、".htaccess"による設定が必要となります。

　Webでは拡張子とMIMEタイプの関係は次のようになっています。

　ただし、IEのようにMIMEタイプよりも拡張子を信用したり、あるいはMIMEタイプも拡張子も無視してファイルの中身を見て、「text/plainと言っているけで、これはHTML文書みたいだから、HTMLで表現してあげるからね」といったように余計なおせっかいをするブラウザもあって、なかなか期待通りの制御はできないようです。

5　HTTP

　HTTP（Hypertext Transfer Protocol）は文字通りWebクライアント（ブラウザ）とWebサーバの間で、HTMLやXMLなどのハイパーテキストをやり取りするためのプロトコルです。

　HTTPはリクエストーレスポンス型のプロトコルであり、クライアントがサーバにリクエストメッセージを送信します。HTTPリクエストメッセージはTCPコネクション上で実行されます。デフォルトのポート番号は80番です。

　HTTPクライアントはリクエストメッセージで、「何を」「どうして欲しいか」を伝えます。「何を」に当たるのがURLです。「どうして欲しいか」はメソッドによって示します。サーバはクライアントからの要求に従ってレスポンスメッセージを返します。基本的にはこれで初期状態に戻り、サーバはクライアントのことは全部忘れてしまいます。というか、最初からクライアントのことは何もわかりません。ユーザが誰かも当然分かりません。このようなプロトコルは状態を記憶していないという意味で、ステートレス（stateless）プロトコルなどと呼ばれています。これではオンラインビジネスなどには全く使えませんので、何か手当てが必要となってきます。そこで出てきたのがCookieを使うというアイデアです。Cookieについては後で節を改めて説明します。

5．1　HTTP標準の歴史

　ティム・バーナーズ=リーが最初に作成したHTTP/0.9は、ごく簡単なプロトコルでした。ブラウザがサーバに対する要求で使用するメソッドはGETのみです。サーバのレスポンスも単純にドキュメントの内容を返して、コネクションを切断するだけで、レスポンスコードの規定もありませんでした。

　HTTP/0.9の改訂版はHTTP/1.0です。HTTP/1.0で初めて仕様がRFC（RFC1945）として扱われるようになりました。メソッドもGET以外に、POST、PUT、HEAD、DELETEなどが追加されました。レスポンスにはヘッダが付けられるようになり、ステータスコードも付けられるようになりました。

　現在のバージョンはHTTP/1.1です。初版はRFC2068で、これはRFC2616で書き換えられ、RFC2616は、更にRFC2730～RFC7235で書き換えられています。

　HTTP/1.1の主な修正点は名前ベースのバーチャルホストをサポートすることです。HTTP/1.0ではIPアドレスのみで相手を識別していたので、ホスティングサーバのように1つのマシン上で何人ものユーザ（何社？）がWebサービスを展開しようとするとうまくいきませんでした。例えば1つのホスティングサーバ上にabc.example.comとefg.example.comという2つの仮想サーバがある場合を考えてみましょう。クライアントがabc.example.comのindex.htmlを要求した場合、DNSで名前解決をし、このIPアドレスを使って、当該サーバにGET index.htmlを要求します。しかし、efg.example.comもIPアドレスは同じですから、こちらのドキュメントルートにもindex.htmlというファイルがあるかも知れません（というより、高い確率であるはずです）。こうなると、クライアントがどちらを要求しているのか分からなくなります。

※ドキュメントルート：Webサーバが公開情報を格納しているディレクトリ（フォルダ）は逆ツリー状に構成されている。ドキュメントルートは公開情報が格納されている逆ツリー状のディレクトリのトップ（ルート）のディレクトリのこと

　HTTPの各バージョンのリクエストのフォーマットは次のようになります。

5．2　リクエストメソッド

　クライアントがリクエストメッセージを送ってサーバにリクエストをするとき、URLで指定したWebページが欲しいという場合が殆どですが、それ以外のことを要求する場合もあります。そこで、クライアントがどんなことを望んでいるかをはっきりとさせる方法が必要となります。この方法をリクエストメソッドといいます。

　HTTPリクエストメソッドは最初はGETだけでしたが、HTTP/1.0でPOST、PUTなどが追加され、HTTP/1.1では現在8種類のメセッドが定義されています。

　HTTP/1.1のリクエスト行の書式は次のようになります。

パス名は/aaa/bbb/ccc.htmlのようにスラッシュで始まるパス名（相対パス名）や、http://などで始まる絶対パス名があります。

■　GET
　一般形は「GET　ファイル名　HTTP/1.1」です。サーバに対してファイル名を指定してオブジェクトを送信するように要求します。URLで識別できる情報なら何でも回収することを意味します。「If-Modified-Since」「If-Unmodified-Since」「If-Match」「If-None-Match」「If-Range」などを含んでいる場合は条件付きGETとなります。

■　PUT、POST

　PUTとPOSTは共にクライアントからサーバへのデータの送信ですが、PUTは指定したURLを直接作成することを要求します。例えばhttp://kmownet.com/computer/web.htmlというURLに対してPUTメセッドでリクエストを送ると、このリソースが存在しない場合は新たにこのURLが作成されます。
　これに対して、POSTは指定したURLは作成されず、このURLを親ディレクトリ（フォルダ）とみなして、その子供のリソースをサーバが生成することを要求します。例えば、http;//kmownet.com/memosというURLに対してPOSTメソッドでリクエストを送るとします。これが1個のメモだとします。新しいメモのURLはサーバが決めます。今までに49番までのメモが存在すると、次のhttp://kmownet.com/memos/50のようなURLがサーバによって勝手に作成されます。
　以上をまとめると、PUTはクライアントが作成したいリソースが明確である場合に使用し、POSTは新しく作成するリソースをサーバに任せる場合に利用するということになります。PUTはファイルを送るから、指定したディレクトリにちゃんと保管してくれという感じでしょうか、これに対して、POSTはデータを渡すからちゃんとファイルに整理して保管してくれという感じになります。
　
　PUTメッソッドはリモートサーバ上にWebページのコレクションを構築する場合に利用します。ただし、呼び出し側が書き込み操作の実行を許されているかを認証するために、PUTの後にContent-Typeヘッダと認証が続きます。

　POSTメソッドは、メッセージをニュースグループに投稿したり、電子掲示板システムにデータを追加したりする場合に使用します。

■　HEAD
　HEADメソッドはメッセージヘッダのみを要求する場合に利用します。HEADメソッドでページの最新の更新時間を得て、インデックス作成のための情報を収集したり、URLの有効性の調査をしたりする場合に利用します。

■　リクエストメッセージの例

5．3　レスポンス

　サーバのレスポンスは次のようなレスポンス行から始まります。

補足メッセージは、OKやNot Foundなど、ステータス番号の意味や詳細を補足するメッセージが返されます。

　ステータス番号の意味は次の通りです。

　ステータスコードは3ケタの数字で表されます。1桁目が特に重要な意味を持っています。

　次に示すのは1桁目の意味です。

　次にステータスコードの一覧を示します。

■　レスポンスの例

5．4　ヘッダフィールド

　リクエスト、レスポンスはそれぞれ、リクエスト行とそれに続くヘッダ部分、空行、メッセージボディからなります。ヘッダの各要素は次の書式で書かれます。

　ヘッダフィールドには、リクエストヘッダでしか利用しないもの、レスポンスヘッダでしか利用しないもの、どちらにも利用できるもの（汎用ヘッダ）、それからメッセージ（エンティティ）の内容を説明するためのエンティティヘッダなどがあります。

■　汎用ヘッダ

■　リクエストヘッダ

使用例

■　レスポンスヘッダ

■　エンティティヘッダ

使用例

5．5　HTTPコネクション

　Webクライアント（ブラウザ）とWebサーバがHTTPでメッセージの交換をする場合に、メッセージ交換の通り道としてTCPコネクションを利用しています。ブラウザはサーバマシンの80番ポートとの間でTCPコネクションを確立します。そして、メッセージの消失、重複、長すぎるメッセージ、確認通知などはTCPに任せます。

　HTTP/1.0では1つのTCPコネクションを確立して、そこで1つの要求（リクエスト）と1つの（レスポンス）が交換され、それでおしまいでした。

1つのテキストページを送信してもらうのに、TCPコネクションの確立（3ウェイハンドシェークでは3ステップ）を行い、HTTPリクエスト、HTTPレスポンス、TCPコネクションの終了（4ステップ必要）という手順が必要となります。WebページがHTML分だけならこれで十分でしたが、Webページが大量のアイコン、画像などから構成されるようになると、これでは大変です。

　HTTP/1.1は永続的コネクション（persistent connection）という概念を導入しました。永続的コネクションでは、TCPは単一のリクエスト・レスポンスの交換の域を超えてコネクションのオープン状態を維持することができます。こうなると1つのTCPコネクションで、いくつものリクエスト・レスポンス交換を行うことができますので、ユーザの待ち時間は大幅に短縮できます。

　HTTP/1.1ではクライアントかサーバのどちらかが、HTTPヘッダで「Connection: Close」を指定しない限り、HTTPレスポンスの後でも、TCPコネクションはそのまま残り、クライアントはそのコネクションを使って複数のリクエストを行うことができ、サーバもそれに対する応答を行うことができます。

6　Cookie

　HTTPは1つのリクエストに対して、1つのレスポンスがあり、それでセションは終了します。HTTPはステートレス（stateless）プロトコルと言われますが、これはサーバはクライアントのセションの状態を保持していないという意味です。リクエストとレスポンスのペアの間の関係がどこにも残っていませんので、例えばWebサーバに対してあるリクエストがあり、続いて別のリクエストがあっても、この2つのリクエストの間に関連性があるのかないのか全く分かりません。たとえ、パスワード認証をしたとしても、その認証をしたブラウザからのアクセスかどうか分かりません。

　ステートフル（セション状態を保持）とステートレスにはそれぞれメリット・デメリットがあります。

■　ステートフルのメリット・デメリット
　メリットはやり取りが簡潔に済み、そのためネットワークの帯域を節約できることです。

　デメリットは、クライアントの状態をその都度把握しておかなくてはならないので、場所とリソースを余分に必要とすることです。また、サーバを複数台設置してシステムの処理能力を高めようというような場合（スケールアウト）、サーバ間でクライアントの状態を同期させる必要があります。

■　ステートレスのメリット・デメリット
　クライアントのリクエストは状態に依存しないので、そのリクエストで知ることのできる情報だけで、操作に必要な十分な情報となります。そのため、サーバの数を揃えてシステムの処理能力を高めようとするスケールアウトには向いています。また、処理がクライアントの状態に依存しないので、処理がシンプルになります。
　
　デメリットは、やり取りが冗長になりがちになることです。また、リソースへの操作が必要となる度に同じことを繰り返す必要があります。そのため、ネットワークの帯域を消費し、処理も遅くなります。また、サーバが状態を保持していないので、エラーが起きた時の処理が大変になります。

　Webが開発された当時はステートレスのシステムが複数存在していたようです。そこで、競争力を維持するためステートレスが採用されたのではないかと思います。ステートレスにすると、サーバ側でステートを保持するための場所、処理に充てるリソースなどが必要なくなりますので、競争力が増すと期待されたのだと思います。

6．1　ステートレスモデルの問題点

　サーバは「あるブラウザの前回のリクエストの結果を踏まえて、今回の処理をする」というようなことができませんので、このままではWebをビジネスに使うことはできません。例をいくつか挙げてみましょう。
①　電子商取引でユーザの買い物かごの中身をサーバ側で覚えておくことができない。
②　ユーザを登録したとしても、登録ユーザと、非登録ユーザを区別することができない。
③　ユーザを識別できないので、特定のユーザが必要としている情報（例えば株価情報、好きな野球チームやサッカーチームの情報）を選り分けて与えることができない。

　オンラインショッピングなどを考えると、誰が何をいつく買ったのか分かりません。代金を誰に請求していいかもわかりません。ユーザを識別する方法がないかと考えてもあまりいい案は浮かびません。例えば、IPアドレスではどうでしょうか。しかし、これには無理があります。IPアドレスはコンピュータを識別するもので、人を識別する能力はありません。企業等では同じIPアドレスのコンピュータを複数人が使う可能性があります。自宅からのインターネット接続ではISPを使いますが、多くのISPではNATを利用していますので、IPアドレスで発信元を識別することはそもそも無理があります。

6．2　ステートを維持する技術---Cookie

　Netscape社はステートを維持するためにCookie（クッキー）という技術を開発しました。Cookieによってステートを維持する手順は次の通りです。

ステップ1：クライアントAがサーバBにリクエストをします。クライアントAはCookieを受け入れ可能ならば、リクエストヘッダでCookieが使えることを宣言します。

ステップ2：サーバBは要求されたページと一緒にCookieを返します。Cookieは単なるファイルあるいは文字列です。サーバBはレスポンスの中で、Set-Cookieで値をセットします。例：Set-Cookie：XYZ

ステップ3：ユーザがCookieを無効にしていない場合は、ブラウザは提供されたCookie文字列を解釈せずに、それを格納します。初めはメモリに置きます。ブラウザのプロセスが終了した後は、ハードディスクに格納します。

ステップ4：ブラウザAはサーバBへの次のリクエスト時に、リクエストヘッダにCookieを入れて送信します。

■　Cookieの書き込み
　HTMLを使ってCookieの値を書き込む方法は次の通りです。

※　JavaScriptを使う場合、CGIを使う場合などは若干異なります。

～の部分には次のような文字列を指定します。

NAME=値;　以外は省略可能です。

　各パラメータの意味は次の通りです。

■　Cookieの参照
　Set-Cookieで保存されたCookieは、HTTPリクエストのCookieヘッダとして、ブラウザからサーバに送信されます。Cookieヘッダは次のように、ブラウザに保存されたNAME=値のペアを";"で連結したものになります。

厳密にいうろ";"の後ろに半角のスペースが必要で、末尾には";"はいりません。ただし、多くのブラウザでは、半角スペースを削除したり、末尾に";"を付けても多分動くでしょう。

　どのCookieがサーバに送信されるかは、Set-Cookieで指定したexpiresやpath、domain、secureなどの属性によって制御されます。

6．3　Cookieの使用

　ブラウザはあるWebサイトを閲覧する前にCookieディレクトリを見て、リクエスト先のドメインが書き込んだCookieがないかを調べ、もしあれば、リクエストのヘッダにそのCookieを含めます。これを受け取ったサーバはそれを解釈します。どのように解釈するかはサーバの自由です。

　オンラインショッピングの例で説明します。最初にショッピングサイトに行くと、住所や氏名、電話番号、送り先などの様々な個人情報の入力を求められます。サーバはこれをCookieに入れてクライアントに送り返します。ユーザがサイトを歩き回って特価品をクリックすると、商品番号、製品コードなどをCookieにいれその都度送り返されます。ユーザが"購入手続きに進む"をクリックすると、ユーザの個人情報や全ての購入品のリストが保持されたCookieが、リクエストと一緒にサーバに送信されます。

　後でまた同じサイトでショッピングするときは（domainやpath属性で確認）、クライアントは保存しておいたCookieを一緒に送信します。サーバは以前送ったCookieが戻ってきたことを確認して、ページに反映させます。Webサイトにアクセスすると、自分の名前が表示されたり、前回のアクセス日時が書かれていたり、訪問回数が書かれていたりすることがあるのはこういうことだったのです。

6．4　Cookieの危険性

　Cookieは便利な反面、危険性もあります。Cookieを奪われると個人情報が悪用される危険性があります。また、Cookieを盗んだ第三者がオンラインショッピングなどで勝手に買い物をし、代金を払わされる可能性もあります。
　Cookieを不正に盗む方法としてはクロスサイトスクリプティングなどの手法が良く知られています。また、パソコン内の情報をコピーして奪い取ってしまうウィルスなども知られていますので、注意して下さい。

　心配な場合はCookieを拒否することができます。全部のCookieを拒否することもできますし、特定のサイトのCookieを拒否することもできます。IEの場合は、「インターネットオプション」（「ツール」から、あるいはツールバーの「歯車アイコン」から）で、あるいはEdgeの場合は、「･･･」（詳細）から「設定」→「詳細設定」→「プライバシーとサービス」の「Cookie」から①全てのCookieをブロックする②サードパーティのCookieだけブロックする③Cookieをブロックしない、のいずれかを選択することができます。

Tweet

ネットワーク超入門講座 セキュリティ編【電子書籍】[ 久米原 栄 ] 価格:2,268円 (2018/1/21 11:07時点) 感想(0件)

更新履歴

2016/05/17