主観も入ってます。
session
概要
情報自体はサーバサイドで持ち、
その情報にアクセスする為のキー値をcookieにてブラウザと共有する
情報をオブジェクトのまま持っておける
データ持続期間
-
サーバーサイドの情報保持期間
サーバサイドの情報の持ち方による -
Javaや.NETのメモリ保持が多い為、20分程度。プロセス再起動で揮発する
-
apache(phpとか)はファイル保持が多い為、結構長い。プロセス再起動しても不揮発
-
デフォルトだと、Webサーバが動作している環境でそのままセッション情報を管理する為、接続先サーバが変わるとセッション情報にアクセスできなくなる。で、DBやKVSに外出しする構成を取ったりする
-
最近はRedisが便利。セッション情報は、KVS向き！
-
ブラウザサイドのキー情報保持期間
ほどんどのWebサーバはSet-Cookieする際に有効期限を設定しない
つまり、ログアウトするまで/ブラウザを落とすまで保持し続ける -
ログアウト時は、有効期限を過去日にしてSet-Cookieする実装が必要
内容
- ログインユーザの契約情報(の一部)など、「マスターのデータストアにアクセスすると遅くなるから手元に持っときたいけど、外(ブラウザ)に渡すのは不安な情報」
- ブラウザ検証ツールで見られると困る情報
cookie
概要
情報自体はブラウザで保管し、リクエストを送出する度にサーバサイドに通知している。
有効期限が指定できたりdomain(後方一致)・pathが指定できたりhttp Onlyとかhttps Onlyとか・・・。
情報は、文字列形式でやりとりされる
domain・path・プロトコルが一致すれば、Ajaxでの通信やimageファイルの取得など、とにかく全てのリクエストで値を送ることになる。(よく問題になる)
データ持続期間
- ブラウザで「cookieを保持しない」設定をしていると、いくら長い有効期限を設定していても、ブラウザ落としたらなくなる。プライベートブラウザも同様。
- ブラウザの設定で有効期限指定が有効になっている場合、Set-Cookieに有効期限が設定されていれば、Set-Cookieに有効期限を設定時は、その有効期限まで保持
- Set-Cookieに有効期限を設定しない場合は、ブラウザを落とすまで保持
内容
まともな用法でいくと・・・
- セッション情報アクセス用のキー値
- ロードバランサーがバランシング後のサーバを覚えとく為のキー値
- javascriptでも使いたいし、サーバサイドでも使いたい情報
- ログアウト後、再ログイン時にも使った方が便利な情報
- ex) 言語選択、直近の検索条件など
- localStorage登場前に、localStorageで保持しときたかった情報
localStorage
概要
ブラウザが保管し、ブラウザしかアクセスできない。(PCの持ち主は、直接ファイル参照とか、できないこともないが・・・)
javascriptを使ってsetし、javascriptを使ってgetする
情報は、文字列形式でset-getする
データ保持期間
- sessionStrage：ウィンドウやタブを閉じるまで
- localStrage：永続(ただし、ブラウザ設定でブラウザ閉じるタイミングで解放するようにもできる)
内容
- 描画でだけ使いたい情報
- javascriptでだけ使いたい情報
- データ量が多い情報