セッション (コンピュータ)

ソフトウェア実装

TCPセッションは一般的に子プロセスやマルチスレッドを用いてソフトウェアで実装され、コンピュータがセッションの確立またはセッションへの参加をすると新規プロセスまたはスレッドが作成される。HTTPセッションは一般的に1セッション1スレッド方式ではなく、各セッションの状態情報を持つデータベースを用いて実装される。マルチプロセスまたはマルチスレッドを用いる利点は、各スレッドが独自の履歴とカプセル化された変数を持つインスタンスとなるため、ソフトウェアの複雑性が緩和されることである。欠点は、システムリソースに関するオーバーヘッドが大きいこと、そしてシステムが再起動するとセッションが中断される可能性があることである。
クライアントがサーバクラスタ内のどのサーバにも接続する可能性があり、サーバがセッション状態を維持しなければならない場合、一貫性の維持において特別な問題が発生する。セッションが維持される間、クライアントを同一のサーバにルーティングするか、あるいはクラスタ側でセッション情報を共有ファイルシステムまたはデータベースを介してサーバ間で伝達し合わなければならない。そうしないと、クライアントがセッション開始時のとは異なるサーバに再接続し、そのサーバが前回保存されたセッション状態にアクセスできず、問題が発生する恐れがある。

サーバサイドのウェブセッション

サーバサイドセッションは扱いやすく効率的だが、負荷分散／高可用性システムが絡むと困難になる恐れがあり、また、ストレージを持たない組み込みシステムの一部では全く使用できない。負荷分散の問題は、共有ストレージの使用またはクライアントごとに1台のクラスタ内サーバとピアリングを結ばせることで解決できるが、システムの効率性と負荷の配分が損なわれる恐れがある。
大容量ストレージを持たないシステムでは、サーバサイドセッションを使う際、セッションデータの保存用にRAMを確保する方法がある。この方法は、クライアント数が限られているサーバに適用できる (クライアントへの同時アクセスが稀であるか許可されていないルータやアクセスポイント等)。

HTTPセッショントークン

セッショントークンは、現在の対話セッションを識別するためにサーバが生成してクライアントに送信する一意の識別子である。クライアントは通常、トークンをHTTPクッキーとして保存して送信し、そして／またはGETクエリまたはPOSTクエリのパラメタとしてトークンを送信する。セッショントークンを使うのは、クライアント側で扱う情報が識別子だけで済む、あるいはすべてのセッションデータがその識別子に関連付けられてサーバ上に保存される (通常データベースに保存され、クライアントはデータベースに直接アクセスすることはできない) ためである。プログラミング言語によるHTTPクッキーの命名例には、JSESSIONID (JSP)、PHPSESSID (PHP)、CGISESSID (CGI)、そしてASPSESSIONID (ASP) 等がある。

セッション管理

ヒューマンマシンインタラクションにおいて、セッション管理とは、コンピュータシステムとの対話セッション全体でユーザの活動を追跡するプロセスのことである。
デスクトップ環境での典型的なセッション管理内容には、開いてあるアプリケーションや各アプリケーションが開いている文書を記録し、ユーザがログアウトして再ログインした際に同一のステートを復元できるようにすること等がある。ウェブサイトの場合、セッション管理はセッションが期限切れとなったユーザ (つまり、ユーザが活動せずに一定時間が経過した場合) に再ログインを要求するために使用される場合がある。HTTPリクエスト間でサーバ側に情報を保存するのにも使用される。

デスクトップセッション管理

デスクトップセッションマネージャは、デスクトップセッションの保存と復元を行うことができるプログラムである。デスクトップセッションとは、現在実行中のすべてのウインドウとその内容のことである。Linuxベースのシステムでは、セッション管理はXセッションマネージャによって提供される。マイクロソフトWindowsのシステムでは、セッション管理はセッションマネージャサブシステム (smss.exe) によって提供されるが、ユーザセッション機能はtwinsplay等のサードパーティ製のアプリケーションで拡張することができる。

ブラウザセッション管理

セッション管理はウェブブラウザで特に有用で、開いてあるページと設定をすべて保存して後日復元することができる。また、システムまたはアプリケーションのクラッシュからの復旧を支援するため、ページと設定を次回起動時に復元することがある。Google Chrome、Mozilla Firefox、Internet Explorer、OmniWeb、そしてOperaは、セッション管理に対応したウェブブラウザの例である。セッション管理にはクッキーを応用することが多い。

ウェブサーバセッション管理

HTTPはステートレスであるため、ウェブブラウザを実行するクライアントコンピュータは、HTTP GETリクエストまたはPOSTリクエストごとにTCPネットワークコネクションをウェブサーバに対して確立しなければならない。従ってウェブサーバは、単一のHTTP GETまたはPOSTオペレーションより長い間、確立したTCPネットワークコネクションを使用することはできない。セッション管理は、ウェブ開発者がステートレスなHTTPプロトコルをセッションステートに対応させるために使う技術である。たとえば、一度ウェブサーバに承認されたら、次のHTTPリクエスト (GETまたはPOST) でサーバから再びアカウントとパスワードを求められることは起こるべきではない。これを達成するために使用される方法の議論については、HTTPクッキーとセッションIDを参照のこと。
複数のウェブサーバがセッション状態を共有しなければならない状況 (クラスタ環境で一般的である) では、セッション情報はウェブサーバソフトウェアを実行しているクラスタノード間で共有しなければならない。クラスタのノード間でセッション状態を共有する方法には、マスタノードへのセッション情報のマルチキャスト (このテクニックの一例についてはJGroupsを参照のこと)、分散共有メモリまたはメモリ仮想化を用いたパートナーノードとのセッション情報の共有、ネットワークソケットを用いたノード間でのセッション情報の共有、分散ファイルシステムまたはグローバルファイルシステム等の共有ファイルシステム上へのセッション情報の保存、またはセッション情報のクラスタ外のデータベースへの保存、等がある。
トランザクションの否認不可性に必要ではなく、かつ遵法監査の対象 (遵法監査を要する次の2つの米国の法律の例については、w:Health Insurance Portability and Accountability Actとw:Sarbanes-Oxley Actを参照) となっていない、トランジェントな揮発性データだと見なされるセッション情報には、どのような保存方法も使用できる。しかし、セッション情報が遵法監査の対象となる場合、セッションの保存、レプリケーション、そしてクラスタリングに使用する方法を慎重に検討すべきである。
サービス指向アーキテクチャでは、XMLメッセージで構築されたSOAPメッセージをコンシューマアプリケーションで使用してウェブサーバにセッションを作成させることができる。

SMSでのセッション管理

HTTPと同様にSMSもステートレスプロトコルである。米国では、1999年にSMSが他社ネットワーク間で相互利用できるようになり、 テキストメッセージがユビキタスでグローバルな通信形態へと普及し始めるにつれ、 様々な企業が商業目的でのSMS活用に関心を向け始めた。サービスは当初一方向通信であったため、セッション管理は必要なかった。今日では、こうした応用例はアプリケーション・ツー・パーソン (A2P) メッセージングと呼ばれるが、これはパーソン・ツー・パーソン (P2P) メッセージングとは全く異なる。対話型の企業アプリケーションの開発にはセッション管理が必要であったが、SMSはGMS標準で定義されているようにステートレスプロトコルであるため、 初期の実装はエンドユーザにコマンドとサービス識別子を手動入力させることでクライアントサイドで制御された。