ついにセッションと Cookie の違いを理解する #HTTP

なぜセッションと Cookie は分かりにくいのか

参考書などを読むと、途中から分からなくなる。

要するに、セッションと Cookie がセットで語られており、混同することでふんわり理解に留まってしまう。
今回は、これらを人に説明できるレベルまで理解してみます。

HTTP は、Web サーバと Web クライアントの間で情報をやりとりするためのプロトコルです。
クライアントは情報をサーバに要求し、サーバは要求に応じて情報をクライアントに返す。

このとき、サーバはどのクライアントからどんな要求があったのかを管理することはない。そのため、HTTP を素直に使うだけだと、カート情報を引き継いだり、ログイン状態を保持したりといった気の利いたことはできない。

これでは困る。ということで、セッションのお出まし。

はじめに重要な事実をお伝えすると、上述でセッションと呼んでいたものは正確には「セッション管理」のことであった。

セッションとセッション管理は区別して整理する必要がある。

セッションとは、クライアントとサーバ間の通信の一連の流れを指す。

これが基本的なセッションの単位である。

繰り返しだが、HTTP を素直に使うだけでは、あるセッションから次のセッションへ情報を引き継ぐことができない。ゆえに、EC サイト等の状態管理が必要なサイトが困ってしまう、というのが課題でした。

上記の課題を解決するために、セッションを管理しようというわけです。

どう管理するのかというと、クライアントに一意のIDを紐付けてやればいい。単純です。
この一意のIDのことをセッションID と呼び、次のように利用します。

サーバは、クライアントからリクエストを受け取った際に、「あ、これセッション管理必要なやつだ」と判断し、レスポンスにセッションID を含めて送る。次のリクエストのときに、クライアントがセッションID も一緒にリクエストに入れて送れば、サーバは「あ、さっきサバ缶をカートにいれたヤツや」となる。

そして、このセッションID の管理方法の1つが Cookie なのだ。

Cookie は、セッションID を管理する方法の1つである。
ということは、方法は他にもあるのだが、Cookie が最もメジャーな方法だ。

Cookie によるセッション管理の流れはこう。

上述のセッション管理の流れとほぼ同じことを繰り返していることにお気付きだと思う。

要は、セッションを管理するための取り決めを、サーバとクライアントで用意しておく必要があり、その取り決めとして Cookie がありますよ、というだけのこと。

余談だが、Cookie 以外のセッション管理方法として、URL Rewriting と hiddenフィールドというのがある。
詳細は割愛するが、セキュリティや実装のシンプルさの観点から Cookie が主流となっている。

「セッションと Cookie の違い」という見出しが的を射ていないことがここまで調べて分かった。

セッションとは、HTTP による通信の一連の流れのことだった。
そして、状態によってカスタマイズしたページを送りたいという要望に応えるため、セッションを管理する必要が生じ、この方式の1つとして Cookie が存在している。

つまり、セッションと Cookie はそれぞれ独立した存在ではなく「セッションの拡張方式として Cookie が用意された」というのが正しそうだ。

ちなみに、学習本でセッションと呼ばれているものは、正確には「セッション管理をしてくれる機能・メソッド」のことなのだと分かった。