セッション（コンピュータサイエンス）

コンピュータサイエンス、特にネットワークにおいては、セッションとは時間制限のある双方向リンクであり、TCP/IP プロトコルの実用的な (比較的高い) レイヤーであり、2 つ以上の通信デバイスまたは端末 (コンピュータ、自動化システム、またはライブでアクティブなユーザー (ログイン セッションを参照))間での対話型の表現と情報交換を可能にします。セッションは特定の時点で確立され、その後のある時点で「破棄」、つまり終了します。確立された通信セッションには、各方向に複数のメッセージが含まれる場合があります。セッションは通常、ステートフルです。つまり、通信が独立した要求と応答で構成されるステートレス通信とは対照的に、通信する側の少なくとも一方が現在の状態情報を保持し、セッション履歴に関する情報を保存して通信できるようにする必要があります。

確立されたセッションは、コネクション型通信を実行するための基本的な要件です。セッションは、コネクションレス型通信モードで送信するための基本的なステップでもあります。ただし、単方向の送信ではセッションは定義されません。^[1]

通信トランスポートは、OSI モデルのアプリケーション層、セッション層、またはトランスポート層のプロトコルおよびサービスの一部として実装される場合があります。

• アプリケーション層の例:
  • HTTPセッションにより、個々の訪問者と情報を関連付けることができます。
  • Telnetリモートログインセッション
• セッション層の例:
  • セッション開始プロトコル（SIP）ベースのインターネット電話通話
• トランスポート層の例:
  • TCPセッション。TCP仮想回線、TCP 接続、または確立された TCPソケットと同義です。

正式なセッション層を実装しないトランスポート プロトコル ( UDPなど) や、アプリケーション層のセッションが一般的に非常に短命であるトランスポート プロトコル (HTTP など) の場合、セッションは、交換されるデータで定義されたメソッドを使用して、より高レベルのプログラムによって維持されます。たとえば、ブラウザーとリモート ホスト間の HTTP 交換には、一意のセッション ID 、ユーザーの設定や承認レベルに関する情報などの状態を識別するHTTP Cookieが含まれる場合があります。

HTTP/1.0 では、1 つの Web/HTTP セッション中に 1 つのリクエストと応答のみが許可されると考えられていました。プロトコル バージョンHTTP/1.1では、 Common Gateway Interface (CGI)を完成させることでこの点が改善され、Web セッションの維持が容易になり、HTTP Cookieとファイルのアップロードがサポートされました。

ほとんどのクライアント サーバー セッションは、トランスポート層によって維持されます (1 つのセッションにつき 1 つの接続)。ただし、Web/HTTP セッションの各トランザクション フェーズでは、個別の接続が作成されます。フェーズ間でセッションの継続性を維持するには、セッション ID が必要です。セッション ID は、動的 Web ページの <A HREF> または <FORM> リンク内に埋め込まれ、CGI に返されます。その後、CGI はセッション ID を使用して、トランザクション フェーズ間でセッションの継続性を確保します。フェーズごとに 1 つの接続を使用する利点の 1 つは、低帯域幅 (モデム) 接続でも適切に機能することです。

TCP セッションは通常、子プロセスやマルチスレッドを使用してソフトウェアで実装されます。この場合、コンピュータがセッションを確立または参加すると、新しいプロセスまたはスレッドが作成されます。HTTP セッションは通常、セッションごとに 1 つのスレッドを使用して実装されるのではなく、各セッションの状態に関する情報を含むデータベースによって実装されます。複数のプロセスまたはスレッドを使用する利点は、各スレッドが独自の履歴とカプセル化された変数を持つインスタンスであるため、ソフトウェアの複雑さが緩和されることです。欠点は、システム リソースの面でオーバーヘッドが大きく、システムを再起動するとセッションが中断される可能性があることです。

クライアントがサーバー クラスター内の任意のサーバーに接続できる場合、サーバーがセッション状態を維持しなければならないときに一貫性を維持する上で特別な問題が発生します。セッションの期間中、クライアントは同じサーバーに誘導されるか、サーバーが共有ファイル システムまたはデータベースを介してサーバー側のセッション情報を送信する必要があります。そうしないと、クライアントはセッションを開始したサーバーとは別のサーバーに再接続する可能性があり、新しいサーバーが古いサーバーの保存状態にアクセスできない場合に問題が発生します。

サーバー側セッションは便利で効率的ですが、負荷分散/高可用性システムと組み合わせると扱いが難しくなる可能性があり、ストレージのない組み込みシステムではまったく使用できません。負荷分散の問題は、共有ストレージを使用するか、各クライアントとクラスター内の単一のサーバー間の強制ピアリングを適用することで解決できますが、これによりシステム効率と負荷分散が損なわれる可能性があります。

大容量ストレージのないシステムでサーバー側セッションを使用する方法は、セッション データの保存用に RAM の一部を予約することです。この方法は、クライアント数が限られているサーバー (一度に複数のクライアントへのアクセスがまれであったり、許可されていないルーターやアクセス ポイントなど) に適用できます。

クライアント側のセッションでは、サーバー上に大量のデータを保存せずに状態を維持するために、 Cookieと暗号化技術が使用されます。動的な Web ページを表示する場合、サーバーは現在の状態データを Cookie の形式でクライアント (Web ブラウザー) に送信します。クライアントは Cookie をメモリまたはディスクに保存します。クライアントは、次の要求ごとに Cookie をサーバーに送り返し、サーバーはそのデータを使用して、その特定のクライアントのアプリケーションの状態を「記憶」し、適切な応答を生成します。

このメカニズムは、状況によってはうまく機能する可能性がありますが、クライアントに保存されたデータは、ユーザーまたはクライアント コンピューターにアクセスできるソフトウェアによって改ざんされる可能性があります。機密性と整合性が求められるクライアント側セッションを使用するには、次のことが保証される必要があります。

1. 機密性: サーバー以外ではセッション データを解釈できないようにする必要があります。
2. データの整合性: サーバー以外がセッション データを操作してはなりません (誤ってまたは悪意を持って)。
3. 信頼性: サーバー以外では有効なセッションを開始できない必要があります。

これを実現するには、サーバーはセッション データをクライアントに送信する前に暗号化する必要があり、暗号化手段によって他の当事者によるそのような情報の変更を防止する必要があります。

リクエストごとに状態を送受信する方法は、Cookie のサイズが小さい場合にのみ実用的です。本質的には、クライアント側のセッションは、各 Web リクエストに必要な追加の帯域幅と引き換えにサーバーのディスク領域を消費します。さらに、Web ブラウザは、Web サイトが保存できる Cookie の数とサイズを制限します。効率性を高め、より多くのセッション データを可能にするために、サーバーは Cookie を作成する前にデータを圧縮し、後でクライアントから Cookie が返されたときにデータを解凍する場合があります。

セッション トークンは、現在の対話セッションを識別するためにサーバーからクライアントに生成され送信される一意の識別子です。クライアントは通常、トークンをHTTP Cookieとして保存して送信したり、GET または POST クエリのパラメーターとして送信したりします。セッション トークンを使用する理由は、クライアントが処理する必要があるのは識別子だけです。すべてのセッション データは、その識別子にリンクされたサーバー (通常はクライアントが直接アクセスできないデータベース) に保存されます。一部のプログラミング言語が HTTP Cookie に名前を付けるときに使用する名前の例には、JSESSIONID ( JSP )、PHPSESSID ( PHP )、CGISESSID ( CGI )、および ASPSESSIONID ( ASP ) があります。

人間とコンピュータの相互作用において、セッション管理とは、コンピュータ システムとの相互作用のセッション全体にわたってユーザーのアクティビティを追跡するプロセスです。

デスクトップ環境における一般的なセッション管理タスクには、開いているアプリケーションと各アプリケーションが開いたドキュメントを追跡することが含まれます。これにより、ユーザーがログアウトして後でログインしたときに同じ状態を復元できます。Web サイトの場合、セッション管理では、セッションの有効期限が切れた場合 (つまり、ユーザーのアクティビティがないまま一定の時間が経過した場合) にユーザーに再ログインを要求することがあります。また、HTTP 要求間でサーバー側に情報を保存するのにも使用されます。

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

セッション管理は、ユーザーが開いているすべてのページと設定を保存し、後日または別のコンピューターで復元できるWeb ブラウザーで特に役立ちます(データの移植性を参照)。

システムまたはアプリケーションのクラッシュから回復できるように、ページと設定を次回の実行時に復元することもできます。セッション管理をサポートする Web ブラウザの例としては、 Google Chrome、Mozilla Firefox、Internet Explorer、OmniWeb、Operaなどがあります。セッション管理は、多くの場合、 Cookieのアプリケーションを通じて管理されます。

ハイパーテキスト転送プロトコル(HTTP) はステートレスです。セッション管理は、Web 開発者がステートレス HTTP プロトコルでセッション状態をサポートするために使用する手法です。たとえば、ユーザーが Web サーバーに認証されると、そのユーザーの次の HTTP 要求 (GET または POST) では、Web サーバーがユーザーのアカウントとパスワードを再度要求することはありません。これを実現するために使用される方法については、HTTP クッキーとセッション ID を参照してください。

複数の Web サーバーがセッション状態に関する情報を共有しなければならない状況 (クラスター環境では一般的) では、Web サーバー ソフトウェアを実行しているクラスター ノード間でセッション情報を共有する必要があります。クラスター内のノード間でセッション状態を共有する方法には、メンバー ノードへのセッション情報のマルチキャスト (この手法の 1 つの例についてはJGroups を参照)、分散共有メモリまたはメモリ仮想化を使用したパートナー ノードとのセッション情報の共有、ネットワーク ソケットを使用したノード間のセッション情報の共有、分散ファイル システムやグローバル ファイル システムなどの共有ファイル システムへのセッション情報の保存、またはクラスター外のデータベースへのセッション情報の保存などがあります。

セッション情報が、トランザクションの否認防止に必要ではなく、コンプライアンス監査の対象となるデータを含まない一時的で揮発性のあるデータであると考えられる場合 (たとえば、米国では、コンプライアンス監査を必要とする 2 つの法律の例については、医療保険の携行性と責任に関する法律およびサーベンス・オクスリー法を参照してください)、セッション情報を保存する任意の方法を使用できます。ただし、セッション情報が監査コンプライアンスの対象となる場合は、セッションの保存、レプリケーション、およびクラスタリングに使用する方法を考慮する必要があります。

サービス指向アーキテクチャでは、拡張マークアップ言語 ( XML ) メッセージで構築されたSimple Object Access Protocol または SOAPメッセージをコンシューマー アプリケーションが使用して、Web サーバーにセッションを作成させることができます。

HTTP がステートレスなプロトコルであるのと同様、 SMS もステートレスです。1999 年に SMS が競合ネットワーク間で相互運用可能になり、^[2]テキスト メッセージングがユビキタスなグローバル通信形式へと成長し始めると、^[3]さまざまな企業が SMS チャネルを商用目的で使用することに興味を持つようになりました。初期のサービスは片方向通信のみであったため、セッション管理は必要ありませんでした (たとえば、2000 年には、フィンランドで最初のモバイル ニュース サービスが SMS 経由で配信されました)。今日では、これらのアプリケーションは、ピアツーピア(P2P) メッセージングとは区別して、アプリケーション ツー ピア (A2P) メッセージングと呼ばれています。対話型のエンタープライズ アプリケーションの開発にはセッション管理が必要でしたが、SMS は GSM 標準で定義されているステートレス プロトコルであるため、^[4]初期の実装では、エンド ユーザーがコマンドとサービス識別子を手動で入力することで クライアント側で制御されていました。

• 翻訳
• 休む
• セッションID
• セッション化
• セッション固定
• セッションポイズニング

• ダグ・リーによるセッション