最初に結論
ザックリ以下のように違います。
- Cookie：
→サーバーから「お前これ持っとけ」と渡されるデータのこと。
Cookieを持たされた人は、そのサイトにアクセスするときに毎回Cookieを持参しないといけない”呪い”にかけられる。
- セッション：
→サーバーが持っている「さっきアクセスしてきた奴リスト」のこと。
または「そのリスト」と「アクセスしてきたヤツが持っているCookie」を照らし合わせて「こいつはさっきアクセスしてきたやつだな！？」と特定する一連の流れのこと。
超わかりやすく
セッションとCookieの違いについて解説した記事は、ネット上にたくさんあるので
この記事ではIT素人にでもわかるように噛み砕いて書きたいと思います。
噛み砕く上で、例え話をします。
・
・
・
とある学校に、A先生👩がいました。
A先生👩はある日、通りすがりの魔女🧙♀️によって「生徒の『顔』と『名前』が覚えられなくなる呪い」をかけられてしまいました😣
A先生👩は困りました。
顔と名前が分からないと、生徒🧒とロクに接することもできないからです。
困り果てたA先生👩でしたが、以下のようにして問題を解決することにしました！😀
- 自分に話しかけてきた生徒に「あなたの名前は何ですか？」と最初に尋ねる
- その生徒の
名札📛を作り「自分と接するときは常にこの名札をつけてね！」とお願いする - その生徒の名前を
自分が話したことある生徒名簿📖に加える - その生徒のことで「なにか覚えておかなければならない事」ができたなら
その生徒専用のノート📖を作り、「この生徒とこういうことを話した」と書いておく
▲生徒Aと生徒Bのことは覚えた！
こうすることで、生徒🧒に話かけられたとしても
- その生徒に
名札📛が付いているか見る - もし
名札📛が付いていれば、自分が話したことある生徒名簿📖にその名前があるか見る - もし
自分が話したことある生徒名簿📖に名前があれば、「ああ、この生徒ね」と判別できる - さらに
その生徒専用のノート📖があればその内容も確認する
という風にして、自分が受け持つ生徒を見分けることができます！🤗
▲生徒Cのことは知らない！
もし名札📛が付いていなかった場合は、自分が話したことがない生徒だし、もし名札📛札が付いていたとしても自分が話したことある生徒名簿📖に名前がなければ、自分を騙そうとしている悪い生徒だと見抜けます。
ただし、この方法には少し問題があります。
例えば、生徒が名札📛をつけ忘れたり無くしてしまったりすると、その生徒はA先生👩と話したことがあるにも関わらずそのことを思い出せません。
また、A先生👩がその生徒専用のノート📖や自分が話したことある生徒名簿📖を紛失してしまった場合にも、A先生👩は生徒のことを思い出せなくなってしまいます･･･。
・
・
・
さて、このへんで現実世界に話を戻してみましょう。
この話に出てきた登場人物は、それぞれ以下のように対応しています。
A先生👩→ サーバー生徒🧒→ アクセスしてくるユーザー名札📛→ Cookie自分が話したことある生徒名簿📖→ セッションその生徒専用のノート📖→ データベース
なんとなく分かりましたでしょうか？
ポイントは、それぞれ持ち主が違うという点です。
名札📛の持ち主
→生徒🧒
自分が話したことある生徒名簿📖の持ち主
→A先生👩
その生徒専用のノート📖の持ち主
→A先生👩
さらにもう1つ重要なのは、名札を作るのはA先生という点です。
名札📛を作る人
→A先生👩
これらを踏まえて、
ここからは実際のセッション、Cookieの話をしていきます。
例えば、Xさんがhttp://yahoo.co.jpにアクセスして、yahooアカウントにログインするとします。
このとき、yahooのサーバーは「ほらよ！」とページを返すのと同時に以下のような事もします。
- 「Xさんと識別するための識別ID」のCookieを返す
- 「yahoo会員リスト」の「Xさん」の欄に「Xさんと識別するための識別ID」を書き込む
- 「Xさん専用のノート」を作り、Xさんに関することを書き込んでいく
これによって、Xさんはyahooにアクセスするときは必ずそのCookieを付けてアクセスすることになります。
そして、アクセスされたyahooサーバーは、そのCookieに書いてある識別IDが「yahoo会員リスト」の中に存在するか確認して、もし存在すれば「あなたはXさんだね！」と認証して、「Xさん専用のノート」を使ってXさんの情報を表示する･･･
のような流れになります。
また、さきほどの例え話と同じように、
もしXさんがCookieを破棄した場合は、yahooサーバーはXさんのことを思い出せませんし、yahooサーバーが持っている「yahoo会員リスト」の中の「Xさんと識別するための識別ID」を削除してしまった場合も同様にXさんのことを思い出せません。
ちなみにCookieは、Xさんが自ら「Cookieを勝手に送るな！」と拒否したり「自分が持ってるCookieを全部破棄するぅううう」と破棄しない限り、有効期限が来るまで永遠と保持し続ける”呪い”のようなものです。
つまり、私達は何も知らないままCookieを持たされ、何も知らないままCookieをサーバーに”勝手に”送信させられているのです･･･😱
こういうこともあって、EUでは「Cookieってプライバシーを侵害してるのでは？」と問題視されていて「Cookieを付けるなら事前に許可を取れ！」という流れになっています。（参考）
実際、大手のブログサービス（アメブロやFC2など）では、サイト下部に「Cookie送信しても大丈夫？」みたいな表示が出ることが多くなってきてますよね。あれは大手のブログサービスだとEUからアクセスしてくる人も大勢いるので、きちんと表記しているんだと思われます。
▲Cookieの確認画面
そんな感じです🙇
専門的な話
ステートレス
少し専門用語を使うと、HTTP通信はステートレスと言って、1つの通信が終わるたびに記憶が消去されます。
いや、この表現は間違ってますね。そもそも「記憶するための仕組みがない」と言ったほうが正しいです。
なので、HTTP通信ではCookieやセッションと言った仕組みを使って「ああ、この前アクセスしてきた人ね！」を実現しているのです🤗
セッションID
さきほどの説明でした「Xさんと識別するための識別ID」は、専門用語を使うと「セッションID」と呼びます。
このセッションIDは
- サーバーの「セッションIDを書き込む専用のファイル」
- サーバーのメモリ上
- サーバーのデータベース
のいずれかに書き込むのが一般的らしいです。
もちろん、Xさんに渡されるCookieにも、このセッションIDが書き込まれています。
Cookieを渡す方法
「Cookieを渡すのはサーバーだよ」という話をしましたが、厳密にいうとCookieを渡す方法には
- サーバーが直接Cookieを渡す
- サーバーが渡したHTMLファイルの中のJavaScriptコードがCookieを渡す
の2種類があります。
前者は、サーバーが「これ持っとけ！」と直接渡す方法ですが
後者は、サーバーが「これあげる！」とプレゼントしたHTMLファイルを開けると、ドッキリ箱の要領でJavaScriptが発動して、JavaScriptから「これ持っとけ！」と渡されます。
つまり、Cookieを渡す人がそれぞれ以下のように違います。
- 前者の方法
→サーバー
- 後者の方法
→JavaScript
基本的に前者を使えばいいですが
「ユーザーが何か操作した結果、Cookieが渡されるようにしたい！」という場合は後者を使います。
前者の方法は、サーバーからの返信であるHTTPレスポンスと呼ばれるデータの中のHTTPヘッダーと呼ばれる部分に「このCookieを持ってろ！」という命令を書き込むイメージです。例えば、PHPだとsetcookieという関数を使えば実装できます。
後者の方法だと、JavaScriptのDocument.cookieメソッドを使えば実装できます。
Cookieの有効期限
Cookieの有効期限は、開発者が何も設定しない場合は「ブラウザが閉じられるまで」です。
ちなみに「ブラウザが閉じられるまで有効なCookie」のことをセッションクッキーと読んだりします。
Cookieはドメイン単位
基本的にCookieはドメイン単位です。他のドメインで渡されたCookieは読み取れません。
例えば、
- google.comで渡されたCookieはgoogle.comだけが読み取れます。
- yahoo.comで渡されたCookieはyahoo.comだけが読み取れます。
- yahoo.comはgoogle.comのCookieは読み取れません。
- google.comはyahoo.comのCookieは読み取れません。
という感じです。
おわり
※このページは分かりやすさ重視のために、すごくザックリした内容になっていますので、詳しくは他のページでお調べになってください。
コメント