オプト管理の記事でも出てきたCookie。
「Cookieのようなオンライン識別子」と書きましたが、そもそも、Cookieはどのように使ったら、「オンライン識別子」になるのでしょうか。
これを説明するために登場するのがSessionという考え方です。
CookieとSessionについては、Google先生に聞いてみれば、すでにたくさんの記事が公開されていますが、私も”今更ながら”ですが、初心に返ってCookieとSessionについてまとめてみようと思いました。
しかし、単にこの二つを語ってもエンジニアっぽい話にならないので、ここに「http通信」の話を混ぜ込んでみたいと思います。Webアプリを開発するとCookie、Sessionが付いて回るのはhttp通信の性質が関係しているからです。
というより、http通信であれやこれやしようとし始めたから、CookieとSessionの話が話題になった気もします。
１） httpは”ステートレス”
http通信の特徴の説明でよく出るのは「ステートレス」。
ステートとは”状態”という意味を持っています。レスは”ない”。つまり”状態を持っていない”ということです。http通信で言う”状態”はブラウザ（クライアント）とWebサーバー（サーバー）の間のやりとり（リクエスト）の状態を示しています。
httpはクライアントとサーバー間のやりとり（リクエスト）がどのような内容だったかを持たず、毎回、「初めまして！」とスタートするということです。
ブラウザでインターネットへアクセスした時は、色々なページのリンクを辿って閲覧を続けると思います。その1回毎に「初めまして！」情報をもらっているのです。
イメージとしては、各部屋の出入りがチェックされている社内を移動する感じに似ている気がします。うっかり「忘れ物した！」と扉が閉まった直後に思い出しても、再び最初チェックを受けて部屋へ入る必要があります。「今、出てきたばかりなのですが。。。」が通用しません。
２）Sessionは論理的な”通信の初めから終わりまで”
毎度「初めまして！」でスタートすると困る時があります。例えばどんなページがどういう経路でアクセスされているかとアクセス分析をしたい時やECでの買い物をしている時などです。
例えば、ECで買い物をして支払いをする場合に、事前のやり取りを記憶されていない場合は、決済に至るすべてのページで「これが買いたい、この支払い方法で、この住所で！」と訴える必要がでてきます。
これを解決するためにSessionという考えを適用します。
Sessionは論理的な通信の流れと書きましたが、http通信だけでは状態を保管できません。そこで登場するのがCookieです。
論理的な通信の流れをCookie内のデータとサーバー上のセッション管理用データを照合することで確認しています。
3）Cookieはhttpヘッダーとして送り込まれる
Cookieはクライアント上では小さなファイルとして保管されていますが、通信が始まった時はhttpヘッダーに含まれて送信されます。
毎度、ユーザーがボタンをクリックしてファイルアップして、なんてことはありません。
通信上の条件が合えば自動で送られ、いつも気にしなくてよいのです。
記事の初めの例（社内移動）を用いるなら、首からさげている社員証というところでしょうか。各部屋の出入り口が首から下げている社員証を自動で読み取って、「〇〇さんが入室」と記録しているようなものです。入室しているほうがあれやこれや言わなくて済み、スムーズな移動が可能になります。
駆け足でCookieとSessionについて、基本概念をまとめてみました。
もっと細かく書くと、プログラムではどうやってセッション管理を始めるか、セッション管理のサーバー上のデータはどう管理するか等もありますが、またの機会に。
また、この基本概念をもとに「オプト管理」も再確認していただくと、「オプト管理」の必要性が明確になるかと思います。