この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "セッション" コンピュータ – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2017年7月） |
計算機科学における特定のネットワーク接続において、セッション(英: session)とは、2台以上の通信機器間の、またはコンピュータとユーザ間 (ログインセッション︵英語版︶参照) の半永久的な双方向情報交換 (ダイアログ (dialogue)、会話、または会議とも) のことである。セッションはある時点で作成または確立され、その後のある時点で破棄される。確立した通信セッションでは、各方向に1通以上のメッセージを送信することができる。セッションは概してステートフル︵英語版︶、つまり通信を可能にするために最低1つの通信内容部にセッション履歴情報を保存する必要があるが、これは通信がレスポンスと独立のリクエストで構成されるステートレス・プロトコル通信とは正反対である。
セッションの確立は、コネクション指向通信︵英語版︶を行う際の基本要件である。また、セッションはコネクションレス型通信モードで送信する際の基本ステップである。ただし、一方向性送信ではセッションは定義されない。
OSI参照モデルのアプリケーション層、セッション層、またはトランスポート層のプロトコルおよびサービスの一部として、通信トランスポートが実装される場合がある。
●アプリケーション層の例:
●HTTPセッションにより各訪問者への情報の関連付けが可能になる。
●telnetによるリモートログインセッション
●セッション層の例:
●SIPベースのインターネット電話の発呼
●トランスポート層の例:
●TCPセッション (TCP仮想回線、TCPコネクション、または確立したTCPソケットの同義語)
フォーマルなセッション層を実装しない場合 (UDP等)、あるいはアプリケーション層のセッション持続期間が非常に短い場合 (HTTP等)、セッションは交換されるデータ内で定義された方法を用いて上位のプログラムによって維持される。たとえば、ブラウザとリモートホスト間のHTTPデータ交換では、一意のセッションID、ユーザの設定情報、または権限レベル等の状態を識別するためのHTTPクッキーが含まれる場合がある。
HTTP/1.0では、1回のWeb/HTTPセッションにつきリクエストとレスポンスを1つだけやり取りすることが期待されていた。これはHTTP/1.1プロトコルバージョンでCGIが完成したことで改善され、ウェブセッションの維持とHTTPクッキーおよびファイルアップロードへの対応が容易になった。
大半のクライアントサーバセッションは、トランスポート層において1セッションにつき1コネクションで維持される。ただし、Web/HTTPの各トランザクションフェーズで異なるコネクションが作成される。フェーズ間でセッションが途切れないようにするには、セッションIDが必要になる。セッションIDは動的ウェブページの<A HREF>または<FORM>リンク内に埋め込み、CGIに返せるようにする。するとCGIは、そのセッションIDを使うことでトランザクションフェーズ間でセッションが続いたままにできる。1フェーズ1コネクションの利点として、低帯域 (モデム) 接続でもうまく機能する点が挙げられる。
TCPセッションは一般的に子プロセスやマルチスレッドを用いてソフトウェアで実装され、コンピュータがセッションの確立またはセッションへの参加をすると新規プロセスまたはスレッドが作成される。HTTPセッションは一般的に1セッション1スレッド方式ではなく、各セッションの状態情報を持つデータベースを用いて実装される。マルチプロセスまたはマルチスレッドを用いる利点は、各スレッドが独自の履歴とカプセル化された変数を持つインスタンスとなるため、ソフトウェアの複雑性が緩和されることである。欠点は、システムリソースに関するオーバーヘッドが大きいこと、そしてシステムが再起動するとセッションが中断される可能性があることである。
クライアントがサーバクラスタ内のどのサーバにも接続する可能性があり、サーバがセッション状態を維持しなければならない場合、一貫性の維持において特別な問題が発生する。セッションが維持される間、クライアントを同一のサーバにルーティングするか、あるいはクラスタ側でセッション情報を共有ファイルシステムまたはデータベースを介してサーバ間で伝達し合わなければならない。そうしないと、クライアントがセッション開始時のとは異なるサーバに再接続し、そのサーバが前回保存されたセッション状態にアクセスできず、問題が発生する恐れがある。
サーバサイドセッションは扱いやすく効率的だが、負荷分散／高可用性システムが絡むと困難になる恐れがあり、また、ストレージを持たない組み込みシステムの一部では全く使用できない。負荷分散の問題は、共有ストレージの使用またはクライアントごとに1台のクラスタ内サーバとピアリングを結ばせることで解決できるが、システムの効率性と負荷の配分が損なわれる恐れがある。
大容量ストレージを持たないシステムでは、サーバサイドセッションを使う際、セッションデータの保存用にRAMを確保する方法がある。この方法は、クライアント数が限られているサーバに適用できる (クライアントへの同時アクセスが稀であるか許可されていないルータやアクセスポイント等)。
クライアントサイドのセッションではステートの維持にクッキーと暗号化の技術が使用され、サーバ上に保存されるデータはそれほど大きくない。動的ウェブページを提供する際、サーバは現在のステートデータをクッキー形式でクライアント (ウェブブラウザ) に送信する。クライアントはクッキーをメモリまたはディスクに保存する。その後の各リクエストでは、クライアントはクッキーをサーバに送り返し、サーバはそのクッキーデータを使って特定のクライアント用のアプリケーションステートを﹁思い出し﹂、適切なレスポンスを生成する。
この仕組みは状況によっては十分に機能し得るが、クライアント上に保存されたデータは、クライアントにアクセスできるユーザまたはソフトウェアによる改竄に対して脆弱である。機密性と整合性が要求される状況でクライアントサイドセッションを使用するには、以下の項目を保証しなければならない。
(一)機密性: 該当のサーバ以外はセッションデータを解釈できないこと。
(二)データの整合性: 該当のサーバ以外は (偶然か故意かに関わらず) セッションデータを操作できないこと。
(三)真正性: 該当のサーバ以外は有効なセッションを開始できないこと。
これを達成するには、サーバはデータをクライアントに送信する前にセッションを暗号化する必要があり、第三者による当該情報の変更は暗号手法によって防止すべきである。
すべてのリクエストでステートを送受信する方法の実用性は、クッキーのサイズが小さい場合に限られる。本質的に、クライアントサイドのセッションでは、サーバのディスク容量がウェブリクエストごとに余分に必要となる帯域に交換される。さらに、ウェブブラウザはウェブサイトごとに保存できるクッキーの数とサイズを制限している。効率を改善し、より多くのセッションデータを扱えるようにするため、サーバ側でデータを圧縮してからクッキーを作成し、クライアントからクッキーが返されたら解凍することも考えられる。
セッショントークンは、現在の対話セッションを識別するためにサーバが生成してクライアントに送信する一意の識別子である。クライアントは通常、トークンをHTTPクッキーとして保存して送信し、そして／またはGETクエリまたはPOSTクエリのパラメタとしてトークンを送信する。セッショントークンを使うのは、クライアント側で扱う情報が識別子だけで済む、あるいはすべてのセッションデータがその識別子に関連付けられてサーバ上に保存される (通常データベースに保存され、クライアントはデータベースに直接アクセスすることはできない) ためである。プログラミング言語によるHTTPクッキーの命名例には、JSESSIONID (JSP)、PHPSESSID (PHP)、CGISESSID (CGI)、そしてASPSESSIONID (ASP) 等がある。
ヒューマンマシンインタラクションにおいて、セッション管理とは、コンピュータシステムとの対話セッション全体でユーザの活動を追跡するプロセスのことである。
デスクトップ環境での典型的なセッション管理内容には、開いてあるアプリケーションや各アプリケーションが開いている文書を記録し、ユーザがログアウトして再ログインした際に同一のステートを復元できるようにすること等がある。ウェブサイトの場合、セッション管理はセッションが期限切れとなったユーザ (つまり、ユーザが活動せずに一定時間が経過した場合) に再ログインを要求するために使用される場合がある。HTTPリクエスト間でサーバ側に情報を保存するのにも使用される。
デスクトップセッションマネージャは、デスクトップセッションの保存と復元を行うことができるプログラムである。デスクトップセッションとは、現在実行中のすべてのウインドウとその内容のことである。Linuxベースのシステムでは、セッション管理はXセッションマネージャによって提供される。マイクロソフトWindowsのシステムでは、セッション管理はセッションマネージャサブシステム (smss.exe) によって提供されるが、ユーザセッション機能はtwinsplay等のサードパーティ製のアプリケーションで拡張することができる。
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メッセージをコンシューマアプリケーションで使用してウェブサーバにセッションを作成させることができる。
HTTPと同様にSMSもステートレスプロトコルである。米国では、1999年にSMSが他社ネットワーク間で相互利用できるようになり、[1] テキストメッセージがユビキタスでグローバルな通信形態へと普及し始めるにつれ、[2] 様々な企業が商業目的でのSMS活用に関心を向け始めた。サービスは当初一方向通信であったため、セッション管理は必要なかった。今日では、こうした応用例はアプリケーション・ツー・パーソン (A2P) メッセージングと呼ばれるが、これはパーソン・ツー・パーソン (P2P) メッセージングとは全く異なる。対話型の企業アプリケーションの開発にはセッション管理が必要であったが、SMSはGMS標準で定義されているようにステートレスプロトコルであるため、[3] 初期の実装はエンドユーザにコマンドとサービス識別子を手動入力させることでクライアントサイドで制御された。
