はじめに
本記事では、著書「プロになるためのWeb技術入門」についてまとめています。
全7章ありますが、今回は5章までをまとめています。
（6章は、JAVAを例にWEBアプリの仕組みについて解説されており、7章は基本情報技術者試験の情報セキュリティ分野を詳しく説明したような内容となっています。）
1.Webアプリケーションとは何か
大きく分けるとアプリケーションは、デスクトップアプリケーションとWebアプリケーションの２種類。
ここでは Webアプリケーションの理解を深めるために両者を比較してまとめている。
1-1デスクトップアプリケーション
例を挙げるとMicrosoft社のWord、Excel、Outlookがデスクトップアプリケーションに該当する。
上記の特徴は以下の３つ。
・CD-ROM、DVD-ROM、Web上でソフトウェアをインストールしなければ使えない
・処理が手元のPC上で行われる
・画面はOSの機能を利用して表示される
1-2Webアプリケーション
一方、Webアプリケーションは以下の3つのような特徴がある。
・インストールする必要がない
・処理が手元のPCではなく、サーバ上で行われる
・画面はHTMLで表現され、Webブラウザ上で表示される
Webアプリケーションには、Yahooの路線案内や、Amazonの販売サービスなど該当する。
インターネットに繋がっていればいつでもどこでも利用できるのが大きな魅力である。
2.Webはどのように発展したか
ここではWebが発展した歴史についてまとめている。
2-1.WWWの誕生と普及
１９６９年に、ARPANETと呼ばれるアメリカ国防省が研究調査目的で、インターネットの原型となるネットワークを構築した。
しかし、
・コンピュータやネットワーク資源が高価すぎた
・メール交換やファイル共有などの作業が地味だったため一般の人には受け入れられなかった
以上２つの理由から、大学研究者などごく一部の人間しか利用できなかった。
WWWの誕生
１９８９年、欧州原子核研究機構（CREN）の、ティム・バーナーズ＝リー博士によってWWWが開発される。
ここで図表や参考文献をテキストだけで表現するため、HTMLが用いられた。
文書間の参照を容易にするため、HyperLinkが使われるようになる。これによってネットワーク経由で容易に参考文献が探せるようになり、作業効率が大きく向上した。
ネットワーク上でつながるハイパーリンクが蜘蛛の巣のように見えることからWorld-Wide Web（世界に広がる蜘蛛の巣）と名付けられる。
現代のWebブラウザの祖先NCSA Mosaic
WWW登場当初は、文字のみのWebページしか表現できなかった。
しかし1９９３年、NCSAモザイクというブラウザが開発されたことにより、文字と画像が混在した今のWebページに近いものが利用可能になった。
また、Mosaicは無料で利用可能なブラウザだったため、この段階で研究者だけでなく一般の人の利用も広がった。
２０００年前後にはPCの低価格化、ADSLや光ファイバーの普及で高速なネットワークが利用可能となり、一気にインターネット利用が一般的となった。
このMosaicが、現在のブラウザであるIEやFirefoxなどのベースとなっている。
2-2.Webを支える技術
ここではWebシステムの基礎となる技術が紹介されている。
WebサーバとWebクライアント
WWWによるハイパーテキストの公開と閲覧は、「Webサーバ」と「Webクライアント」というソフトウェアで実現されている。
WWWでは、ハイパーテキスト（HTML形式のファイル）をWebサーバに蓄積し、Webクライアントの要求に従ってHTMLファイルを渡す仕組みとなっている。
この時行われる要求を「リクエスト」、サーバからクライアントに対する応答を「レスポンス」と呼ぶ。
Webサーバ用のソフトウェアには「Apache」「IIS」などがある。
WebブラウザはIEやFirefoxなど。
なぜクライアントとサーバに分けるのか
WWWでは、コンテンツの管理をしやすくするために Webサーバーに情報を集めておける仕様になっている。
一方で、コンテンツを自由に閲覧するために、利用者が直接膨大な情報が格納されたサーバーを操作するのは困難なため、手元のPCで簡単に操作できるようになった。
そのリソースはどこにある？-URL
サーバには大量の情報が入っており、不特定多数の人がコンテンツを公開するため、具体的にどの情報に対してリクエストが来ているのかを明確にする必要がある。
そこで一意なコンテンツを指定するために「URL」で、リソースの特定を行う。
URLは、スキーム、ホスト名、パス名によって構成される。
http://www.littleforest.jp/webtext/index.html
上記URLでは
スキームがhttp:
ホスト名がwww.littleforest.jp
パス名がwebtext/index.html
と分けられる。
・スキーム
リソースを入手するための方法のこと（HTTPプロトコル）。
スキームはRFC1738という文書で規定されており、https(暗号化されたhttp)、mailto(電子メール)、ftp(ファイル転送)、file(ファイルシステムのファイルやディレクトリを参照する)などがよく利用されるスキーム。
・ホスト名
リソースが存在するホスト（コンピュータ）名を表す。
クライアントからの要求を返すのがホストコンピュータ。
ホスト名はローカル名と、親ドメイン名に分けられる。
ローカル名がwww.
親ドメイン名がlittleforest.jp
さらに詳しく見ると
jp 日本の
littleforest littleforestという組織の
www wwwサーバというコンピュータ
となる。
ローカル名は自由に決められるが、親ドメイン名は（株）日本レジストリサービス（JPRS）という団体が管理している。
・パス名
ホスト名で指定されたコンピュータ上のリソースの位置を示す。
まとめるとURLは、ドメイン→コンピューター→ディレクトリ→ファイル名というように階層的にリソースを指定することで一意性を保っている。
HTTP
WWWでは、異なるコンピュータ間で情報のやりとりをするために、通信のためのルールを取り決める必要があった。
そのルールが通信プロトコルと呼ばれる。
通信プロトコルは、モールス信号や狼煙と同じで、定められたルールを知らない者からは理解できないものである。異なるコンピュータ同士で情報のやりとりをするには、このルールが必要であり、それが通信プロトコルと呼ばれる。
そしてHTMLの転送に適したプロトコル（通信の取り決めルール）がhttpである。
CGI（コモンゲートウェイインターフェイス）の誕生
WWWの目的は前述したとおり、作成した文書を世界に公開し共有することだが、問題点として一度公開した情報が変更できないため、利用者がすぐに離れていってしまうことがあった。（このような情報は静的コンテンツと呼ばれる）
そこでCGI（HTTPの一種）という仕組みが使われることとなった。CGIはWebサーバー上で動作するプログラムが自動でHTMLを出力するため、HTMLを変更する手間を省くことができる。（ここで生成されたHTMLを動的コンテンツと呼ぶ）
CGIで主に使用されたプログラムは、Perlというプログラミング言語で、大規模開発にはC言語が使用された。
サーブレットの誕生
WWWの静的コンテンツの問題を解消したCGIだったが、２つ問題点があった。
１つは開発言語、もう1つは性能の問題である。
CGIで使用されたPerlでは、大規模開発ができず、オブジェクト指向プログラミングができなかった。
また、アクセス数が増えるとCGIでは処理速度が追いつかないという問題もあった。
Java/サーブレットの誕生
上述したCGIの問題点を解決するために誕生したのが、Javaとサーブレット。
Javaはオブジェクト指向がフルサポートされており大規模開発に適している言語である。しかし、Webアプリケーションのために開発された言語ではないためサーブレットという機能が開発された。
サーブレットはCGIと同じく動的コンテンツの生成に使うものだが、CGIより処理速度が格段に速かったため、CGIの問題点を解決するものとして普及した。
Javaでアプリケーションを開発することの利点
Javaは特定のOSやハードウェアに依存せずに動作するという特徴がある。
C言語ではソースコードを直接コンピュータの機械語にコンパイルするが、JavaではJavaVMと呼ばれる仮想的なコンピュータでコンパイルが実行される。
そのためJavaVMが動作するコンピュータならOSに依存せず使用可能。
Webサーバに利用されるOSはWindows、Linuxなどさまざまであるため、従来は開発環境と本番環境を同一にする必要があった。
しかし、Javaならばその必要がないため、開発はWindows、本番環境の動作テストのみlinuxで行う、といったことが可能。
ただし、サーブレットを動作させるWebコンテナの設置がWebサーバのみの場合と比べて難しく、オブジェクト指向の知識が必要という点から、企業の大規模なシステムでは使われるが、個人ではほとんど使用されない。
個人の簡単なWebサイトは従来のCGI/Perl(PHP)が使用された。
JSP
サーブレットの問題点
現代の見栄えするWebページにはプログラムの知識以外に、デザインの知識が必要で、業務がプログラマとデザイナーで分担することが主流となっている。
しかしサーブレットはデザインの修正がしにくい仕様となっており、作業効率の面で問題がある。
また、サーブレットではJavaの出力命令に従ってHTMLの文字列を出力する仕組みとなっている。そのためプログラムが長くなると修正箇所がわからないという事態も生じてしまう。
JSPの誕生
JSPでは、動的に出力したい箇所を<% %>で括ることでHTMLに非常に近い形でプログラムを記述できる。JSPに書かれたJavaプログラムはスクリプトレットと呼ばれる。
JSPの誕生でデザイナーとプログラマが開発の分業をしやすくなった。
Webアプリケーションフレームワークの時代
サーブレットやJSPの問題点
サーブレットやJSPでWebアプリケーションの開発は楽になったが、大規模アプリケーションを作成する際に0からコードを書くのは非常に時間と労力のかかるものだった。
また、開発者が勝手に独自のライブラリやクラスを作ってしまい、チーム開発がうまく回らないという事態も起こった。
そこで誕生したのがフレームワークである。
Webアプリケーションフレームワークの誕生
大規模アプリを効率よく作成するために、一度作成されたプログラムを再利用しようという動きが広まった。よく利用される処理（文字列やデータの操作）は、「ライブラリ」と呼ばれるプログラム部品として整備され、再利用された。
この再利用できる部分を増やして、アプリ開発をしやすくするための土台を「フレームワーク」という。
3.HTTPを知る
##3-1HTTPの知識はなぜ必要か
HTTP通信について詳しく知らなくてもフレームワークを使用すればWebアプリを作ることは可能である。
しかし、HTTP通信で何が起こっているか理解していないと、アプリが意図した動きをしないときに原因の究明が困難になるため、理解しておく必要がある。
3-2.WebブラウザとWebサーバの通信をのぞいてみよう
本書ではWindowsでHTTP通信の中身を確認する方法が記載されているが、ここではMacのデベロッパーツールを使用したHTTP通信ののぞき方を紹介する。
下記URLを参考に。
https://atmarkit.itmedia.co.jp/ait/articles/1610/21/news023.html
ここでは次のURLにアクセスした際のHTTP通信の中身を、デベロッパツールで確認。https://www.littleforest.jp/webtext/http/index.html
デベロッパーツールで確認できる情報のうち以下を説明する。
・メソッド
・URI
・HTTPバージョン
・Accept
・Accept-Language
・User-Agent
・Host
それぞれの役割を詳しくみてみよう。
・メソッド
リクエストの種類を表す。
WebブラウザからWebサーバへ送信されるリクエストの大半はGETメソッドになる。
・URI
GETメソッドで何の情報を欲しいのかを表す。
デベロッパーツールで調べた結果（上記スクリーンショット画像）では、https://www.littleforest.jp/webtext/http/index.htmlがURI
・HTTPバージョン
HTTPのバージョンによって利用できるメソッドの種類やリクエストヘッダの種類が変わる。
デベロッパーツールで調べた結果（上記スクリーンショット画像）では、HTTP1.1が使用されている。
・Accept
Webクライアントが受け取ることができるデータの種類を表す。データの形式はContent-Typeという形式で表される。
この情報がわかればWebサーバ側は、不要な情報を送らずに済む。
・Accept-Language
Webクライアントが受け取ることができる言語を示す。
デベロッパーツールで調べた結果（上記スクリーンショット画像）では、ja（日本語）,en-US（英語）となっている。
・User-Agent
利用しているWebブラウザの種類やバージョンを示す。
具体的な利用例としてWebサーバがAgent-fieldを参照して、スマホからのアクセスの場合スマホ用のHTMLを返すなどの役割をする。
また、利用者がどのブラウザを利用しているかの統計をとるのにも使われる。
・HOST
リクエストの送信先ホストやポート番号を指定する。
HTTPレスポンスについて
・頻出するステータスコード
| ステータスコード | 意味 | 説明 |
|---|---|---|
| 200 | OK | リクエストが正常に完了したことを表す |
| 302 | Found | リクエストされたリソースが一時的に別のURIに属していることを示す |
| 401 | Unauthorized | ユーザ認証に失敗したことを表す |
| 403 | Forbidden | アクセス権限がないため、サーバにリクエストの実行を拒否されたことを表す |
| 404 | Not Found | ブラウザに入力したURLが誤っていたときのエラー |
| 500 | Internal Server Error | CGIプログラムなどサーバ内部のプログラム実行においてエラーが発生したことを表す |
3-3.情報はどうやってインターネットの大海原を越えるのか
インターネット上の住所・IPアドレス
HTTPによるリクエストではリクエスト先のWebサーバはURLの中のホスト名の部分で表される。
https://www.littleforest.jp/webtext/http/index.html
上記URLではwww.littleforest.jpが要求先のWebサーバを示す。
しかしホスト名は人間に分かりやすいように表現されているにすぎず、コンピュータでは以下のようなIPアドレスで識別される。
192.168.0.1
IPアドレスはIPv4という通信プロトコル上では43億通り表すことができ、IPv6では340兆個表せる。
TCP/IP
IPアドレスを参照して情報を届ける役割を持つ。
TCP/IPでは送信する情報をパケットと呼ばれる小さな単位に分割することで、情報送信の効率化を図っている。
IPアドレスはICANNという組織に業務委任された、JPNICに申請しなければ割り当ててもらえないが、この作業はインターネットサービスプロバイダが行ってくれる。
グローバルアドレスとプライベートIPアドレス
このように割り当てられたインターネット上で唯一のアドレスを「グローバルIPアドレス」という。これは電話で例えると、重複のない固定電話番号。
一方で、IPアドレスはインターネット利用に限らず、コンピュータなどネットワーク機器同士の情報のやりとりにも必要となる、これを「プライベートIPアドレス」という。これは、電話の内線のようなものなので、他で使われても問題なく（重複可能）、申請は必要ない。
DNS
前述の通り、人間に理解できるURLだけではコンピュータが識別できないため、IPアドレスが使用される。そのためURLをIPアドレスに変換する必要がある。この作業はOSが行ってくれる。
IPアドレスを知るためには、DNS（ドメインネームシステム）に問い合わせる必要がある。
ターミナル（Macの場合）から、「nslookup ドメイン名」と打ち込みDNSサーバに問い合わせることで、ドメイン名に対応するIPアドレスがわかる。
ちなみにURLではなくIPアドレスを入力しても、同じWebページが表示される。
DNSサーバは複数存在する
前述の通りIPアドレスは43億個存在するため、その情報量が膨大すぎて処理が困難である。
そのためDNSサーバを多数用意して分散管理が行われている。
ポート番号
TCP/IPでは情報伝達の効率化のため、パケットという単位に分けて情報を送信するわけだが、これだけでは受信した側は、その情報のプロトコルやどのアプリケーションで処理すればいいかが判別できない。
そこで「ポート」が使われる。
TCP/IPによって情報を受け取るアプリケーションは「待受ポート」を決めて情報を持つ。ポートは0〜65535までの数字で表され、同じポートを複数のアプリケーションが利用することはできない。
ポート番号を定めることによって、送信された情報をどのアプリケーションが処理するか判別できるようになる。
先ほど確認したwww.littleforest.jp（192.168.0.1のIPアドレス）にはポート番号が記述されていなかったが、これはHTTPリクエストでは特に指定がない場合、自動でポート番号８０が割り当てられるからである。
各プロトコルで主に使われるポートは決まっており、このようなポートを「ウェル・ノウン・ポート」と呼ぶ。
＜代表的なウェル・ノウン・ポート＞
| ポート番号 | プロトコル |
|---|---|
| 20,21 | FTP（ファイル転送） |
| 22 | SSH（暗号化されたリモートコンピュータとの汎用通信） |
| 23 | Telnet（リモートコンピュータとの汎用通信） |
| 25 | SMPT（メール送信） |
| 53 | DNS（ホスト名解決） |
| 80 | HTTP（Webブラウジング） |
| 110 | POP3（メール受信） |
| 443 | HTTPS（暗号化されたHTTP） |
Webサーバへの要求をどのように伝えるか
上記HTMLフォームの２つのテキストフィールドには、「arg1」、「arg2」とname属性が付けられている。これによりテキストフィールドに入力された文字列が、「arg1」、「arg2」という名前でWebサーバに送られる。
では実際に、計算フォームに数字を入れて計算結果の詳細を確認しよう。
デベロッパーツールから、GETリクエストでフォームが送信されていることが確認できる。ここでリクエストURLを確認すると、計算後の情報URLの末尾が以下のように変わっていることがわかる。
このURLの?以降の部分を「クエリ文字列」と呼ぶ。これはフォームに入力された文字列をWebサーバに送るために使われる。
POSTメソッドによるパラメータ渡し
ここまでGETメソッドによるパラメータ渡しを実行したが、これには問題点がある。
それは、パラメータがURLに含まれているため、第三者に情報漏洩のリスクがあるという点。
また、URLの長さは２５５文字で制限されることが一般的なため、あまり多くの情報量を扱うことができない。
そこでPOSTメソッドによるパラメータ渡しが使われる。
POSTメソッドのパラメータ渡しでは、URLの末尾が/do_calc_post.phpとなり、POSTメソッドが使用されていることがわかる。
また、Payloadのタブからパラメータが確認可能。
これによりGETメソッドの問題は解決する。ただし、Webサーバにログが残る可能性もあるためセキュリティ性は高いが、完璧とは言えない。
＃＃＃ GETとPOSTどちらを使えばよい？
セキュリティ性が高いのならば、全てPOSTメソッドを使って情報の受け渡しをすればいいはずだが、GETにもメリットがある。
先ほど見たとおりGETメソッドで渡したステータスはURLに情報を格納するため、お気に入り機能やブックマークで記録することができる。
また、ブックマークなどで同じ検索結果を表示するためには、GETリクエストがシステムに影響を与えないものでなくてはいけない。（システムが変われば表示結果も変わってしまう。）
このように同じ要求を繰り返しても、同じ結果が得られることを「副作用がない」という。
GETリクエストとPOSTリクエストの使い分けは、ログイン処理などパスワードが必要な機能、決済処理などの副作用をともなう処理、クエリ文字列に収まりきらない大量の情報を扱うといった場合POSTリクエスト、それ以外はGETリクエストとする。
4.CGIからWebアプリケーションへ
本章では画面モックアップの必要性やシステム開発の流れについて触れている。
特にログイン機能の構造が複雑なため、理解を深めるためにログイン機能についての情報を本書からピックアップしてまとめていく。
ログイン認証機能の動作確認
上記はログイン機能を持つアプリケーションの、HTTP通信のログ。
ログインボタンを押した際のリクエストはdo_login.phpで確認可能。
ログイン時に使用したユーザー名、パスワードはPOSTメソッドで渡されており、Payloadタブから確認できる。
上記画像から分かる通り、ステータスコードは302 Foundとなっており、これはリクエストされたリソースが一時的に他のURLに移動していることを示す。
この、他のURLを示す箇所がResponse Headers内のLocationに存在する、item_list.phpである。
このように最初に要求したURLと異なるURLへ誘導することを「リダイレクト」という。
PHP実行の裏側の仕組み
do_login.phpというリソースに対してGETリクエストを行うと、PHPスクリプトが実行される仕組みだが、この仕組みの裏側について簡単にまとめていく。
今回アクセスしたサイトにはAppacheというWebサーバソフトウェアが採用されており、HTTPリクエストを受け取るとAppache内に元々用意されているモジュール（プログラム動作を拡張する部品）が、PHPスクリプトを実行してくれるようになっている。
CGIでは、クライアント→リクエスト→Webサーバ→CGI→プログラムの実行→CGI→Webサーバ→レスポンス→クライアントというプロセスでコンテンツが生成されていたのに対し、モジュールを使えばWebサーバとのやりとりのみで動作するため高速化できるメリットがある。
ただしCGIはたいていのWebサーバで利用できるのに対し、モジュールでは利用できるWebサーバが限られる。
例えば今回使用されたPHPエンジンのmod＿php５は、microsoft社のIISでは利用ができない。しかし有名な言語であれば大抵、言語別にWebサーバに対応したモジュールが用意されているため利用者にはあまり問題にはならない。
モジュール開発者からすると手間が増えるためデメリットとなる。
ログイン状態をどのようにして記憶するのか
ログイン認証には注意しなくてはならない点がある。
それは商品購入画面などログインしていないユーザから操作されると、アプリケーション利用者に大きな被害が出る可能性のあるページが存在するため、ログインしている状態を保持しなければならない点である。
しかし商品購入画面のURLを直接入力すればログインしなくても画面が表示されてしまう。
つまりHTTP通信では、状態を持つことができないのである、
ステートフルなプロトコルとステートレスなプロトコル
上記はFTP通信プロトコルのやりとりである。
上記のようにユーザ名、パスワードと入力しなければサーバとやり取りすることができない。これはFTPサーバが前回のリクエスト結果を覚えていてリクエストを実行しているということである。
FTPはリクエストに伴って状態が変わっていくので、状態を持つプロトコル「ステートフルプロトコル」と呼ばれる。
参考：macOSからTelnetでHTTP通信する方法
一方で、HTTPは1回のリクエストでやりとりが終了しているため状態を保たない「ステートレスプロトコル」と呼ぶ。
HTTPのメリットはオーバーヘッド（無駄な処理）が少ないことと、アカウント認証がない分実装が簡単な点である。
ステートレスなHTTP上で状態をどのように表現するか
４章までで紹介した手法で考えられる方法は、GETリクエストのパラメータとしてログイン情報を渡すか、ユーザ名とパスワードをPOSTリクエストパラメータとして毎回渡す方法。
前者の方法は、?login=ok をURL末尾に追加する形となるが、これでは誰でも認証をすり抜けられてしまうためアウト。
後者はPOSTリクエストの場合画面遷移前に必ずフォームを通さなければいけないため、非常に面倒な作業となってしまいやはり現実的ではない。
そこで登場したのが「Cookie」である。
Cookieを利用して状態を保持する
今回はcookieを利用できるようにしたphpファイルを使用して、Cookieの動作を確認していく。
リクエストヘッダにCookie: user=satou; pass=webtextの行が追加されているのが確認できる。これはフォームからユーザ名パスワードを記入してログインした結果。
では次に、アドレスバーにURLを直接入力した場合を見ていこう。
先ほどはConnectionとHostの間にCookieが入っていたが、今回は非表示となっている。
Cookieの仕組み
WebサーバからWebブラウザへ、HTTPレスポンスヘッダを利用して小さな情報を「名前＝値」の組み合わせで送り、これをCookieと呼ぶ。
WebサーバからCookieを受け取った Webブラウザは、次回同じ Webサーバにアクセスする際、受け取ったCookieをそのままHTTPリクエストヘッダに入れて送る。
Webアプリケーション側ではリクエストヘッダに入っているCookieを調べることで、アクセスしてきた相手がどのような相手なのか知ることができる。
一方、Cookieを受け取ったサーバと異なるWebサーバに対してはCookieを送らないため、意図しない情報がほかのWebサーバに送られてしまうことはない。
上記画像は、ログイン処理が終わった後のHTTPレスポンスである。Set-Cookieヘッダでuser=satou,pass=webtextという情報をブラウザに対して送っている。
setcookieの値は、プログラムのファイル側で任意に指定可能。
次にログアウト後のレスポンスを確認してみる。
ここで Set-Cookieにdeletedの値が入り、有効期限（expires属性）が過去の日付に変更されることで、Cookieが消去される。
安全に状態を保存する技術 セッション
CookieはHTTPのリクエストヘッダやレスポンスヘッダを利用して情報のやりとりを行う。
実際にデベロッパーツールを使って情報のやり取りをのぞいてきた通り、Cookieではユーザ名やパスワード、クレジットカート番号など第三者にバレると金銭的な被害が生じてしまう情報まで簡単に見ることができてしまう。
また、CookieはPC上にテキストファイルとして保存されており、やはり情報漏洩のリスクが高い。
そこで「セッション」と呼ばれる技術が生まれた。
chromeのcookie（クッキー）の保存場所は？cookieの確認・編集・削除方法を解説！
セッション
Webアプリケーションにおいてセッションとは、ログイン→商品選択→注文内容確認→ログアウトのような一連の処理の流れのことをいう。
セッションの状態はどこで保存するのか
１つのセッションが1回のやりとりで終了しないということは、セッションに付随する情報が必要であるということ。
そのセッションに付随する情報は、Webサーバ側で管理することになっている。
また、WebサーバとWebクライアントの間で商品の受付番号のみやりとりすることで、受付番号に対応したWebクライアント（ユーザー）の情報が受け渡しできる。
ここで利用する受付番号を「セッションID」という。
HTTPにおけるセッションIDの受け渡し方法の流れ
Webクライアントの1回目のリクエストの際に、WebサーバのレスポンスでセッションIDを持たせたCookieをWebクライアントに返す。
2回目以降はWebクライアント側のCookieにセッションIDが格納されているため、WebサーバはセッションIDからメモリの情報（ログイン状態やショッピングカードの中身）を参照して、復元することができる。
セッションID利用の実際を確認する
上記画像はログインの際のHTTP通信のログ。
リクエストにCookieが追加されており、PHPSESSIDという名前で数字とアルファベットの羅列が格納されている。
このセッションIDがどこでサーバから渡されたのかは一つ前（上）のリクエストdo_login/phpで確認できる。
上記画像のSet-Cookieの部分で、セッションIDが発行されているのがわかる。
5.Webアプリケーションの構成要素
WebアプリケーションはクライアントとサーバがHTTPによって通信することで実現されている。
論理的にはサーバには、Webサーバ、アプリケーションサーバ、データベースサーバの３種類が存在する。
クライアントサイドとサーバーサイド
ここまで説明してきた通りWebの世界はWebサーバとWebクライアント（Webブラウザ）が存在する。実際のシステムはWebクライアントは一台でも成り立つが、サーバ側は複数のコンピュータが存在し、役割分担をすることで高速に機能している。
小規模なシステムでは、サーバ側も一台のコンピュータで成り立つこともあるが、大規模システムではそうはいかず、数十台から数百台も必要とされることもある。
このサーバ側で動作するコンピュータを総称して「サーバサイド」、ブラウザ側のコンピュータを「クライアントサイド」という。
ノード（Node）
このように複数のコンピュータを組み合わせて１つのシステムを実現する場合、各コンピュータを「ノード（Node）」と呼ぶ。
データベースサーバの登場
Webサイトから商品を注文してくれた顧客情報を注文票など、紙の情報で管理すると、注文の多い時間帯や、売れた商品数などを調べるのに膨大な時間がかかってしまう。
そこで情報の検索や集計を、人間よりもはるかに早くできるデータベースが登場した。ただしデータベースは高性能ゆえに開発がとても難しく導入が困難なものとされる。
そのため、通常はデータベース管理システムが使われる。このシステムを利用すればコンピュータ上にデータベースを構築できるようになる。
データベースに対する操作
データベースに対する操作は、それぞれの頭文字をとって「CRUD(クラッド)」と呼ばれる。
Create、Read、Update、Deleteの頭文字である。また、データベースを操作する際に使う言語を「SQL」という。
データベースとクライアントの関係
データベースは独立して動作するプロセスであるため、何らかの方法でデータベースに対してSQLを渡して情報の抽出を依頼し、結果をもらう必要がある。
データベースとSQLのやり取りをする方法は二つ。
一つ目は「データベースクライアント」と呼ばれるもので、人間がSQLを入力し、直接データベース内の情報抽出や操作を行うものだ。
二つ目はWebアプリケーションのプログラムがSQLを発行する方法。
プログラムがデータベースの情報を確認しSQLを発行することで、HTMLを表示させれば新しい商品などの情報を追加する際にHTMLを修正せずに済む。
データベースサーバの分離
データベースを動作させる方法として、もっとも簡単なのはWebサーバ上で動作させることと言える。
こうすればデータベース用に新しいコンピュータを用意する必要がなく、Webサーバへデータベースをインストールするだけで済む。
ただしこの方法はアクセスが触れるとシステムダウンの恐れがある。そこで一般的にはサーバとデータベース用のコンピュータをそれぞれ用意することになる。
またDBサーバを分離するメリットはもう一つ、既存システムとの結合のしやすさがある。データベースにある情報資産をインターネット経由で利用できると、新しいWebのシステムを作る際に簡単にデータを拾うことができる。
そして、DBサーバだけを利用したいクライアントが存在する場合も、分離している方が好都合なのだ。
Webアプリケーションとデータベースの通信
ソフトウェアで異なるプロセス同士が情報交換をするには、例えばWebサーバやWebブラウザであればHTTPで通信する必要がある。
Webアプリとデータベースもやはり通信プロトコルが必要なのだが、データベース製品固有の通信プロトコルが標準で提供されているためあまり意識する必要はない。
アプリケーションサーバの登場
Servlet/JSPを動かすためのアプリケーションサーバ
Javaプログラムはコンピュータが直接実行するのではなく、JavaVMと呼ばれる仮想的なコンピュータが実行しているが、JavaVM上では「アプリケーションサーバ」と呼ばれるソフトウェアが動作している。
CGIとの違いとして、CGIはプロセスが一回ごとに終了するのに対し、JavaVMは常にプロセスが実行されている常駐型である。
Webサーバとアプリケーションサーバの連携
JavaによるWebアプリケーションでは、WebサーバとしてAppacheHTTPServerが、アプリケーションサーバとしてTomcatを使うことが一般的である。
前述の通りアプリケーションサーバ側にモジュールを用意し、連携を可能にしている（Tomcatの場合Appach向けにmod_jkが用意されている）。
Webサーバとアプリケーションサーバの分担
Webサーバとアプリケーションサーバを連携させる場合、通常の静的コンテンツ（HTMLファイル）はWebサーバ上に配置し、動的コンテンツとなるWebアプリケーションはアプリケーションサーバが担当する。
ここでWebサーバで受け取ったHTTPリクエストは、URLによってどのような処理をアプリケーションにさせるのか判別する。
Appacheに組み込まれているmod_jkによる連携では、接続先となるTomcatプロセスのことを「Tomcatワーカ」と呼ぶ。
Webサーバとアプリケーションサーバ連携のメリット
・アプリケーションサーバを別のノードで動かすことができる
・静的コンテンツのリクエストが多いWebサーバと、動的コンテンツのリクエストが多いアプリケーションサーバで役割分担ができる
Webサーバの機能を持ったアプリケーションサーバ
Tomcatのようなアプリケーションサーバは、ApacheなどのWebサーバと連携しなくても単独で使用することもできる。このやり方は設定の手間がないため、規模の小さいWebシステムや開発環境で使用されることが多い。
ただし、機能が少ないというデメリットもあるため、使いたい機能が存在しない場合は、Webサーバと連携する必要がある。
アプリケーションサーバの提供する代表的な機能
・セッション管理
セッションIDの発行や管理を行う
・トランザクション管理
一連の業務を確実に完了させるための機能。
ショッピングサイトでいえば、商品在庫を１つ減らす、クレジットカードの請求処理を行う、などまとめて実行すべき処理を「トランザクション」と呼ぶ。
・データベース接続の管理
サーバダウンやシステムパフォーマンスの低下を防ぐために、データベース接続はサーバが自動で行う。
・Webアプリケーションの官吏とシステムの可用性・性能の向上
複数のアプリケーションサーバを用意することで何らかの原因がサーバダウンした時に、別のサーバで処理する機能がある（可用性の向上）。
そのために「セッションレプリケーション」と言って、サーバ同士が連携してセッションの状態を共有する仕組みもある。
Webシステムの三層構成
システムの大小や、用途に応じてノードを分けたりといった変更はあるが、一点変わらない点は必ずサーバーサイドでは「Webサーバ」「APサーバ」「DBサーバ」が存在する。
これを「三層構成」と呼ぶ。