私は本を読んでいて、ETag の章について特定の質問があります。著者は、ETag はパフォーマンスに悪影響を及ぼす可能性があり、細かく調整するか、完全に無効にする必要があると述べています。
ETag とは何か、リスクについては理解していますが、ETag を正しく取得するのは難しいですか?
値が応答本文の MD5 ハッシュである ETag を送信するアプリケーションを作成しました。これはシンプルなソリューションであり、多くの言語で簡単に実現できます。
応答本文の MD5 ハッシュを ETag として使用するのは間違っていますか? もしそうなら、なぜですか？
なぜ著者 (明らかに何桁も私を裏切っている) は、そのような単純な解決策を提案しないのでしょうか?
この最後の質問は、あなたが作成者でない限り答えるのが難しい :) ので、MD5 ハッシュを ETag として使用することの弱点を見つけようとしています。
ETag は Last-Modified ヘッダーに似ています。クライアントによる変更を決定するメカニズムです。
ETag は、リソースの状態と特定の形式を表す一意の値である必要があります (リソースには、それぞれ独自の ETag を必要とする複数の形式が含まれる場合があります)。リソースのドメイン全体で一意ではなく、単にリソース内で一意です。
現在、技術的には、ETag は Last-Modified ヘッダーと比較して「無限」の解像度を持っています。Last-Modified は 1 秒単位でのみ変更されますが、ETag は 1 秒未満になる可能性があります。
ETag と Last-Modified の両方を実装することも、どちらか一方だけを実装することもできます (もちろん、何も実装しないこともできます)。Last-Modified だけでは不十分な場合は、ETag を検討してください。
「すべての」リソースに ETag を設定しないことに注意してください。基本的に、キャッシュされることを期待していないもの (特に動的コンテンツ) には設定しません。その場合は意味がありません。無駄な作業です。
編集：あなたの編集を見て、明確にします。
MD5は大丈夫です。唯一の欠点は、常に MD5 を計算することです。たとえば、200K の PDF ファイルで MD5 を実行すると、コストがかかります。キャッシュされることを期待していないリソースで MD5 を実行するのは、単に無駄です (つまり、動的コンテンツ)。
秘訣は、使用するメカニズムが何であれ、Last-Modified と同じくらい安価であるべきだということです。Last-Modified は、通常、リソースのプロパティであり、通常はアクセスが非常に安価です。
ETag も同様に安価である必要があります。MD5 を使用していて、リソースと MD5 ハッシュの間の関連付けをキャッシュ/保存できる場合、それは優れたソリューションです。ただし、ETag が必要になるたびに MD5 を再計算することは、基本的に ETag を使用してサーバー全体のパフォーマンスを向上させるという考えに反します。
instela の動的コンテンツに etags を使用しています。
私たちの戦略は、送信するコンテンツの md5 ハッシュを生成する出力の最後にあり、if-none-match ヘッダーが存在する場合は、ヘッダーを生成されたハッシュと比較します。2 つの値が同じ場合、304 コードを送信し、コンテンツを返さずにリクエストを中断します。
コンテンツをハッシュするために少し CPU を消費するのは事実ですが、最終的には帯域幅を大幅に節約しています。
ユーザーごとに異なるコンテンツを持つ Facebook ニュースフィード スタイルのメイン ページがあります。ニュースフィードのコンテンツは 1 時間に 3 ～ 4 回しか変更されないため、メイン ページの更新はクライアント側にとって非常に効率的です。モバイル時代では、帯域幅を費やすよりも CPU 時間をもう少し多く費やす方がよいと思います。帯域幅は依然として CPU よりも高価ですが、クライアントにとってはより優れたエクスペリエンスです。
この本を読んでいないので、著者の正確な懸念について話すことはできません.
ただし、ETag の生成は、ページが変更されたときに ETag が 1 回だけ生成されるようにする必要があります。Web ページの MD5 ハッシュを生成するには、サーバーの処理能力と時間がかかります。多くのクライアントが接続している場合、パフォーマンスの問題が発生する可能性があります。
したがって、必要な場合にのみETag を生成し、関連するページが変更されるまでそれらをサーバーにキャッシュするための優れた手法が必要です。
ETAGSperceived problemを使用すると、ブラウザがページ上のすべてのリソースに対して (単純で小さい) 要求/応答を発行して解析し、etag 値がサーバー側で変更されたかどうかを確認する必要があると思います。
個人的には、頻繁に変更される画像、css、javascript (ブラウザの etag が最新の場合、サーバーはコンテンツを再送信する必要はありません) に対しては、サーバーへのこれらの非常に小さなラウンドトリップが許容できると思います。このメカニズムにより、「更新された」コンテンツをマークするのが非常に簡単になるからです。