##前提知識（HTTPプロトコルについて）
###HTTPプロトコルとは
HTTPで通信するルールのこと。
HTTPプロトコルは状態を持たない。
つまり、HTTPプロトコルではリクエストを送り、レスポンスを受け取った時点で、その通信は終了してしまいます。
これでは分かりにくいので、具体例を挙げると、
Googleで「犬 可愛い」と検索をする。
そしてもう一度、Googleで、「犬 可愛い」と検索をする。
この2回はリクエストとレスポンスが全く同じことをしていますが、
別の通信だと認識されてしまいます。
これが、HTTPプロトコルは状態を持たないことを意味しています。
(ステートレスプロトコルと言います）
###アプリケーションでの具体例
上記のことの問題点として、アプリケーションの機能を例に挙げて説明します。
例えば、ログイン画面でログイン後、次のページへ遷移するとユーザー情報を
引き継げないなどの問題が挙げられます。
これらを解決するのがクッキーとセッションです。
#Cookie（クッキー）
クッキーとは、HTTPヘッダーに格納できるテキストデータのことです。
WebサーバーからWebブラウザへHTTPレスポンスのヘッダを利用して情報を送ります。
この情報は「名前＝値」の組み合わせで表されます。
そして、このデータはクライアントのブラウザに保存されます。
（より視覚的にクッキーの状態などを確認する方法としてInetSpyなどのサービスもありますので、興味のある方は調べてみてください）
このcookieを利用すればブラウザに値が格納されているため、
先ほどのログイン問題でも発生したHTTPプロトコルの値を保持できないという問題は解決できます。
しかし、別の問題が発生します。
###セキュリティ上の問題
クッキーにはセキュリティ上の問題があるのです。
なぜなら、クッキーはクライアント側に値を保存するからです。
クライアント側にあるということはクライアント側で変更が可能ということもあり、
少し知識のある人なら誰でも簡単見ることができます。
例えば先ほど紹介したInetSpyなど
そこでようやく、登場するのがセッションです。
#Session（セッション）
クライアントとサーバーの通信状態をセッションといいます。
セッションにはIDを割り振って管理します。
保持されたセッションが欲しいときはIDを指定して取り出せます！
クッキーと違って、セッションを使用すれば、値はサーバー側に保存されてるためクライアント側からは操作できません。
では、どうやってセッションIDをサーバーに送るかというと、
クッキーに、このセッションIDを格納します。
そうすることで、クッキーの問題点であった中身を見られても問題ありません。
なぜなら、セッションIDを見たとしても、関連している中身はサーバーにあるためデータを改ざんすることはできないからです。
#まとめ
###cookie
保存場所：クライアント側
安全性：データ改ざんの可能性が高い
###session
保存場所：サーバー側
安全性：データ改ざんの可能性は低い
取り出すにはセッションID をサーバーに送信する必要あり
セッションIDにクッキーを格納してデータ送信を安全に実現する