Loading article…
コンピュータ科学、特にネットワークにおいて、セッションとは、時間制限のある双方向リンクであり、TCP/IPプロトコルの実用的な（比較的高い）層で、 2つ以上の通信デバイスまたはエンド（コンピュータ、自動システム、またはアクティブなユーザー（ログインセッションを参照））間で対話的な表現と情報交換を可能にするものです。セッションは特定の時点で確立され、その後、ある時点で「切断」されます。確立された通信セッションでは、双方向で複数のメッセージがやり取りされる場合があります。セッションは通常ステートフルであり、通信を行う当事者の少なくとも一方が現在の状態情報を保持し、セッション履歴に関する情報を保存する必要があります。これに対し、ステートレス通信では、通信は独立した要求と応答で構成されます。
確立されたセッションは、コネクション指向通信を実行するための基本的な要件です。セッションは、コネクションレス通信モードで送信するための基本的なステップでもあります。ただし、単方向送信はセッションを定義するものではありません。[ 1 ]
通信トランスポートは、 OSIモデルのアプリケーション層、セッション層、またはトランスポート層のプロトコルおよびサービスの一部として実装される場合があります。
正式なセッション層を実装していないトランスポートプロトコル（UDPなど）や、アプリケーション層でのセッションが一般的に非常に短命なプロトコル（HTTPなど）の場合、セッションは、交換されるデータで定義された方法を使用して、上位レベルのプログラムによって維持されます。たとえば、ブラウザとリモートホスト間のHTTP通信には、一意のセッションID、ユーザーの設定情報、認証レベルなど、状態を識別するHTTP Cookieが含まれる場合があります。
HTTP/1.0では、1回のWeb/HTTPセッション中に1つのリクエストとレスポンスしか許可されないと考えられていました。プロトコルバージョンHTTP/1.1では、共通ゲートウェイインターフェース（CGI）を完成させることでこの点が改善され、Webセッションの維持が容易になり、 HTTPクッキーやファイルアップロードがサポートされるようになりました。
ほとんどのクライアント/サーバーセッションはトランスポート層によって維持され、1つのセッションにつき1つの接続が使用されます。しかし、Web/HTTPセッションの各トランザクションフェーズでは、それぞれ別の接続が作成されます。フェーズ間でセッションの継続性を維持するには、セッションIDが必要です。セッションIDは、動的Webページの<head>タグまたは<body>タグ内に埋め込まれ、CGIに渡されます。CGIは、このセッションIDを使用して、トランザクションフェーズ間のセッションの継続性を確保します。フェーズごとに1つの接続を使用する利点の1つは、低帯域幅（モデム）接続でもうまく機能することです。<A HREF><FORM>
TCPセッションは通常、子プロセスやマルチスレッドを使用してソフトウェアで実装されます。コンピュータがセッションを確立または参加する際に、新しいプロセスまたはスレッドが作成されます。HTTPセッションは通常、セッションごとに1つのスレッドを使用するのではなく、各セッションの状態に関する情報を含むデータベースを使用して実装されます。複数のプロセスまたはスレッドを使用する利点は、各スレッドが独自の履歴とカプセル化された変数を持つインスタンスであるため、ソフトウェアの複雑さが軽減されることです。欠点は、システムリソースのオーバーヘッドが大きいことと、システムが再起動されるとセッションが中断される可能性があることです。
クライアントがサーバークラスタ内の任意のサーバーに接続できる場合、サーバーがセッション状態を維持しなければならない際に、一貫性を保つ上で特別な問題が発生します。クライアントはセッション期間中、同じサーバーに接続されるか、サーバーは共有ファイルシステムまたはデータベースを介してサーバー側のセッション情報を送信する必要があります。そうしないと、クライアントはセッションを開始したサーバーとは異なるサーバーに再接続する可能性があり、新しいサーバーが以前のサーバーの保存された状態にアクセスできない場合に問題が発生します。
サーバーサイドセッションは便利で効率的ですが、負荷分散／高可用性システムと組み合わせると扱いが難しくなる場合があり、ストレージのない一部の組み込みシステムでは全く使用できません。負荷分散の問題は、共有ストレージを使用するか、クラスタ内の各クライアントと単一のサーバー間で強制ピアリングを適用することで解決できますが、これによりシステム効率と負荷分散が損なわれる可能性があります。
大容量ストレージを持たないシステムでサーバー側セッションを使用する方法の一つとして、セッションデータの保存用にRAMの一部を確保する方法がある。この方法は、クライアント数が限られているサーバー（例えば、ルーターやアクセスポイントなど、一度に複数のクライアントからのアクセスがまれであるか、または許可されていないサーバー）に適用できる。
クライアント側のセッションでは、サーバーに大量のデータを保存することなく状態を維持するために、 Cookieと暗号化技術が使用されます。動的なWebページを表示する際、サーバーは現在の状態データをCookieの形式でクライアント（Webブラウザ）に送信します。クライアントはCookieをメモリまたはディスクに保存します。その後、クライアントはリクエストごとにCookieをサーバーに送信し、サーバーはそのデータを使用して特定のクライアントのアプリケーションの状態を「記憶」し、適切な応答を生成します。
このメカニズムは一部の状況ではうまく機能するかもしれませんが、クライアントに保存されたデータは、ユーザーまたはクライアントコンピュータにアクセスできるソフトウェアによる改ざんに対して脆弱です。機密性と完全性が求められるクライアント側セッションを使用するには、以下の点が保証されなければなりません。
これを実現するには、サーバーはセッションデータをクライアントに送信する前に暗号化する必要があり、暗号化手段によって第三者による情報の改ざんを防止する必要がある。
リクエストごとに状態を送受信するのは、クッキーのサイズが小さい場合にのみ実用的です。つまり、クライアント側のセッションは、サーバーのディスク容量を犠牲にして、各Webリクエストに必要な帯域幅を確保していると言えます。さらに、Webブラウザは、Webサイトが保存できるクッキーの数とサイズを制限しています。効率を向上させ、より多くのセッションデータを保存できるようにするために、サーバーはクッキーを作成する前にデータを圧縮し、クライアントからクッキーが返された後に解凍することがあります。
セッショントークンは、現在のインタラクションセッションを識別するためにサーバーからクライアントに生成される一意の識別子です。クライアントは通常、このトークンをHTTP Cookieとして保存して送信するか、GETまたはPOSTクエリのパラメータとして送信します。セッショントークンを使用する理由は、クライアントは識別子のみを処理すればよいからです。すべてのセッションデータは、その識別子に関連付けられたサーバー（通常はクライアントが直接アクセスできないデータベース）に保存されます。一部のプログラミング言語がHTTP Cookieに名前を付ける際に使用する名前の例としては、JSESSIONID（JSP）、PHPSESSID（PHP）、CGISESSID（CGI）、ASPSESSIONID（ASP）などがあります。
人間とコンピュータのインタラクションにおいて、セッション管理とは、コンピュータシステムとのインタラクションセッション全体にわたって、ユーザーの活動を追跡するプロセスである。
デスクトップ環境における一般的なセッション管理タスクには、現在開いているアプリケーションと、各アプリケーションが開いているドキュメントを追跡し、ユーザーがログアウトして後でログインした際に同じ状態を復元できるようにすることが含まれます。Webサイトの場合、セッション管理には、セッションの有効期限が切れた場合（つまり、一定時間ユーザー操作がない場合）にユーザーに再ログインを要求することが含まれる場合があります。また、HTTPリクエスト間でサーバー側に情報を保存するためにも使用されます。
デスクトップセッションマネージャとは、デスクトップセッションを保存および復元できるプログラムです。デスクトップセッションとは、現在実行中のすべてのウィンドウとその現在のコンテンツのことです。Linuxベースのシステムでは、セッション管理はXセッションマネージャによって提供されます。Microsoft Windowsシステムでは、セッション管理はセッションマネージャサブシステム（smss.exe）によって提供されます。ユーザーセッション機能は、 twinsplayなどのサードパーティ製アプリケーションによって拡張できます。
セッション管理は、ユーザーが開いているすべてのページと設定を保存し、後日または別のコンピュータで復元できるウェブブラウザで特に役立ちます（データポータビリティを参照）。
システムやアプリケーションのクラッシュからの復旧を支援するため、次回の起動時にページや設定を復元することもできます。Google Chrome、Mozilla Firefox、Internet Explorer、OmniWeb、Operaなどは、セッション管理をサポートするWebブラウザの例です。セッション管理は、多くの場合、 Cookieを使用して行われます。
ハイパーテキスト転送プロトコル（HTTP）はステートレスです。セッション管理は、Web開発者がステートレスなHTTPプロトコルでセッション状態をサポートするために使用する技術です。たとえば、ユーザーがWebサーバーで認証されると、次のHTTPリクエスト（GETまたはPOST）でWebサーバーがユーザーのアカウントとパスワードを再度要求することはありません。これを実現するために使用される方法については、HTTP CookieとセッションIDを参照してください。
複数の Web サーバーがセッションの状態に関する情報を共有する必要がある場合 (クラスタ環境では一般的です)、Web サーバー ソフトウェアを実行しているクラスタ ノード間でセッション情報を共有する必要があります。クラスタ内のノード間でセッション状態を共有する方法には、メンバー ノードへのセッション情報のマルチキャスト (この手法の 1 つの例についてはJGroups を参照)、分散共有メモリまたはメモリ仮想化を使用してパートナー ノードとセッション情報を共有する、ネットワーク ソケットを使用してノード間でセッション情報を共有する、分散ファイルシステムやグローバル ファイルシステムなどの共有ファイルシステムにセッション情報を保存する、またはクラスタ外のデータベースにセッション情報を保存する、などがあります。
セッション情報が、取引の否認防止に必要ではなく、コンプライアンス監査の対象となるデータを含まない一時的で揮発性の高いデータとみなされる場合（例えば、米国では、コンプライアンス監査を義務付ける法律の例として、医療保険の携行性と説明責任に関する法律（ HIPAA）とサーベンス・オクスリー法を参照）、セッション情報の保存方法はどのようなものでも使用できます。ただし、セッション情報が監査コンプライアンスの対象となる場合は、セッションの保存、複製、クラスタリングに使用する方法について検討する必要があります。
サービス指向アーキテクチャでは、 コンシューマーアプリケーションは、拡張マークアップ言語（XML ）メッセージで構築されたシンプルオブジェクトアクセスプロトコル（ SOAP）メッセージを使用して、Webサーバーにセッションを作成させることができます。
HTTP がステートレス プロトコルであるのと同様に、SMSもステートレス プロトコルです。1999 年に SMS が競合ネットワーク間で相互運用可能になり[ 2 ]、テキスト メッセージングがユビキタスなグローバルなコミュニケーション形態へと成長し始めたため[ 3 ]、さまざまな企業が SMS チャネルを商用目的で使用することに関心を持つようになりました。初期のサービスは、一方通行の通信のみであったため、セッション管理は必要ありませんでした (たとえば、2000 年にフィンランドで最初のモバイル ニュース サービスが SMS 経由で配信されました)。今日では、これらのアプリケーションは、ピア ツー ピア(P2P) メッセージングとは区別して、アプリケーション ツー ピア(A2P)メッセージングと呼ばれています。インタラクティブなエンタープライズ アプリケーションの開発にはセッション管理が必要でしたが、SMS は GSM 規格で定義されているステートレス プロトコルであるため[ 4 ] 、初期の実装では、エンド ユーザーがコマンドとサービス識別子を手動で入力することでクライアント側で制御されていました。