キャッシュコントロールヘッダーの制御について教えてください（私が書いたキャッシュ関数に影響します）

私は、処理のために etag とファイル キャッシュに依存して、PHP で制御されるキャッシュを自分で作成しました。
ブラウザーが etag を送信した場合、etag が一貫している場合は、それを比較し、etag が一貫していない場合は、304 を直接送信します。ファイルキャッシュがあり、直接 ファイルキャッシュを読み取り、現在のサーバーにキャッシュされたetagを送信します
(ファイルキャッシュとetagの更新は別の場所で処理されます)

ここで、304を返さずに応答があることに突然気づきましたチェックしたところ、このアドレスを持つサーバーが見つかりました。http 応答ヘッダーが、cache-control: no-cache
を返しました。サーバーのキャッシュをクリアしたところ、初めて応答するときにサーバーが自動的に no-cache ヘッダーを送信したことがわかりました。私の etag も送信されました) の場合、サーバー側にキャッシュがあるかどうかに関係なく、サーバー側が処理中に etag を受信しない場合、ブラウザはリクエスト ヘッダーに etag を追加しません。最初のリクエストを実行し、ファイルを再読み込みし、etag を再送信します... (応答 200)

これはおおよその内容ですが、これにより、必要な直接キャッシュの効果が失われます。 304を使用します。

違いを見ると、通常のデータ、約 10KB は正常に実行されています (キャッシュなしの最初のリクエストは 130 ミリ秒、キャッシュありの最初のリクエストは 90 ミリ秒、その後は 16 ミリ秒以下)
しかし、これは304 を送信しない場合 (常に (キャッシュなし送信)、データは 304B のみです (ただし、キャッシュ モジュールなしでも、サーバーの計算により約 90 ミリ秒かかります)。
データの返送が一貫していないことが原因でしょうか。この 304B データは 12KB に拡張され、キャッシュなしヘッダーは引き続き送信され、20kB への増加は同じです。

それから私は混乱しました...何が起こったのか分かりません。

(良心的、すべてのコードは私によって書かれており、1 つのヘッダー (etag) を除いて他の etag は一切送信されません)

ディスカッションへの返信 (解決策)

理由がわかりました...

理由は何ですか?
ノーキャッシュを送信し続けるのはなぜですか?おそらくサーバーの設定が原因だと思われます。

その理由は何ですか?
ノーキャッシュを送信し続けるのはなぜですか?おそらくサーバーの設定が原因だと思われます。

PHP のセッション制限の理由