「セッション」と「クッキー(Cookie)」の関係を整理してみる

「セッション」と「クッキー」の意味を理解して使いたい！

セッションとクッキーの関係がいまいちよく分からない。
そう思っている方は自分だけではないと思い、本記事を執筆しました。

本記事ではまず「セッション」と「クッキー」の言葉の意味を整理し、具体例を見ながら理解を深めます。後半ではZennを利用してブラウザ上で「セッション」と「クッキー」の挙動を検証ツールを用いて確認してみます。

そもそも「セッション」と「クッキー」がなぜ必要か

セッションとクッキーを理解するためには、少しだけその前提となるwebシステムの構造を把握する必要があります。

現代のwebシステムはサーバ・クライアント間の通信にHTTPを利用しています。
このHTTP通信は、個々のリクエスト/レスポンスの関連を認識することができません。
つまり、サーバ側は、前回のリクエスト/レスポンスの内容を覚えていないのです。
これによりどのような問題が起こるでしょうか。

例えば、ショッピングサイトで、カートに商品を入れた後、次のページに遷移した瞬間にカートの中身が消えてしまいます。
何故なら、サーバ側は前回のリクエストを覚えていないからです。
このようなHTTP通信の特徴を ステートレス（Stateless） といいます。

ステートレスなプロトコルでは、 複数のリクエスト/レスポンスにまたがって状態（ステート）を維持する一連のやり取り（これをセッションといいます） を識別できないのです。

では、ステートレスなHTTP通信で、どのようにカートの中身を覚えることができるのでしょうか。
これを実現するのが 「クッキー(Cookie)」という仕組み です。

ここまでのまとめ

• HTTPはステートレスな通信プロトコルであり、複数のリクエスト/レスポンスにまたがって状態（ステート）を維持する一連のやり取りを識別できない
• 「セッション」：複数のリクエスト/レスポンスにまたがって状態（ステート）を維持する一連のやり取り
• 「クッキー」：セッションを実現するための仕組み

クッキーの仕組み

セッションを実現するために必要な情報をサーバが生成し、それをクライアントと共有することで、その情報を共有している間は関連のある一連の通信であるとみなせます。
このサーバからクライアントへ渡され、ブラウザに保存されるデータを格納する仕組みがクッキーです。

どのような情報をクッキーに格納すれば、セッションを実現できるでしょうか？
関連させたい一連の通信は、ほとんどの場合はクライアント側でユーザがログインからログアウトまでに実施した通信です。そのため、ログイン時にサーバ側でユーザ情報と紐づけた固有のセッションIDを生成し、これをクッキーに格納してクライアントに渡すと都合が良さそうです。

生成したセッションIDは、HTTPレスポンスにおいて、 Set-Cookie というヘッダーに格納されます。また、これは「セッションID = 12345」のようなKey-Value形式で保存されます。
クッキーが付与されたレスポンスをクライアント側が受け取り、Webブラウザの機能により保持されます。これでクライアント・サーバ間でセッションを実現する準備が整いました。

そして、クライアントが再度サーバへリクエストを送信する際、送信先のサーバのクッキーを保持している場合は、Cookieというヘッダーにその内容を入れて送信します。

サーバ側はクッキー内のセッションIDに紐づいたユーザ情報を取得することで、そのユーザが操作する一連の通信を識別できるようになります。

ここまでのまとめ

• サーバ側でセッションIDを生成し、Set-Cookieというヘッダーに格納してレスポンスをクライアントへ返す
• クライアント側ではWebブラウザがクッキーを保持する
• サーバへのリクエスト時にそのサーバのクッキーを保持している場合、Cookieにクッキーを格納してリクエストをする
• サーバ側はクッキー内のセッションIDに紐づいたユーザ情報を取得することでセッションを維持する

クッキーを確認してみる

実際にサーバ側でクッキーが発行され、クライアント側のブラウザがそれを保持してセッションを実現している流れを見てみましょう。
今回は、Zennのwebサイトを検証ツールを用いて調べてみます。

1. ログイン前

• ログイン前のZennの画面で検証ツールのNetworkタブを開きます。
• レスポンスヘッダーにアプリケーション固有のセッション管理のためのクッキーはまだ存在していません（Google Analytics関連のクッキーはあります）
  
  ログイン前のNetworkタブ

2. ログイン後

• Zennにログイン後の画面で検証ツールのNetworkタブを開きます。
• レスポンスヘッダーのSet-Cookieに、セッションIDが付与されていることが分かります。
  
  ログイン後のNetworkタブ

3. ログイン後に他ページへ遷移

• ログイン後に他ページへ遷移してもクッキーが保持され、セッションが継続することが確認できます。
  
  ログイン後に他ページへ遷移した場合

4. 検証ツールのApplicationタブ>Storageでもクッキーを確認

• Storageではブラウザが保持しているクッキーを一覧で確認できます。
  
  Storageのクッキー

5. Applicationタブ>Storageでクッキーを削除した後の挙動を確認

• Storageでクッキーを削除後、画面をリロードすると、ログアウトされた画面に遷移します。
• クッキーが無くなったため、サーバ側はユーザを認識できず、セッションが終了してしまいます。
  
  クッキーを削除後にリロードした場合

まとめ

整理してみると、意外とシンプルな仕組みでセッションが実現されていることが分かります。
セッションに関連した課題は実務でも頻繁に遭遇するため、参考にしていただければ幸いです。

参考文献

• 改訂新版 プロになるためのWeb技術入門 小森 裕介 (著)