-
Notifications
You must be signed in to change notification settings - Fork 0
セッションが必要な理由
Toshiki edited this page Dec 20, 2023
·
1 revision
セッションが必要な理由を知るためには、HTTPはステートレスであることついて理解しておく必要があります。
ステートフルは状態を保持する、ステートレスは状態を保持しないという意味です。
では、ファーストフード店を例にして、ステートフルとステートレスについて考えてみます。
- 客 : 「ハンバーガーセットをお願いします」
- 店員 : 「サイドメニューは何にしますか？」
- 客 : 「ポテトで」
- 店員 : 「ドリンクはどうしますか？」
- 客 : 「コーラで」
- 店員 : 「サイズはどうしますか？」
- 客 : 「Lサイズで」
- 店員 : 「以上でよろしいですか？」
- 客 : 「はい。お願いします。」
- 店員 : 「かしこまりました。」
- 客 : 「ハンバーガーセットをお願いします」
- 店員 : 「サイドメニューは何にしますか？」
- 客 : 「ハンバーガーセットをポテトでお願いします」
- 店員 : 「ドリンクはどうしますか？」
- 客 : 「ハンバーガーセットをポテトとコーラでお願いします」
- 店員 : 「サイズはどうしますか？」
- 客 : 「ハンバーガーセットをポテトとコーラのLサイズでお願いします」
- 店員 : 「以上でよろしいですか？」
- 客 : 「ハンバーガーセットをポテトとコーラのLサイズ、以上でお願いします。」
- 店員 : 「かしこまりました。」
ステートフルでは、前提を繰り返す必要がありませんでした。
これは、店員が客の注文を覚えていた（状態を保持できていた）からです。
飲食店であればステートフルの方が便利ですが、Webサーバでは違います。
なぜなら、サーバは同時に大多数のクライアントとやり取りをすることが大前提だからです。
- 客1 : 「ハンバーガーセットをお願いします」
- 店員 : 「サイドメニューは何にしますか？」
- 客2 : 「ハンバーガーセットをお願いします」
- 客1 : 「ポテトで」
- 店員 : 「（客2へ）サイドメニューは何にしますか？」
- 店員 : 「（客1へ）ドリンクはどうしますか？」
- 客1 : 「コーラで」
- 客3 : 「ハンバーガーセットを…」
- 客4 : 「ハンバーガーセットを…」
- 店員 : 「（客1へ）サイズはどうしますか？」
- 店員 : 「（客3へ）サイドメニュー…」
- 客2 : 「ポテトで」
- 店員 : 「…。」
この例を見ると、ステートフルで複数を相手にすることが大変だと実感できると思います。
サーバで言うと、メモリの使用量が増えたり、サーバ側の処理が増えるのでやり取りが遅くなります。
これがステートレスである理由の1つです。
また、スケーラビリティ（拡張性）の観点からもステートレスの方がいいと言えます。
詳しく書くと、サイトにアクセスが集中したらサーバを増設して対応します。そのとき、ステートレスであれば別のWebサーバーが応答できるようになります。
- 客 : 「ハンバーガーセットをお願いします」
- 店員1 : 「サイドメニューは何にしますか？」
- 客 : 「ハンバーガーセットをポテトでお願いします」
- 店員2 : 「ドリンクはどうしますか？」
- 客 : 「ハンバーガーセットをポテトとコーラでお願いします」
- 店員3 : 「サイズはどうしますか？」
- 客 : 「ハンバーガーセットをポテトとコーラのLサイズでお願いします」
- 店員2 : 「以上でよろしいですか？」
- 客 : 「ハンバーガーセットをポテトとコーラのLサイズ、以上でお願いします」
- 店員4 : 「かしこまりました」
ステートレスというのは一見冗長に見えますが、実は理にかなった仕組みになっています。
HTTP通信では状態を持てないことを上で説明しました。
ということは、ログインをしても、次のページではログインをしているのかどうかわからないということになってしまいます。
この問題を解決するのがセッションです。
- 誰がアクセスしているのか？何回目のアクセスなのか？などの状態を持てるようにする仕組み
- ログイン機能やショッピングカート機能などが使えるのはセッションのおかげ