IT

Cookieとセッションについてわかりやすく解説します!

こんにちは!ウマロです。

最近、WEBアプリケーションの仕組みについて勉強していまして、それ関係の書籍やサイトを漁っているのですが、今回は「Cookie(クッキー)」「セッション」について、個人的に理解が詰まってしまったので、備忘の意味を込めてわかりやすく解説したいと思います。

トピックとしては以下のようになります。

本記事のトピック
  • Cookieとセッションの必要性
  • Cookieとは
  • Cookieの問題点
  • セッションとは

Cookieとセッションについて、イマイチよく分からないという方にとって参考になれば幸いです。

そもそもなぜCookieとか、セッションが必要なのか

大前提として、私たちが普段使っているインターネットは、HTTP通信と呼ばれるルールの元成り立っています。

HTTP通信の流れは、以下の図のように、クライアントからのリクエストをサーバ側が受け取り、それに対応したレスポンスを返すというものです。

イメージとしては、あなたが「Amazonのホームページを見たい」というリクエストを送ったとします。

リクエストを受けとったWebサーバ側では、対応するAmazonのホームページ画面を探し出し、あなたの元へホームページ画面を表示させるレスポンスを送るといった具合です。

ここで重要なのは、HTTPでは1回のリクエストだけで用が済んでしまうので「状態」が存在しません。

つまり、サーバ側はこの通信が前のページからの続きなのか、関連したアクセスなのか、以前の状態を全く覚えていません。

HTTP通信は状態を持たないプロトコル「Stateless Protocol(ステートレス・プロトコル)」と呼ばれています。

なぜこのようになっているのかと言うと、HTTPが考案された当時は、HTTPを使ってWebアプリケーションを実現することを技術者たちが考えていなかったからです。

しかし、AmazonなどのECサイトで商品を購入する場合、以前の状態を覚えていないとどうなるでしょうか?

ネットショッピングの流れは、基本的に以下ですね。

まずサイトにログインして、欲しい商品を探してカートに入れます。

そのあと、支払うことで注文が完了します。

しかし、実はこの時サーバは、誰が商品をカートに入れたのか、誰が購入したのか覚えていないんです。

これだと、非常にマズイですよね。

注文したはずの商品が、自分の元に届かないと言うことが起きてしまいそうです。

そこで考えられたのが、今回解説する「Cookie(クッキー)」「セッション」という技術です。



Cookieとは

CookieはHTTPの仕様を拡張してWebアプリケーションとWebブラウザの間で情報を交換できるようにしたものです。

その情報は、WebサーバからWebブラウザへHTTPレスポンスのヘッダを利用して情報を送ります。この情報は「名前 = 値」の組み合わせで表され、この情報のことをCookieと呼びます。

簡潔に言うと、CookieはWebブラウザ(クライアント)に保存された情報とも言えます。

WebサーバからCookieを受け取ったWebブラウザは、次回同じWebサーバにアクセスする際、受け取ったCookieをそのままHTTPリクエスト・ヘッダに入れて送ります。

一方、Webアプリケーション側では、リクエスト・ヘッダに入っているCookieを調べることで、アクセスしてきた相手がどのような相手なのかを知るとが出来るわけですね。

Cookieにどのような情報を含めるのかはアプリケーションが自由に決めることができます。(名前やパスワードなど)

こうしてWebサーバから送られたCookieは、ブラウザが読み取ってクライアントのPC上に保管されます。次に同じWebサーバへアクセスする際に、リクエスト・ヘッダを利用してCookieが送信されます。

このように、Cookie情報をもとにクライアント側(Webブラウザ)の状態を保ことができます。

Cookie情報の保存数、情報内容には以下の制限があります。

  • 1つのドメイン(Webサーバ)に対して20個までCookieの保存が可能。
  • 1つのCookieは名前と値を合わせて4Kバイトまで設定可能。
  • クライアントが保存できるCookieの数は全体で300まで。

Cookieの問題点

Cookieを用いることでWebブラウザに状態を持たせることができるようになり、これで問題は解決したかに思えます。

しかし、実はCookieにはセキュリティ上のクリティカルな問題が残っているんです。

Cookieを利用した情報のやり取りは、HTTPリクエストのリクエスト・ヘッダやレスポンス・ヘッダを利用して行われます。

この情報は特定のツールを用いることで、知識のある人ならば、簡単に覗くことができてしまうのです!

特にユーザ名やパスワード、クレジットカードの番号といった情報を第三者に盗まれてしまうと、本人になりすまして勝手にクレジットカードを利用されたり、銀行口座から勝手に振り込みをされたりといった被害が起きてしまう可能性があります。

そこで、より安全により多くの情報を保持するための方法として、考案されたのが「セッション(Session)」と呼ばれる仕組みです。



セッションとは

セッションを利用した情報の保持の仕組みとは、どのようなものなのでしょうか?

ここでは、「銀行に口座を開設するための一連の手続き」を例に解説したいと思います。

まず、Aさんが新しい口座を開設するために銀行の窓口に向かうところからスタートです。

大抵はこんな感じで順番待ちになると思います。

口座開設は受付の後ろに控える業務担当者によって手続きされます。

その間に受付担当は次の受付番号を持つお客の対応を行います。

そのうちに、Aさんの口座開設の手続きが完了します。

再び「受付番号326番でお待ちのお客様〜」と呼ばれ、Aさんは新しい通帳を受け取ることができます。

ここまでの流れを整理してみましょう。

  1. 口座開設手続き受付
  2. 口座開設手続き中
  3. 口座開設手続き完了

この①〜③までの一連の流れのことを「セッション」と呼びます。

銀行の窓口はリクエストを受け取るWebサーバ、窓口に訪れるお客はWebクライアントに当てはまりますね。

そして、銀行の場合は窓口とお客の間で紙の書類によって情報をやり取りしますが、Webアプリケーションの場合はHTTPで通信します。

また、先ほどの受付番号に該当するものがセッションでいう「セッションID」となります。

セッションIDは、銀行で発行される受付番号のように、番号自体に特別な意味はなく、Webサーバにリクエストを発行したWebクライアントを識別できれば良いのです。

一連の流れの状態を管理する方法として、以下のような管理表の概念があります。

セッションIDさえ分かれば、それに付随する色々な情報も分かるということがご理解いただけるでしょうか?

セッションIDはただの数字(または文字列)なので、Cookieを利用してやりとりされます。

Webアプリケーションでのログインのように、セッションを開始する時にはWebサーバ側が新しいセッションIDを発行します。発行したセッションIDは、HTTPレスポンスのCookieへ格納してWebブラウザ(クライアント側)へ渡します。

それ以降のリクエストのときは、Webブラウザ(クライアント)はセッションIDを格納したCookieをWebサーバへ送ります。

そして、Cookieを受け取ったWebサーバは、その情報に含まれる「セッションID」を元にしてメモリ上に残っているクライアントの状態を復元します。

Cookieを利用して情報をやり取りしているのは変わらないのですが、以下の点が大きく異なっています。

Cookieの中に情報そのものを格納するのか、セッションIDだけを格納するのか。

CookieにセッションIDだけ保存しておけば、セッションIDはただの数字(または文字列)なので盗まれても何の問題もない。

セッションIDを元に状態を復元するためのメモリは、Webサーバ上にあるから安全性も高い。

Cookieに格納できる情報量の制限を気にしなくて良い。



まとめ

今回は、Webアプリケーションにとって重要な要素である「Cookie」と「セッション」について解説しました。

もし、あなたがWebアプリケーションを開発する場合、今回解説した内容を理解しているかしていないかで開発過程もスムーズさが変わってくるでしょう。

ぜひ、ご自分でも学習を続けてみてくださいね。

それでは、今回はここまで!

ではでは〜♪( ´▽`)