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

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

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

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

■クライアントでのセッションIDの保持：クライアントはサーバーから応答を受け取ると付随して返されてきたCookieを保存します。 クライアントは２回目のアクセスの際には、サーバーから与えられたCookieを要求に付随して送ります。

■サーバーでのクライアントの識別：２回目のクライアントの要求があると、サーバーは送られてきたセッションIDに対応したセッション・オブジェクトを取得し、 そのセッション・オブジェクトからクライアントのユーザー情報を取得します。選択した商品情報などがある場合は、そのセッション・オブジェクトに格納します。

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

サーバーでのセッション管理には2通りの範囲があります。どちらもweb.xmlの設定になりますが、編集するweb.xmlが異なります。

①Webコンテナ（アプリケーション・サーバー）単位%CATALINA_HOME%\conf\下にあるweb.xmlに< session-config >の設定を記述します。 この設定は、Webコンテナ全体の設定です。Webモジュールで設定を上書きしない限り、Webコンテナ上で動作するwebモジュール全てに有効です。

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

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

① SSL(Secure Socket Layer)のSSL ID：httpsプロトコルで情報を暗号化して通信を行う際に、 共通鍵を識別するために使用するSSL IDをセッションIDとして利用する方法です。 httpsでの通信は情報の暗号化、及び復元の処理に負荷がかかるため、パフォーマンスが落ちるという問題点があります。

②Cookie(デフォルト)：セッションIDのデフォルトの配布媒体です。 セッション管理で使用するCookieはブラウザが開いている間有効な一時Cookieです。 Cookieはブラウザの設定でオフにすることができるので、注意が必要です。

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

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

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

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