ステートフルとステートレス
Cookieとセッションを理解するためには、ステートフルとステートレスを知っておくわかりやすい。 HTTPはシンプルなプロトコルで、ステートレスという特徴がある。
HTTPのステートレスというのは、状態を保持せず、リクエスト/レスポンスの1往復でやりとりが完結する処理とみなされ、複数の処理を関連づける仕組みを持たないことを言う。
一方、ステートフルは次の処理内容に関連づける方式のこと。相手の状態を覚えることになるので、ステートレスに比べてサーバの負担は大きくなる。
概念的なイメージを載せておく。
HTTPはステートレスであるが、ECサイトなどの一連の動作をして購入するようなものがWebに増えてきたため、どうにかしてステートフルにしたいという状況になった。
そこで、HTTPを補完する(状態を保持し管理する)別の仕組みが導入されている。そこに利用されているのがCookie。
Cookieとは
上に書いた通り、HTTPはステートレスなプロトコルであるため、何かしら状態を補完する仕組みが必要になる。その仕組みとしてCookieが利用されている。
Cookieとは、Webサイトの提供者が、Webブラウザを通じて訪問者のコンピュータに一時的にデータを書き込んで保存させる仕組み Cookie 【HTTP Cookie】
Cookieのやりとりは、Webサーバに接続してきたWebブラウザに対して、レスポンスと一緒に保持してほしい情報をCookieとして送信する。Webブラウザでは、そのCookieを保持しておき、次にサーバにリクエストするときには、Cookieも併せて送信する。そうすることで、サーバはCookieを参照することでWebブラウザを識別できるようになる。概念的なイメージは下記のような感じ。
Cookieはメッセージヘッダーに入っている。サーバがCookieを送るときはSet-Cookieヘッダーを、クライアントがCookieを送るときはCookieヘッダーを含めることで、Cookieを送信できる。
ヘッダー名 | 内容 | ヘッダー種別 |
---|---|---|
Set-Cookie | 状態を保持・管理するための情報(Cookie) | レスポンスヘッダーフィールド |
Cookie | サーバから受け取ったCookieの値 | リクエストヘッダーフィールド |
Set-Cookieヘッダーに属性を付与して、Cookieの有効期限というようなオプションを設定できる。 ここでの注意点は、name属性とそこに付与する値は必須という点。下の表の通り、Cookieの名前と値になるので、これが空だとSet-Cookieなのに設定されていない状態になってしまうため必須になっていると思われる。
属性 | 内容 |
---|---|
name=value | Cookieにつける名前とその値 |
expaires=date | Cookieの有効期限。この値がない場合、ブラウザを閉じるとCookieは削除される |
max-age=seconds | Cookieの残存時間を秒数で指定 |
secure | HTTPS通信している場合のみCookieを送信 |
httponly | JavaScriptからのCookieへの参照制限 |
domain=DOMAIN_NAME | Cookieが利用されるドメイン名 |
path=PATH | Cookieが利用されるサーバ上のパス |
上の表の通り、有効期限が指定されていないCookieはブラウザを閉じると削除される。こうしたCookieをセッションCookieと呼ぶ。
一方、有効期限が設定されたCookieはブラウザを閉じても削除されず、有効期限が来るまでブラウザ上に残り続ける。セキュリティの観点から、ECサイトではセッションCookieがよく利用される。
ここまでは、ステートレスなHTTPプロトコルをどうやって、ステートフルにするかの話。次は、ステートフルな通信をどう活かしているってお話。
セッションとは
Cookieを使うことで、HTTPプロトコルでもステートフルな通信ができるようになった。ステートフルになることの旨味は『一連の処理を保持しながら処理できる』という点。この一連の処理のことをセッションというらしい。
セッションの具体的な例をショッピングサイトでの購入の流れで示す。大雑把な流れは下記のように分類できる。
- ログインする
- 商品を選ぶ
- カートに入れる
- カートを確認する
- 購入する
- ログアウトする
この一連の処理をセッションという。Webサーバには複数のWebブラウザからリクエストが来るため、Webブラウザとセッションを関連づけてセッションを管理したい。そんなときに使えるのが、上で学んだCookie。
セッション管理では、Webブラウザを識別するための情報を『セッションID』と呼び、セッションIDはサーバで生成されて、Cookieに含めてブラウザに送信される。Webブラウザでは次回以降のリクエスト時に、受け取ったセッションIDを含めた処理を行うことで、サーバとのセッションを維持したまま通信できる。
概念的には下記のような感じ。下の例だと、セッションIDは簡単なものをつけているけど、Cookieを悪用すればなりすましができてしまうので、推測しにくい値である必要がある。
ちなみに、セッション中に行われる一連の作業の最小単位をトランザクションというらしい。イメージ的には下記。