Cache-Control：privateとは何ですか？

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/でページをテストすると、「ブラウザーのキャッシュを利用する」ように指示されます。

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秒のウィンドウで同じページにアクセスする67198ユーザーはすべて同じコンテンツを取得します-すべてクローズキャッシュから提供されます。誰にとってもパフォーマンスの勝利。

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

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

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

Expires現代（1998年頃）のCache-Control: max-ageヘッダーに相当するレガシーです。

• Expires：日付を指定します（yuck）
• max-age：秒を指定する（良さ）

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

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

1998年以降に作成されたWebサイトは使用できExpiresなくなり、代わりにを使用しますmax-age。

ETagとは何ですか？

ETagはLast-Modifiedに似ていますが、日付である必要はなく、何かである必要があります。

データベースから製品のリストを取得している場合、サーバーは最後の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、それはほかのもののために働くので、ファイルの概念が持っている、または物事日付を。それだけです

Cache-Control: private

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

RFC2616セクション14.9.1から

RFC 2616、セクション14.9.1：

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

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

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

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

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

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

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

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