159

chesseng.herokuapp.comにアクセスすると、次のような応答ヘッダーが表示されます。

Cache-Control:private
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/css
Date:Tue, 16 Oct 2012 06:37:53 GMT
Last-Modified:Tue, 16 Oct 2012 03:13:38 GMT
Status:200 OK
transfer-encoding:chunked
Vary:Accept-Encoding
X-Rack-Cache:miss

次に、ページを更新して取得します

Cache-Control:private
Connection:keep-alive
Date:Tue, 16 Oct 2012 06:20:49 GMT
Status:304 Not Modified
X-Rack-Cache:miss

したがって、キャッシュが機能しているようです。それがキャッシングで機能する場合、ExpiresとCache-Control：max-ageのポイントは何ですか。混乱を増すために、https：//developers.google.com/speed/pagespeed/insights/でページをテストすると、「ブラウザのキャッシュを活用する」と表示されます。

4

4 に答える 4

172 
Cache-Control: private

応答メッセージの全部または一部が単一のユーザーを対象としており、プロキシサーバーなどの共有キャッシュによってキャッシュされてはならないことを示します。

RFC2616セクション14.9.1から

于 2012-10-16T07:17:27.377 に答える
93

Webサーバーにヘッダーが含まれていなくても、キャッシュが機能している理由についての質問に答えるには、次のようにします。

  • 有効期限： [a date]
  • キャッシュ制御： max-age =[seconds]

サーバーは親切にも中間プロキシにコンテンツをキャッシュしないように要求しました（つまり、アイテムはプライベートキャッシュにのみキャッシュする必要があります。つまり、自分のローカルマシンにのみキャッシュする必要があります）。

  • キャッシュ制御：プライベート

しかし、サーバーはあらゆる種類のキャッシュヒントを含めるのを忘れていました。

  • Expiresを含めるのを忘れた（ブラウザはその日付までキャッシュされたコピーを使用することを知っている）
  • 彼らはMax-Ageを含めるのを忘れていました（ブラウザはキャッシュされたアイテムがどれくらいの期間有効であるかを知っているので）
  • 彼らはE-Tagを含めるのを忘れていました（ブラウザが条件付きリクエストを実行できるようにするため）

ただし、応答には最終変更日が含ま れていました。

Last-Modified: Tue, 16 Oct 2012 03:13:38 GMT

ブラウザはファイルが変更された日付を知っているため、条件付きリクエストを実行できます。サーバーにファイルを要求しますが、ファイルが2012/10/16 3:13:38以降に変更されている場合にのみ、ファイルを送信するようにサーバーに指示します。

GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT

サーバーはリクエストを受信し、クライアントがすでに最新バージョンを持っていることを認識します。200 OKクライアントに続いてページのコンテンツを送信するのではなく、キャッシュされたバージョンが適切であることを通知します。

304 Not Modified

ブラウザは、サーバーにリクエストを送信して応答を待つというラウンドトリップ遅延に悩まされる必要がありましたが、静的コンテンツを再ダウンロードする必要がなくなりました。

なぜマックスエイジ？なぜ期限切れになるのですか？

Last-Modifiedは最悪だからです。

サーバー上のすべてに日付が関連付けられているわけではありません。その場でページを作成している場合、それに関連付けられた日付はありません。現在はです。しかし、私はユーザーに15秒間ホームページをキャッシュさせたいと思っています。

200 OK
Cache-Control: max-age=15

ユーザーがハンマーF5を打つと、キャッシュされたバージョンを15秒間取得し続けます。これが企業プロキシの場合、同じ15秒のウィンドウで同じページにアクセスする67,198人のユーザー全員が同じコンテンツを取得し、すべてクローズキャッシュから提供されます。誰にとってもパフォーマンスが勝ちます。

追加の利点はCache-Control: max-age、ブラウザが「条件付き」リクエストを実行する必要さえないことです。

  • のみを指定した場合Last-Modified、ブラウザはリクエストを実行し、応答If-Modified-Sinceを監視する必要があります304 Not Modified
  • 指定した場合max-age、ブラウザはネットワークのラウンドトリップに苦しむ必要さえありません。コンテンツはキャッシュから直接出力されます。

「Cache-Control：max-age」と「Expires」の違い

ExpiresCache-Control: max-ageは、最新のヘッダーに相当するレガシー（c。1998）です。

  • Expires：日付を指定します（yuck）

  • max-age：秒を指定します（良さ）

  • そして、両方が指定されている場合、ブラウザは以下を使用しますmax-age。

      200 OK
  Cache-Control: max-age=60
  Expires: 20180403T192837

1998年以降に作成されたWebサイトはExpires、これ以上使用せず、代わりにを使用する必要がありますmax-age。

ETagとは何ですか？

ETagは、日付である必要はなく、単にである必要があることを除いて、Last-Modifiedに似ていsomethingます。

データベースから製品のリストを取得している場合、サーバーはrowversion日付ではなくETagとして最後の製品を送信できます。

200 OK
ETag: "247986"

私のETagは、静的リソース（画像、js、css、フォントなど）またはキャッシュされたレンダリングページのSHA1ハッシュにすることができます（つまり、これはMozilla MDN wikiが行うことであり、最終的なマークアップをハッシュします）。

200 OK
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

そして、 Last-Modifiedに基づく条件付きリクエストの場合とまったく同じです。

GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT

304 Not Modified

ETagに基づいて条件付きリクエストを実行できます。

GET / HTTP/1.1
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

304 Not Modified

Anは、ファイル以外のもの、または日付の概念を持つものに対して機能するため、ETagより優れています。ただ_Last-Modified

于 2018-04-03T18:54:31.150 に答える
22

RFC 2616、セクション14.9.1：

応答メッセージの全部または一部が単一のユーザーを対象としており、共有キャッシュによってキャッシュされてはならないことを示します...プライベート（非共有）キャッシュは応答をキャッシュできます（MAY）。

ブラウザはこの情報を使用できます。もちろん、現在の「ユーザー」とは、OSユーザー、ブラウザユーザー（Chromeのプロファイルなど）など、さまざまな意味があります。指定されていません。

私にとって、より具体的な例はCache-Control: private、プロキシサーバー（通常は多くのユーザーがいる）がそれをキャッシュしないことです。これはエンドユーザー向けであり、他のユーザー向けではありません。

参考までに、RFCは、これがセキュリティを提供しないことを明確にしています。コンテンツを保護するのではなく、正しいコンテンツを表示することです。

プライベートという言葉のこの使用法は、応答がキャッシュされる場所を制御するだけであり、メッセージコンテンツのプライバシーを保証することはできません。

于 2014-02-01T20:07:24.593 に答える
0

Expiresエンティティヘッダーフィールドは、応答が古くなったと見なされるまでの日付/時刻を示します。Cache-control：maxageフィールドは、応答が古くなったと見なされるよりも大きい経過時間値（秒単位）を示します。

上記のヘッダーフィールドは、サーバーにリクエストを送信するかどうかを決定するメカニズムをクライアントに提供します。ある条件では、クライアントがサーバーにリクエストを送信し、応答の経過時間の値が最大値よりも大きい場合、サーバーがクライアントにリソースを送信する必要があることを意味しますか？たぶん、リソースは決して変更されませんでした。

この問題を解決するために、HTTP1.1は最後に変更されたヘッドを提供します。サーバーは、応答の最終変更日をクライアントに提供します。クライアントがこのリソースを必要とする場合、クライアントはIf-Modified-Sinceヘッドフィールドをサーバーに送信します。この日付がリソースの変更日より前の場合、サーバーはリソースをクライアントに送信し、200コードを提供します。それ以外の場合、サーバーはクライアントに304コードを返します。これは、クライアントがキャッシュしたリソースを使用できることを意味します。

于 2017-02-18T12:37:03.273 に答える