HTTPキャッシングヘッダーの初心者向けガイド

この記事では、HTTPのキャッシュヘッダー（LC）およびコンテンツ配信ネットワーク（CDN）の対応する動作に関する情報を提供します。 キャッシュヘッダーが最新のWebにどのように適合するかを知りたい場合、または同僚が何を話しているのか知りたい場合は、この記事が役立ちます。



ZKの利点をすでに理解しており、知識を広げたい場合は、W3のドキュメントを参照することをお勧めします。

ZKはあなたのために何ができますか？

簡単に言えば、キャッシュを使用すると、サーバーからユーザーブラウザーまでの途中のリモートポイントにWebリソースを保存できます。 ブラウザはキャッシュも保存するため、クライアントが同じリソースを常に要求することはありません。



Webトラフィックのキャッシュ設定は、アクセスするサイトにとって重要です。 トラフィックの支払い、eコマースからの収入の獲得、または優れたWeb開発者としての評判を維持したいだけの場合は、キャッシングの仕組みを理解する必要があります。



会社のロゴ、ファビコンサイト、またはリクエストごとに変更されない基本的なCSSファイルなどのリソースの場合、リクエスターがこれらのファイルのコピーをしばらく保持できるようにすることができます。 あなたの訪問者が車の後部座席にいる子供で、「まだ到着しましたか？」といつも尋ねる人なら、この許可は「いいえ、もう20分行かなければならないので、私の答えを覚えておいてください」という答えに似ています。



サーバーへの要求の数を減らすことにより、サーバーが処理できる要求の数を増やします。 通常、写真、スクリプト、およびスタイルシートはテールとたてがみでキャッシュでき、動的に作成されたページ（フォーラム、Webアプリケーション）は通常は価値がありません。 主にパフォーマンスを懸念する場合は、すべての動的コンテンツをAJAXリソースで最小化し、残りを最大限にキャッシュする必要があります。

顧客およびCDN向け

従来、キャッシュ設定はクライアントのブラウザのみに関連していたため、忘れないでください。 しかし、今日では、コンテンツ配信ネットワーク（CDN）の急増に関連して、Webの中間地点でキャッシュがどのように機能するかを理解することがより重要です。

CDNとは何ですか？



Wikipediaの記事全体を読まないために、これらはサーバーとクライアントの間にある（複数の）サーバーです。 それぞれが、さまざまなHTTPヘッダーで指定したルールに従ってコンテンツをキャッシュします。

適切に設定すると、CDNはコンテンツを最速かつ最も近いサーバーを介してクライアントに転送します。 さらに、CDNはユーザーとユーザー間のバッファーとして機能します。 キャッシュされたリクエスト（CDNがサーバーをプルせずに処理したリクエスト）の割合に関心があります。 トラフィックとアーキテクチャに応じて、この数値は90％に達する可能性がありますが、小さい数値では効果がわかります。 少数のリクエストでは、それらのほとんどがサーバーに送信されることに注意する必要があります。したがって、この割合は、キャッシュ時間とサイトの全体的な負荷とともにのみ意味を持ちます。 ただし、1つのキャッシュのみを構成し、キャッシュヘッダーが正しく機能しない場合は、合計がさらに悪化する可能性があります。





サーバーは、異なる地域に存在する中間サーバーにコンテンツを配信します。



キャッシュに加えて、CDNには素晴らしい副作用があります。サーバーが突然クラッシュした場合、場合によってはCDNはユーザーが気付かないようにリクエストをバッファリングします。

主な見出し

1.キャッシュ制御

最も重要なもの。 通常、次のようなパラメータを1行で設定します。



キャッシュ制御：private、max-age = 0、no-cache



これらの設定はキャッシュ応答ディレクティブと呼ばれ、次のとおりです。



プライベート| 公開



コンテンツが特定のユーザー向けかどうかを報告します。 その場合、キャッシュする必要はありません。



キャッシュなし



ディレクティブ自体は、このリクエストは毎回新たに行わなければならないことを示しています。 以下で説明するetagヘッダーが一般的に使用されます。 このディレクティブの後にフィールドに名前を付けると、楽しみが始まります。 その後、キャッシュサーバーは回答をキャッシュできることを理解しますが、指定したフィールドを削除する必要があります。 これは、たとえば、Cookieの適切な操作に役立ちます。 ただし、一部の古いプログラムでは、このトリックの使用方法がわかりません。



店なし



この応答を保存する必要がないことを報告します。 驚くべきことに、事実。 キャッシュがルールに従って機能する場合、リクエストのどの部分も保存されないようにします。 これは、機密情報を保護するために必要です。



最大年齢



通常、リソースのライフタイムは有効期限で指定されますが、より具体的にする必要がある場合は、max-ageを秒単位で指定できます。 また、このディレクティブには有効期限よりも利点があります。



s-maxage



ただし、前のものと少し似ていますが、sは共有キャッシュを意味し、CDNに必要です。 このディレクティブはmax-ageよりも優先され、CDNサーバーになると期限切れになります。



再検証する必要があります



彼は、各リクエストを新たに行う必要があり、どのような状況でもユーザーがキャッシュされたコンテンツを提供するべきではないと言います。 キャッシングを有効にする他のすべてのディレクティブよりも優れています。 主にいくつかの特別なプロトコル（送金など）で使用されます。



変換なし



一部のプロキシは、コンテンツを圧縮および変換して作業を高速化できます。 このディレクティブはこの動作を禁止します。



プロキシの再検証



must-revalidateとほぼ同じですが、中間CDNサーバー用です。 なぜ彼女はs-mustrevalidateと呼ばれなかったのですか？ 彼を知っている人。 ポイントは、コンテンツが更新されたかどうかを確認するために、新しいユーザーごとに1回だけ必要なことです。

2.有効期限

当初、これはリソースの有効期限を決定する標準的な方法でした。 今日では、max-ageとs-maxageが優先されますが、下位互換性のためにこのヘッダーを設定することは常に役立ちます。



1年以上先の日付を設定すると、ヘッダーの仕様に違反します。

3. etag

エンティティタグの頭字語。 これは、要求されたリソースの一意の識別子です。通常、そのコンテンツのハッシュ、または更新された時間のハッシュです。 一般に、クライアントのCDNからのリクエスト方法は、「私のリソースとは異なるetagがある場合、リソースXを提供します」。

4.変化する

非常に強力なもの。 IEは過去に誤って処理していましたが、今でも正しく処理していません。 ある時点で、彼と一緒のChromeでさえバグがありました。 基本的に、ヘッダーは、キャッシュ内のコンテンツが有効かどうかを判断するために使用できるヘッダーをキャッシングシステムに伝えます。 キャッシュをキー値データストアと見なす場合、Varyを使用すると、これらの値がキーに追加されます。



多くの場合、Accept-Encodingのようなヘッダーを見つけることができます。これにより、gzipで圧縮されたリソースがクライアントに確実に受け入れられます。 それは多くのトラフィックを節約します。 また、設定



変化する：ユーザーエージェント



User-Agentに応じて異なるHTML / CSSをレンダリングすると、サイトのSEOがより使いやすくなります。 Googleはこの小さなことに気付き、Googlebotはモバイルコンテンツも処理します。

5.プラグマ

多くのことを実行できるかなり古いディレクティブですが、より新しいディレクティブを使用して既に処理されています。 私たちはフォームに最も興味があります



プラグマ：no-cache



現代の顧客では何が変わる



キャッシュ制御：キャッシュなし

警告

すべてのCDNまたはクライアントプログラムが仕様に従って動作するわけではありません。 Web開発者であれば、この問題に精通しています。 したがって、サービスを開始する前に、すべてをテストして、すべてが正常に機能することを確認する必要があります。



さらに、一部の見出しが重複または重複している場合があります。 これは、さまざまな方法のわずかな違い、またはWebがHTTP / 1.0からHTTP / 1.1プロトコルに移行したためです。このプロトコルでは、キャッシュがより詳細に説明されています。

1.圧縮

許容可能な圧縮としてgzipへの要求を受け取ったCDNプロバイダーは、サーバーから圧縮コンテンツを要求するか、リソースの圧縮バージョンをクライアントに提供する必要があります。 最新のCDNは、リソース圧縮を独立して実行できます。



CDNサーバーのパフォーマンスをテストする場合、リソースの圧縮バージョンと非圧縮バージョンの両方をチェックするように構成されているものがあることを考慮する必要があります。 このチェックにより、応答時間がわずかに長くなります。

2. SSL

CDNは中間者です。 HTTPSトラフィックの整理と、サーバーへの送信方法について考える必要があります。 多くのCDNは要求をsomesite.com/assetからsomesite.com/assetにリダイレクトします。したがって、サーバーのロジックがプロトコルに依存している場合は、ロジックを変更するか、CDNにHTTPSにリダイレクトするように依頼します。

動的コンテンツはどうですか？

通常、この場合、cache-control：no-cacheを設定して、CDNがキャッシュしないようにする必要があります。 彼の仕事を少しスピードアップする方法に興味があるなら、読み続けてください。



典型的な動的コンテンツ

HTTP/1.1 200 OK Server: Apache X-Rack-Cache: miss ETag: "e6811cdbcedf972c5e8105a89f637d39-gzip" Status: 200 Content-Type: text/html; charset=utf-8 Expires: Mon, 29 Apr 2013 21:44:55 GMT Cache-Control: max-age=0, no-cache, no-store Pragma: no-cache Date: Mon, 29 Apr 2013 21:44:55 GMT
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ほとんどの動的コンテンツはそれほど一貫していません。 たとえば、アクティブなユーザーのリストの有効期間は10〜20秒です。 チャートページはおそらく数分間表示されます。 フィードは、特にetagを使用してしばらくキャッシュできます。 サイトの負荷が高い場合、しばらくの間リソースの一部をキャッシュしてみる価値があります。

キャッシュ時間分析

それでは、リソースを設定するのに最適な時期は何ですか？ トラフィックの量、リソースのサイズ、キャッシュのサイズに依存します。



さらに、キャッシングの主な欠点、つまりリソー​​スの制御の低下を考慮する必要があります。 リソースをすぐに更新する必要がある場合、1年前に彼に尋ねると問題が発生します。 特に、この時間をCDN（s-maxage）だけでなく、ユーザー（max-age）にも設定した場合。



キャッシュの最長期間は1年、つまり31536000です。しかし、これは悪い考えです。 顔にタトゥーを入れるようなものです。 サーバーが、リソースが変更されたかどうかに関するCDNからの少なくとも毎日の要求に耐えられない場合は、サーバーを変更する時が来ました。



静的コンテンツヘッダー

 HTTP/1.1 200 OK Cache-Control: no-transform,public,max-age=300,s-maxage=900 Content-Type: text/html; charset=UTF-8 Date: Mon, 29 Apr 2013 16:38:15 GMT ETag: "bbea5db7e1785119a7f94fdd504c546e" Last-Modified: Sat, 27 Apr 2013 00:44:54 GMT Server: AmazonS3 Vary: Accept-Encoding X-Cache: HIT
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

S3を使用した静的コンテンツのキャッシュ設定の例。 キャッシュには、ユーザープログラムの場合は300秒-リソースを900秒間保存することをお勧めします。 最後の見出しは、どのCDNがリクエストを処理したかを示しています。



「1年間リソースをキャッシュしない」コマンドの例外、または長いキャッシュの問題を回避するための1つのハック。 新しいバージョンをリリースするたびにリソースの名前を変更できます。 増加するバージョン番号、一時的なラベル、ハッシュを名前に追加できます。



次の表にキャッシュ損失を示します。 リソースが1分間に500件のリクエストを受信すると仮定すると、さまざまなリソース保存時間オプションについて次の割合のキャッシュリクエストが取得されます。

キャッシュ時間（分）	キャッシュリクエストの割合	1時間あたりの元のリクエスト
1	99.8％	60
5	99.96％	12
20	99.99％	3
60	99.997％	1
86400	99.9998％	<1

キャッシュリクエストの何パーセントがあなたに合っていますか？ 通常、リソースの有効期間は60秒から60分です。 疑似動的コンテンツの場合、最大60秒の範囲でキャッシュ時間を設定できます。

CDNチェック

ヘッダーが期待どおりにCDNを通過することを確認します。 通常、CDNはこのリソースの詳細を示す何らかのXヘッダーを挿入します。 ここに、私にとって非常に役立つと思われるいくつかのツールがあります。

1. Webインスペクター

最も簡単な方法は、Chromeでページを右クリックし、[要素の検査]を選択し、[ネットワーク]タブに移動して、HTMLリソースをクリックすることです。 これがデフォルトで選択されていない場合は、[ヘッダー]タブを選択してすべてのヘッダーを表示します。 Chromeには、ユーザーエージェントを設定し、ローカルキャッシュを使用しない機能もあります。

2. チャールズプロキシ

このようなプロキシを介して、トラフィックをリダイレクトし、DNSクエリを操作し、ヘッダーを記録し、パフォーマンス統計を見ることができます-これらはすべてわかりやすくシンプルなGUIで行います。

3.cURL

コマンドラインから要求を行い、応答ヘッダーを表示します。 便利なキー：-Aユーザーウィジェットの表示、-b-Cookie、-F-フォームデータ、-H-ヘッダーの割り当て、-I-リクエストヘッダーのみ。

4. hurl.it

大まかに言って、これは明確なインターフェースを持つcURLです。 ヘッダーを設定し、応答ヘッダーと応答本文を表示できます。

5. Pythonとリクエスト

Requestsは、Webリクエスト用のPythonライブラリです。 その助けを借りて、サイトの自動テストを作成できます。

マージンノート

これでガイド全体を読んだので、いくつかの注意事項があります。



ApacheやNginxなど、ほとんどのWebサーバーがほとんどの作業を行います。 cache-controlヘッダーを操作するだけです。 ブラウザは通常、コンテンツの強力なキャッシュ用に構成されているため、多くの場合、他の方法よりも過剰なキャッシュに対処する必要があります。 通常、300秒などのある程度の時間キャッシュする「/ static」などのパスを指定します。 次に、「cache-control：no-cache」という見出しでルートパス「/」を指定する必要がありますが、動的コンテンツのユーザーをサーバーに直接リダイレクトし、「/ static」にあるもののみをCDNに残すことをお勧めします。



通常、CDNには、ヘッダーに関係なく、必要に応じてキャッシングルールとキャッシュを解除する機能があります。 また、プロトコルを非常に自由に扱うことが多いため、CDNサーバーが提供するものをテストし、サーバーのヘッダーと比較することが非常に重要です。



サイトを高速化するための追加資料については、 モバイルWebパフォーマンスのドキュメントを参照することをお勧めします。