1. HTTPプロトコルは、インターネット上でクライアントであるブラウザの要求をサーバーに届け、 サーバーからの応答を
クライアントのブラウザに返すための通信プロトコルです。
HTTPプロトコルの通信は、一回のクライアントからサーバーへの要求、サーバーからクライアントへの応答が通信の単位
となっており、 一回の通信ごとに接続を切断し処理を終了します。一回のアクセスごとに通信接続を切断するので、以前
の通信の情報を保持することができません。 この以前の情報を保持することができないプロトコルのことをステートレス
（状態をもたない）なプロトコルといいます。

2. ■ステートレスなプロトコルの問題点
：Webアプリケーションで実現するサイトは、以前の通信の情報を保持する必要があります。
たとえばショッピング・サイトのアプリケーションでは、ユーザーがログイン後に、商品の選択画面、決済画面へと複数
の画面に遷移をしますが、 すべての処理でログイン時のユーザー情報を保持している必要があります。HTTPプロトコルで
Webアプリケーションを実現するためには、 ステートレスなプロトコルを使いながらも、何らかの形で情報を保持する必要
があります。

3. セッションとは、１クライアントがサーバーと交わす一連のアクセスのまとまりです。 複数クライアントからの要求を
それぞれのセッションと関連付けて、どのクライアントからの要求かをサーバー側で識別することをセッション管理とい
います。

4. ■サーバーでのセッションIDの作成
：クライアントのユーザー情報を格納する情報格納箱であるセッション・オブジェクトを作成します。
セッション・オブジェクトは、クライアントとの一連のやり取りの間、サーバーのメモリ内に保持されます。 セッショ
ン・オブジェクトを作成する際に、どのクライアントのものなのかを識別するセッションIDを生成し、 セッションIDと
セッション・オブジェクトの対応関係をセッション・テーブルという表に記述します。 サーバーは作成したセッション
IDをCookieに保存し、クライアントへの応答時に付随して返します。Cookie名はJSESSIONIDと定められています。

5. ■クライアントでのセッションIDの保持：クライアントはサーバーから応答を受け取ると付随して返されてきたCookieを
保存します。 クライアントは２回目のアクセスの際には、サーバーから与えられたCookieを要求に付随して送ります。
■サーバーでのクライアントの識別：２回目のクライアントの要求があると、サーバーは送られてきたセッションIDに対
応したセッション・オブジェクトを取得し、 そのセッション・オブジェクトからクライアントのユーザー情報を取得しま
す。選択した商品情報などがある場合は、そのセッション・オブジェクトに格納します。

6. サーバーでのセッションの取り扱いです。
セッションに対する設定としては、セッション・タイムアウトがあります。セッション・タイムアウトとは、 セッショ
ン･オブジェクトが使用されずに残っている場合、削除するためのタイムアウト時間です。 各Webアプリケーションの
web.xmlに上図の設定を記述します。
< session-timeout>で設定する単位は「分」です。デフォルトは30分です。

7. サーバーでのセッション管理には2通りの範囲があります。どちらもweb.xmlの設定になりますが、編集するweb.xmlが異な
ります。
①Webコンテナ（アプリケーション・サーバー）単位
%CATALINA_HOME%conf下にあるweb.xmlに< session-config >の設定を記述します。 この設定は、Webコンテナ全体の
設定です。Webモジュールで設定を上書きしない限り、Webコンテナ上で動作するwebモジュール全てに有効です。

8. ②Webモジュール単位
%CATALINA_HOME%webappsWebアプリケーション名WEB-INF下にあるweb.xmlに< session-config >の設定を記述しま
す。 この設定はWebコンテナの設定を上書きします。Webモジュール独自のタイムアウトの設定をする際に利用します。

9. アプリケーション・サーバーとクライアント間でセッションIDを共有する仕組みのことを、セッション・トラッキング・メ
カニズムといいます。 セッション・トラッキング・メカニズムには、セキュリティの高い順に以下の仕組みがあります。
セッション・トラッキング・メカニズムの優先順位はセキュリティの高い順になります。

10. ① SSL(Secure Socket Layer)のSSL ID：httpsプロトコルで情報を暗号化して通信を行う際に、 共通鍵を識別するために使用
するSSL IDをセッションIDとして利用する方法です。 httpsでの通信は情報の暗号化、及び復元の処理に負荷がかかるため、
パフォーマンスが落ちるという問題点があります。
②Cookie(デフォルト)：セッションIDのデフォルトの配布媒体です。 セッション管理で使用するCookieはブラウザが開いて
いる間有効な一時Cookieです。 Cookieはブラウザの設定でオフにすることができるので、注意が必要です。

11. ③ URL再書き込み：ブラウザでCookieを無効に設定している場合に使用する方法です。 URL再書き込みを使用する場合に
は、プログラム上でURL再書き込みを行うコーディングをする必要があり HttpServletResposeインターフェースの次のメ
ソッドを使用します。
・ public String encodeURL(String url)
・ public String encodeRedirectURL(String url)

12. セッション管理には、Managerという実装が用意されており、デフォルトではStandardManagerが設定されています。
StandardManagerは、Tomcatが正常に停止すると現在のセッションの情報を%CATALINA_HOME%workCatalinaホス
ト名Webアプリケーション名SESSION.serファイルに保管します。 再起動する際には、このファイルからセッション情
報をロードした上でファイルを削除します。 そのため、Tomcatが異常終了した場合はファイルが作成されず、セッショ
ンの情報が失われます。

13. セッション情報を永続化しておきたい場合は、ファイルまたはデータベースに保管可能なPersistentManagerに設定しま
す。

14. 図はPersistentManager の例です。
セッションID.sessionというファイル名で保管されます。保存先のフォルダを指定しなければ、 %CATALINA_HOME%
workCatalinaホスト名Webアプリケーション名フォルダに保管されます。