【図解】コネクションとセッションの違いと具体例 ~TCPやHTTP,TLS,PPPoEでの定義~ | SEの道標
ネットワークエンジニアとして知っておくべきこと

【図解】コネクションとセッションの違いと具体例 ~TCPやHTTP,TLS,PPPoEでの定義~

コネクションとは セッションとは

ネットワーク用語で紛らわしい言葉としてコネクションセッションがあります。この 2 つの言葉の違いを解説します。

まず、コネクションとセッションという単体の言葉だけでは違いを一般的に説明することはできません。各プロトコルで、独自の定義されていたり慣用的に使われていたりしますし、ファイアウォールのような特殊な機器でも独自の定義があったりします。

ここではネットワークでよく遣われる範囲で具体例を紹介していきます。

TCP の場合

TCP では『コネクション』が定義されています。たまに『TCP セッション』と言うのを聞きますが、厳密には『TCP セッション』という概念はありません。

TCP コネクションはホスト間の論理回線の確立を意味し、TCP 3way Handshake から TCP Fin、もしくは TCP Reset までが 1 コネクションです。

TCP コネクションはホスト同士 (一般にはクライアントとサーバ間) で確立するため、間に存在する L3 ネットワーク機器は基本は関与せず、OSPF 等で経路が切り変わってもコネクションは切れません。(ただし、後述するファイアウォール等を通過する場合には注意が必要。)

PPP, PPPoE の場合

PPP や PPPoE では『セッション』が定義されています。コネクションは存在しません。

この場合のセッションは TCP コネクションと似ていて『論理回線』を意味します。

例えば NTT のフレッツ回線サービスでは基本サービスで 2 セッションまで確立できます。

『セッションプラス』という有償オプションサービスを追加すれば、3 つ以上の PPPoE セッションを確立することができます。

TLS (https等) の場合

TLS にはコネクションとセッションの両方があります

TLS コネクションの寿命は TCP コネクションの寿命とほぼイコールとなることが多いです (STARTTLS の場合は例外)。

一般的には TCP 3way Handshake の直後に TLS ネゴシエーションが始まり、ネゴの完了を示す TLS Finished から TLS コネクションが始まります。

また、TLS コネクションの終了は通常は TLS Alert で終わり、その後に TCP Fin や Reset で TCP コネクションも終わります。(いきなり TCP Reset で TLS も強制終了することもあります。)

一方、TLS セッションは TLS コネクションよりも長いです。TLS セッションは通信で使う共通鍵の利用期間を示します。セッションがタイムアウトするまでは、新たな TLS コネクションであっても利用される共通鍵(セッションキー)は同じです。

HTTP の場合

HTTP は本来はコネクションもセッションもありません。ただし、慣例的に、クッキーによるセッションが HTTP セッションと呼ばれたりします

HTTP は規格としては『ステートレス』であり、クライアントがあるリクエストを行った場合、常に同じレスポンスが返されます。

この理屈だと、例えば楽天サイトの購入ページではログイン前とログイン後で同じ画面を返すはずです。

ですが実際にはそうなりません。ログインしてなければログインを促す画面が返されたりします

このような挙動を実現しているのがクッキーです

認証後には Web サーバからクッキー (文字列データ) が払い出されます。クライアントは次回以降はそのクッキーを提示し、Web サーバはそれを見てログインしているか否か、ログインしているならどのユーザか、を判断します。

クッキーには期限が定められており、具体的な時間であったり、ブラウザが閉じられるまでだったりします。

クロスサイトスクリプティング等の攻撃により、セッションクッキーの文字列がばれることがあり、これによりセッションを乗っ取られることがあります。

これをセッションハイジャックと言います。

なお、クッキーは規格としては定義されてはおりませんが、慣例的に広く使われており、Apache や nginx 等の一般的な Web サーバでも実装可能です。

ファイアウォール (UTM) の場合

ファイアウォールでは TCP コネクションUDP / ICMP の往復の通信 (Ping や DNS のクエリ/レスポンスや NTP の往復通信等) を併せて『セッション』として定義しています

おそらく『TCP セッション』という言葉が誤用されるのは、このファイアウォール独自の数え方とごっちゃになっているからでしょう。

ファイアウォールでは通信をセッション単位で管理しており、各プロトコルでの正しいシーケンス (DNS クエリの後には DNS レスポンスが戻ってくる、等) を理解しており、正しくないシーケンスになるとパケットをドロップします。この機能をステートフル・インスペクションと言います。

ステートフル・インスペクションの詳細については以下ページをご参照下さい。

【図解】ステートフル・インスペクションの仕組み〜TCP/UDPの状態を監視するファイアウォール機能〜
ステートフル・インスペクションとは ステートフル・インスペクション (State...

また、セッションが不正に奪われないよう、セッション開始から一定時間が経過すると強制的にセッションを終了させます。この機能をセッション・タイムアウトと言います。

セッション管理にはハードウェアリソースを消費するため、機器スペックによってセッション数の上限があったりします。

まとめ

このように、単に『コネクション』とか『セッション』と言うだけではそれが何を意味するか不明確です。

例えばクライアントとサーバ間で HTTP 通信をしていて、ファイアウォールを経由する構成において、『セッションがクリアされた』と言われても、HTTP のセッションクッキーがクリアされたのかファイアウォールの管理するセッションがクリアされたのか分かりません

必ず何のセッションのことか確認しましょう。(実は TCP コネクションのことを言ってた、なんてこともよくある話。)

コメント

タイトルとURLをコピーしました