JSブラウザストレージの詳しい説明

導入

フロントエンドを深く知るにつれて、Cookie、LocalStorage など、多くのブラウザストレージソリューションについて学びました。これらのストレージソリューションの類似点と相違点は何ですか。また、それぞれの適用可能なシナリオは何ですか。

クッキー

クッキーのソース

クッキーはもともとローカルストレージ用ではなく、ユーザーを識別するために作成されました。ご存知のとおり、Http プロトコルはステートレスです。つまり、サーバーに送信するすべてのリクエストはサーバーに分離され、サーバーはこれらのリクエストの送信元を認識しません。たとえば、ショッピングカートにいくつかのアイテムを追加したが、チェックアウト要求を送信したときにサーバーが混乱しました。どうすれば、あなたが誰で、何を購入したかを知ることができるでしょうか? Cookie を使用すると、サーバーは Cookie をチェックすることで送信元ユーザーを判別できます。ある意味で、Cookie はリクエストの ID カードであると言えます。リクエストが誰から送信されたかをサーバーに伝えることができます。

クッキーとは

百聞は一見に如かず。クッキーがどんなものか見てみましょう

これは、Baidu のホームページで使用される Cookie です。ご覧のとおり、Cookie は名前と値のペアとしてブラウザに保存され、値は明らかに暗号化されたデータです。

クッキー生成方法

このクッキーはドメイン名、つまりBaiduホームページのクッキーに属します。ドメイン属性から、最初の2つのクッキーが.baidu.comに属していることがわかります。

各ドメイン名は、自身のドメイン名の Cookie のみを設定およびアクセスできます。たとえば、baidu.com はドメイン sougou.com の Cookie にアクセスできません。ただし、サブドメインは親ドメインによって設定された Cookie を読み取ることができます。たとえば、スクリーンショットでは、www.baidu.com は Domain='.baidu.com' の Cookie を読み取ります。Domain を手動で設定することで、親ドメインの Cookie を設定できます。たとえば、www.baidu.com は Domain='baidu.com' を設定することで、*.baidu.com のすべてのサブドメインも、設定した Cookie を読み取ることができます。

//www.baidu.com

document.cookie='年齢=20;ドメイン=.baidu.com'

// 現時点では、すべての第2レベルドメイン名はこのCookieを直接読み取ることができます

クッキーは、サーバー側での生成とブラウザ側での生成の 2 つの方法で生成されます。

サーバー側 - HTTPレスポンスヘッダーにset-cookieを設定する

レスポンスヘッダーの Set-Cookie を通じて保存する Cookie 値を指定できます。リクエストがブラウザに戻ると、ブラウザはヘッダーの set-cookie 値に従って Cookie を設定します。デフォルトでは、ドメインは Cookie を設定するページのホスト名に設定されます。もちろん、ドメイン値を手動で設定することもできます。

Cookie の設定: id=a3fWa;

browser-jsでは、document.cookieを通じてクッキーを読み書きし、キーと値のペアの形式で表示することができます。

ドキュメント.cookie="id=a3fWa"
document.cookie='年齢=20;ドメイン=.baidu.com'

クッキーの適用シナリオ

クッキーの機能は、リクエストの送信元をサーバーに伝えることであるため、主な機能はユーザーのログイン状態を維持すること（パスワードを記憶すること）です。さらに、ユーザーの閲覧データ、プッシュ広告、前述のショッピングカートを記録することもできます。

クッキーのデメリット

実際、前回の記事では欠点が非常に明白です。

大きさが足りない

クッキーはリクエストごとに送信されるため、クッキーには厳密なサイズ制限が必要です。各クッキーのサイズは 4kb に制限されています。4kb は名前と値のサイズを指し、このドメインに設定できるクッキーの合計サイズが 4kb のみであるという意味ではないことに注意してください。

パフォーマンスの欠点

クッキーはドメイン名に従い、同じドメイン名へのリクエストごとに送信されます。ただし、画像などの静的リソースのリクエストなど、大量のリクエストにはクッキーはまったく必要ありません。各クッキーはわずか 4kb ですが、少量でも大量のリソースが無駄になります。

静的リソースを CDN に配置することができます。このとき、画像のドメイン名はメインサイトのドメイン名とは異なり、Cookie は送信されません。

十分に安全ではない

コンソールを直接開くとクッキーを見ることができるのと同様に、クッキーはエンコードによって暗号化されているものの、HTTP 転送時にはプレーンテキストで転送されます。スクリプトでも簡単にクッキーを取得できるため、非常に簡単に解読されてしまいます。

サーバー側でクッキーを設定する場合は、ブラウザがdocument.cookieを使用してクッキーにアクセスできないようにHttpOnlyタグを添付します。

Cookie の設定: id=a3fWa; HttpOnly

「セキュア」とマークされた Cookie は、Https プロトコルの暗号化されたリクエストを通じてのみ送信される必要がありますが、Cookie は本質的に安全ではなく、これら 2 つのタグでは明確なセキュリティ保証を提供できないため、機密情報を保存するために Cookie を使用しないでください。

回避策

Cookie には多くの欠点がありますが、恒久的な解決策はあるのでしょうか? それは、「プロの人がプロの仕事をする」ということです。

ユーザーのログイン状態と一部のユーザー情報を保存するタスクは、Seesion に引き継がれます。つまり、Cookie は一意のユーザー識別子を保存するためだけに使用され、実際の情報はサーバー側に保存されます。Cookie は、サーバー上の情報を検索するための SeesionID として使用されます。この方法では、Cookie の容量制限とセキュリティの問題が解決されます。この時点では、Cookie には意味のないランダムコードの文字列が含まれているためです。

ローカルストレージの役割は、HTML5 の新しいローカルストレージソリューション「Web Storage」に引き継がれ、localStorage と SessionStorage の 2 つのカテゴリに分かれています。次に、この 2 つの兄弟を紹介します。

ローカルストレージ

特徴

データは手動で削除されるまで長期間保存されます
サイズは約5M
クッキーと同様に、Web サイトは独自のドメイン名の下にあるデータにのみアクセスして操作できます。
クライアント側でのみ使用され、サーバー側との通信はありません
インターフェースのカプセル化の改善
キーと値のペアを使用して情報を保存する
同じオリジンのウィンドウは、

使用例

LocalStorage は非常に便利です:

// データを設定する localStorage.setItem("key","value");
//データを読み取る let valueLocal = localStorage.getItem("key");

使用シナリオ

上記の機能から、LocalStorage はローカルキャッシュに非常に適しており、最初の画面の読み込み速度を向上させることができることがわかります。画像など、頻繁に変更されない大きなリソースもキャッシュして、ネットワーク要求を削減できます。

セッションストレージ

特徴

保存時間はこのセッションのみ有効です。つまり、ウィンドウを閉じると保存時間は失われます。
このウィンドウのみがアクセスでき、同じソースを持つ他のウィンドウはアクセスできません。
小さい約5M

使用シナリオ

sessionStorage は、それと同期されるライフサイクルおよびセッションレベルの情報を保存するのに適しています。この情報は現在のセッションにのみ適用されます。たとえば、フォームデータを永続化して、更新後にフォームデータが失われないようにするために使用できます。

Cookie、LocalStorage、SessionStorage の違い

範囲の違い

これら 3 つはすべてプロトコルに従います。つまり、同じプロトコル、同じドメイン名、同じポートで同じデータにアクセスして変更できます。唯一の違いは、SeesionStorage でも同じウィンドウが必要であることです。

ライフサイクルの違い

クッキーの有効期限は手動で設定できます。デフォルトは現在のセッションの期間です。ウィンドウを閉じるとクッキーは削除されます。有効期限が設定されると、有効期限までハードディスクに保存されます。
LocalStorage は、手動で削除しない限り常に存在する永続的なローカルストレージです。
SessionStorage はセッションレベルのストレージであり、ウィンドウが閉じられると削除されます。