セッション (コンピュータ)
フォーマルなセッション層を実装しない場合 (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コネクションの利点として、低帯域 (モデム) 接続でもうまく機能する点が挙げられる。
クラスタのノード間でセッション状態を共有する方法には、マスタノードへのセッション情報のマルチキャスト (このテクニックの一例についてはJGroups(英語版)を参照のこと)、分散共有メモリまたはメモリ仮想化(英語版)を用いたパートナーノードとのセッション情報の共有、ネットワークソケットを用いたノード間でのセッション情報の共有、分散ファイルシステムまたはグローバルファイルシステム等の共有ファイルシステム上へのセッション情報の保存、またはセッション情報のクラスタ外のデータベースへの保存、等がある。
トランザクションの否認不可性に必要ではなく、かつ遵法監査の対象 (遵法監査を要する次の2つの米国の法律の例については、w:Health Insurance Portability and Accountability Actとw:Sarbanes-Oxley Actを参照) となっていない、トランジェントな揮発性データだと見なされるセッション情報には、どのような保存方法も使用できる。しかし、セッション情報が遵法監査の対象となる場合、セッションの保存、レプリケーション、そしてクラスタリングに使用する方法を慎重に検討すべきである。
サービス指向アーキテクチャでは、XMLメッセージで構築されたSOAPメッセージをコンシューマアプリケーションで使用してウェブサーバにセッションを作成させることができる。