モバイルネットワークの発展と進化に伴い、携帯電話のネイティブアプリに加えて、「WebApp」を実行することもできます。これはすぐに使用でき、使い切ったときに使用できます。優れたWebAppは、ネイティブアプリに匹敵する機能とエクスペリエンスを備えています。WebAppの優れたパフォーマンスの理由の一部は、ブラウザストレージテクノロジーの向上に起因する可能性があります。データを保存するCookieの機能は、開発ニーズを満たすのが困難でしたが、徐々にWeb StorageとIndexedDBに置き換えられました。この記事では、これらの保存方法の違い、長所、短所を紹介します。
1つ、クッキー
1.クッキーの起源
Cookieの役割は、Cookieをローカルに保存することではなく、「状態を維持する」ことです。HTTPプロトコルはステートレスであるため、HTTPプロトコル自体は要求と応答の間の通信状態を保存しません。一般的に、サーバーはユーザーが前回何をしたかを知らないため、インタラクティブなWebアプリケーションの実装が大幅に妨げられます。典型的なオンラインショッピングのシナリオでは、ユーザーはいくつかのページを閲覧し、ビスケットの箱と飲み物のボトル2本を購入します。チェックアウトの最後に、HTTPのステートレスな性質と追加の手段がないため、サーバーはユーザーが何を購入したかを知らないため、Cookieが作成されました。これは、HTTPのステートレス性を回避するために使用される「追加の方法」の1つです。サーバーは、Cookieに含まれる情報を設定または読み取り、サーバーとの会話中のユーザーの状態を維持できます。
ちょうど今のショッピングシナリオでは、ユーザーが最初のアイテムを購入すると、サーバーはユーザーにCookieを送信し、Webページをユーザーに送信して、そのアイテムの情報を記録します。ユーザーが別のページにアクセスすると、ブラウザーはCookieをサーバーに送信するため、サーバーはユーザーが以前に購入したものを認識します。ユーザーは引き続き飲み物を購入し、サーバーは元のCookieに新しい製品情報を追加します。チェックアウト時に、サーバーは送信されたCookieを読み取るだけです。
2.クッキーとは
Cookieは、ユーザーのIDを識別するために、一部のWebサイトがユーザーのローカル端末に保存するデータ（通常は暗号化されている）を指します。Cookieはサーバーによって生成され、クライアントによって維持および保存され、メモリまたはディスクに保存されます。サーバーはCookieを介して、リクエストの送信元を知ることができます。その後、ログイン後の更新など、クライアントの状態を維持できます。リクエストヘッダーには、ログイン時とタイミングで応答ヘッダーにSet-Cookieが含まれます。 Webサーバーはリクエストを受信し、Cookieの値を読み取ることができ、一部のユーザーの情報の状態はCookieの値の内容に基づいて判断および復元できます。
つまり、Cookieを使用すると、ステートレスHTTPプロトコルに基づいて安定した状態情報を記録できます。
クッキーは主に次の3つの分野で使用されます。
- セッション状態管理（ユーザーのログインステータス、ショッピングカート、ゲームスコア、または記録する必要のあるその他の情報など）
- パーソナライズされた設定（ユーザー定義の設定、テーマなど）
- ブラウザの行動の追跡（ユーザーの行動の追跡や分析など）
3.クッキーの原理と構成
初めてWebサイトにアクセスすると、ブラウザーは要求を送信します。サーバーはCookieを生成し、応答のSet-Cookieヘッダーを介してクライアントに通知します（複数のSet-Cookieヘッダーは複数の値を渡すことができます）。クライアントの後Cookieを取得すると、後続のリクエストは自動的にCookieヘッダーをリクエストに取り込み、サーバーに送信します（以下の例を参照）。さらに、Cookieの有効期限、ドメイン、パス、有効期間、および該当するサイトをすべて指定できます。必要に応じて。
// 一个HTTP响应：
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Other-header: other-header-value
复制代码このHTTP応答は、「value」の値を持つ「name」という名前のCookieを設定します。名前と値は、送信時にURLエンコードされます。ブラウザはこれらのセッション情報を保存し、次のような後続の各リクエストでHTTPヘッダーCookieを介してサーバーに送り返します。
GET /index.jsl HTTP/1.1
Cookie: name=value
Other-header: other-header-value
复制代码Cookieは、ブラウザの次のパラメータで構成されています。
- name：Cookieを一意に識別する名前。Cookie名では大文字と小文字が区別されないため、myCookieとMyCookieは同じ名前です。ただし、実際には、一部のサーバーソフトウェアではCookie名が大文字と小文字が区別される場合があるため、Cookie名は大文字と小文字が区別されるものとして扱うのが最善です。Cookie名はURLエンコードされている必要があります。
- value：Cookieに保存されている文字列値。この値はURLエンコードされている必要があります。
- ドメイン：Cookieが有効なドメイン。このドメインに送信されるすべてのリクエストには、対応するCookieが含まれます。指定しない場合、サブドメインを除いて、デフォルトでドキュメントソース（プロトコル、ドメイン名、およびポートによって定義されます）になります。指定した場合
Domain、通常はサブドメイン名が含まれます。したがって、指定Domainは省略よりも制限が少なくなります。ただし、これは、サブドメインがユーザーに関する情報を共有する必要がある場合に役立つことがあります。たとえば、Domain = mozilla.orgを設定すると、Cookieはサブドメイン（developer.mozilla.orgなど）にも含まれます。 - パス：このパスがリクエストURLに含まれている場合にのみ、Cookieがサーバーに送信されます。
// 例如，设置 Path=/docs，则以下地址都会匹配：
/docs
/docs/Web/
/docs/Web/HTTP
复制代码- Expires / Max-Age：Cookieの有効期限（Expires）または有効期間（Max-Age）を設定します（つまり、それ以降はサーバーに送信されません）。単純な名前と値のペアの形式のCookieは、現在のセッション中にのみ存在し、ユーザーがブラウザを閉じると失われます。Cookieのライフサイクルが単一のブラウジングセッションを超えるようにする場合は、Expires / Max-Ageを指定し、max-ageの優先度をexpiresよりも高くします。
- セキュア：設定後、SSLセキュア接続を使用している場合にのみCookieがサーバーに送信されます。たとえば、リクエスト
https://www.wrox.comはCookieを送信しますが、リクエストは送信しhttp://www.wrox.comません。 - HttpOnly：HttpOnly属性が設定されたCookieには、クロスサイトスクリプティング攻撃（XSS）を防ぐためにJavaScriptを使用してDocument.cookie属性、XMLHttpRequest、およびRequestAPIを介してアクセスすることはできません。
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value; domain=.wrox.com; path=/; secure
Other-header: other-header-value
复制代码ここで作成されたCookieは、wrox.comのすべてのサブドメインとこのドメインのすべてのページ（path = /で指定）に有効です。ただし、このCookieは、セキュアフラグが設定されているため、SSL接続でのみ送信できます。
ドメイン、パス、有効期限、およびセキュアフラグは、どのような状況でCookieをリクエストに含める必要があるかをブラウザに通知するために使用されることを知っておく必要があります。これらのパラメータはリクエストとともにサーバーに送信されず、Cookieの名前と値のペアのみが実際に送信されます。
4.JavascriptのCookie
一般的に、Cookieを生成する主な方法は2つあります。1つは上記の応答のSet-Cookieヘッダーを介してクライアントに通知する方法、もう1つはJavaScriptのdocument.cookieを介してCookieを読み書きする方法です。
//读取浏览器中的cookie
console.log(document.cookie);
//写入cookie
document.cookie='myname=langlixingzhou;path=/;domain=.baidu.com';
复制代码JavaScriptでCookieを処理するのは面倒です。インターフェースが単純すぎて、BOMのdocument.cookieプロパティだけだからです。値を設定するときに、document.cookieプロパティを介して新しいCookie文字列を設定できます。この文字列は、解析後に元のCookieに追加されます。document.cookieを設定しても、既存のCookieが設定されていない限り、以前に存在していたCookieは上書きされません。作成されたCookieの追加情報を指定するには、Set-Cookieヘッダーと同じ形式の文字列を追加するだけです。
document.cookie = encodeURIComponent("name") + "=" +
encodeURIComponent("Nicholas") + "; domain=.wrox.com; path=/";
// 使用encodeURIComponent()对名称和值进行编码
复制代码5.クッキーの欠陥
- クッキーは十分な大きさではありません
各Cookieのサイズは4KB（名前と値はこの4KBに含まれています）であり、複雑なストレージ要件には十分ではありません。クッキーが4KBを超えると、トリミングされる運命に直面します。このように、Cookieは少量の情報にアクセスするためにのみ使用できます。さらに、多くのブラウザには、サイトのCookieの数にも制限があります（通常は300を超えないCookie）。
- Cookieが多すぎると、パフォーマンスが大幅に低下します
Cookieは特定のドメインにバインドされています。同じドメイン名でのすべてのリクエストにはCookieが含まれます。現時点で画像またはCSSファイルのみを要求している場合、Cookieを使用して実行する必要があると想像してください（重要なのは、Cookieに格納されている情報が不要であるということです）。これはお金の無駄です。クッキーは小さいですが、リクエストが重なっているため、このような不要なクッキーによるオーバーヘッドは想像を絶するものです。
Cookieはユーザー情報を維持するために使用され、ドメイン名（domain）でのすべてのリクエストはCookieを伝送しますが、静的ファイルリクエストの場合、Cookie情報を伝送することは無意味です。現時点では、CDNのドメイン名とホスト（保存静的ファイル）を使用できます。ステーションのドメイン名は個別に解決されます。
- HTTPリクエストのCookieはプレーンテキストで渡されるため、HTTPSを使用しない限り、セキュリティは問題になります。
6.クッキーとセキュリティ
Cookieが安全に送信され、偶発的な参加者やスクリプトがアクセスできないようにするには、Secure 属性とHttpOnly 属性の2つの方法があります。
としてマークされたSecure Cookieは 、HTTPSプロトコルで暗号化された要求を介してのみサーバーに送信されるため、man-in-the-middle攻撃を防ぐことができます。ただし、Secure フラグが設定されて いても、Cookieは本質的に安全でSecure はなく、フラグは実際のセキュリティを提供できないため、機密情報をCookieを介して送信しないでください。たとえば、クライアントのハードドライブにアクセスできる人はそれを読み取ることができます。
Chrome52およびFirefox52以降、安全でないサイト（http:）はCookieSecure タグを使用できません 。
JavaScript Document.cookie APIは、HttpOnly 属性を持つCookieにアクセスできません 。このようなCookieはサーバー上でのみ機能します。たとえば、サーバー側セッションを永続化するCookieは、JavaScriptで使用できる必要はありませんが、HttpOnly 属性を持っている必要があり ます。この予防策は、クロスサイトスクリプティング（XSS）攻撃を軽減するのに役立ちます。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2019 07:28:00 GMT; Secure; HttpOnly
复制代码クッキーの制限とその特性により、クッキーは大量のデータを保存する理想的な方法ではなく、「専門家が専門的なことを行う」ことが可能になり、Webストレージが登場しました。
HTML5は、新しいローカルストレージソリューションであるWebストレージを追加しました。これにより、Webストレージでは、Cookieは、クライアントとサーバー間の対話のチャネルとして、クライアントの状態を維持しながら、本来の機能しか実行できなくなります。