HTTPキャッシュ及び多くのwebストレージ概念の小整理

キャッシュは1つのウェブサイトにとって非常に重要で、ウェブサイトの性能を高めることができて、冗長なデータの伝送を減らして、サーバーの負担を増加して、webストレージはブラウザにもっと強いファイルを保存するインターフェースを提供しました.HTTPキャッシュに関する属性がかなり混同されていますが、HTML 5のオフラインストレージとローカルストレージの関係は、最近、これらのWebストレージに関するものを整理して、まず関連する属性と概念をリストして、それらの違いとつながりを整理できるかどうかを見てみました.

manifest

cache-control

expires

304(no modified)

ETag

If-None-Match

Last-Modified

If-Modified-Since

http-equiv

webstorage

cookie/session

少し乱れているような気がするのではないでしょうか.私が整理したノートについて一度行ってみましょう.)まず、HTTPキャッシュに関するものを話しましょう.Cache-Control: HTTPで要求されたリソースは、応答ヘッダでCache-controlでブラウザにキャッシュポリシーを定義することができます.プロパティ値を設定することで、誰ができるか、どの条件で応答をキャッシュできるかを制御することができます.キャッシュの有効期間もあり、この属性のいくつかの一般的な値は以下の通りである:no-cache：はキャッシュを使用しないことを示し、先にサーバと戻ってくるリソースが変更されているかどうかを確認するno-store：はブラウザとすべての中継キャッシュ応答を禁止するリソースmax-age=100：はキャッシュの有効期間を示し、単位は秒であり、この時間内にキャッシュファイルにいくつかの変更が発生しない限り、それ以外の場合は、以前のキャッシュを直接使用します.この間、Etagなどの方法で検証されたリソースが変更されていないことに注意してください.キャッシュされたファイルが変動し、主にこれらの状況がある:リソース名の変更、リソースアドレスの変更、キャッシュの削除、Webページの強制リフレッシュなど;リソース名の変更、ファイル名のバージョンhash値の追加、例えばimage.pngをimage-hashに変更する.pngは,ファイルを更新するたびにユーザが要求を再発行し,最新のリソースを取得できることを保証する.リソースパスの変更、imageなどのファイルのリクエストパスの変更.pngクエリーパラメータをimageに変更する.png?hash,max-ageの時間設定は、サイトごとに実際の状況に応じて設定、極端な方法は、この値を大きく設定し、リソース名を変更したり、リソース要求アドレスにクエリーパラメータを追加したりすることで、ブラウザに更新リソースを教え、一般的には長い間サイトを更新する場合に使用される.public：はmax-ageでデフォルトpublicです.private：プライベートキャッシュを設定する必要はありません.中継キャッシュは許可されませんが、ブラウザでキャッシュできます.
HTTPキャッシュの他の概念:expires：は存在する時間を表し、クライアントがこの設定の時間までにリソースを要求する必要がないようにするmax-ageに似ているが、expiresは固定時間を表し、サーバとクライアントの時間が一致しないという問題があり、主にHTTP 1に用いられる.0バージョン、HTTP 1.1バージョンは完全により強力なCache-Controlで代替することができ、max-ageと同時に存在する場合、expiersがhttp-equiv：キャッシュを上書きする2つの制御メカニズムがあり、1つは要求ヘッダ情報制御であり、もう1つはmetaラベルを利用することである.HTMLドキュメントではmetaタグにhttp-equivを対応する属性名、contentを値としてキャッシュを設定できます.たとえばはWebページを変更するHTMLファイルにのみキャッシュ作用があり、そのページの他のリソースや他のページのHTMLファイルには作用しません.
ではmax-age(expires)が期限切れになった後、no-cacheの下のリソースは先にサーバに戻ったリソースが変更されているかどうかを確認し、どのようにこのプロセスを実現しますか?ETag/If-None-Match，Last-Modified/If-Modified-Since ETag(Entity Tag)は、リソースを識別するための検証トークンであり、hash値であるか、バージョン番号であるかのいずれかであり、リソースが変更されるたびにETagの値が変更され、ブラウザの最初のリクエストが変更されると、次のリクエストが送信されるときにEtagが変更されたかどうかを検証するために、応答ヘッダのETag値が保存されます.では、次のブラウザは、Etagと対応するリソースがローカルに保存されていることをサーバにどのように伝えますか?If-None-MatchリクエストヘッダにIf-None-Martch(ETagが存在する場合はブラウザが自動的に追加)を追加することで、前回のリクエスト後にローカルに格納されたEtag値に値を付与し、サーバはサービス側の最新リソースのEtagと比較し、変更がなければブラウザに304 no modifiedを直接返し、ブラウザはローカルキャッシュされたファイルを直接使用するLast-Modified/If-Modified-Sinceその役割はETag/If-None-Match，に等しいが、前者は所定の時間で対比され、最小の単位は秒であり、後者は一意の識別子を通過するので、元の駅が1秒以内に何度も更新された場合、前者は役に立たないことがわかる.ETagの検証はLast-MOdifiedよりも優先され、またETagにも欠点があり、分散環境では、異なるサーバでのEtagの同期問題がサーバにいくつかの圧力をもたらす可能性があります.HTTPキャッシュは各HTTPリクエストに直接関連しており、各リクエストリソースの応答には対応するキャッシュポリシーがあります.それらはよく似ていますが、他のメカニズムを通じて、ブラウザにどのファイルをキャッシュするかを直接伝えることができますか?HTML 5オフラインストレージが登場
H 5オフラインストレージ:サーバが1部通過する.manifestファイルはブラウザに完全なキャッシュリストを提供し、リストにはキャッシュが必要なファイル、キャッシュが必要なファイルのリストが含まれているほか、リソースに代替の要求アドレスを設定したり、404ページを設定したりするなど、他の機能があります.
実装:H 5のラベルの新しい属性manifestを利用して、HTMLファイルに，サーバーを追加するだけでmanifestファイルのmime-typeをtext/cache-manifestタイプに設定すればいい.ブラウザは要求するたびにmanifestファイルが更新されているかどうかをチェックし、サービス側はmanifestファイルを修正することで、ブラウザが次にリソースを要求するときに、対応するリソースの更新を通知できます.
役割:ローカルオフラインストレージにより、ネットワークがない場合にウェブサイトにアクセスして事前に保存したファイルリソースを保存することができ、ネットワークがある場合にローカルリソースを直接使用することも、接続を要求する圧力を減らし、ウェブページのロード速度を高めることができる.ここでHTTPキャッシュとの違いに注意し、ローカルリソースを直接使用し、200(from cache)を要求する.管理を統一するmanifestがあるため、更新があるかどうかを確認するよう要求する必要はなく、期限切れもありません.PS:ここではmanifestファイル自体の更新について、HTTPキャッシュを実行するか、このファイルを直接キャッシュしないかという問題があります.前述の概念は主にキャッシュ要求ファイルというブロックのものであり、それらの目的はすべてウェブページの性能を高めることであり、最適化型のストレージと言え、ユーザーによりスムーズな体験をもたらすことができるが、私たちの印象にはもう一つのストレージがあり、それは私たちにより多くの可能性と効果の実現を提供することができ、機能型のストレージである.H 5ローカルストレージWebstorage，cookie，session cookie，session周知のように、HTTPは無状態のプロトコルであり、要求ごとに独立して連絡がなく、ブラウザやサーバはユーザーの状態を維持することができず、ユーザーが依然として前のユーザーであるかどうかを判断する.同じユーザの各リクエストヘッダに一意の識別子を追加することで、この識別子を判断することでユーザのいくつかの情報と状態を維持することが容易に考えられる.セッション情報は識別子として用いられ,クッキーメカニズムはクライアントでステータスを保持するスキームを採用し,セッションメカニズムはサーバ側でステータスを保持するスキームを採用している(サービス側でステータスを保持するにもクライアントでステータスを保持する必要があるため,一般的にセッションはベースクッキーまたはセッションstorageを必要とする)
総じて言えば:cookieデータはクライアントに置いて、sessionデータはサービス側に置いて、cookieは期限を設定することができて、sessionはブラウザを閉じる時に破棄します(cookieのデフォルトもです)、cookieは安全ではありませんて、sessionはサーバーの性能に影響する可能性があります
Cookie:通常、JavascriptでsetCookieの関数をカプセル化して作成されます.サイズに制限があり、リクエストヘッダが肥大化する可能性があります.ブラウザがリクエストを送信するときに、ローカルのcookieをチェックします.このcookie宣言の範囲がリクエストのurlアドレスより大きい場合、自動的にリクエストにcookieフィールドを追加します.
session:サーバはブラウザリクエストヘッダのsession IDをチェックするたびに、ある場合はこのsession idをサーバのデータベース(ハッシュリスト)で検索し、見つけてから対応する権限の操作を行います.このリクエストIDがなければ、クライアントに新しいものを作成し、クライアントに返信した後、クライアントはcookieまたはsessionstorageでこのsession idを保存することができます.ヘッダのクッキーフィールドを要求してサーバにsessionIdを提供し、クッキーが禁止されている場合、urlパスに追加したり、フォーム非表示ドメインを追加したりする他の方法が必要です.
CookieはHTTPプロトコル仕様の一部として、主にユーザー情報を格納するために使用され、サービス側と対話するために使用され、サイズも制限されている.ただ、セッションレベルのストレージlocalstorage，sessionstorage webstorageは、より大きなストレージファイル設計のために、Cookieがユーザー情報を記録する責任を負うよりも、webstorageはローカルストレージに専念し、パッケージされたsetItemを通じて、getItemなどの方法でlocalstorageを使用することができる永続化されたストレージであり、自発的に削除しない限り永遠に存在しない.sessionstorageは主にセッション(session)を格納するために使用され、ブラウザを閉じると破棄される.非永続化されたストレージである.上記の概要のほか、IndexDB、FileSystemなどのストレージ方法もある.Webストレージに関する知識は本当に多く、穴も少なくないように見えますが、実践して徐々に身につける必要があります.