gzip_proxiedディレクティブのオプションは何ですか？
gzip_proxied ディレクティブでは、次のオプションを使用できます（網羅的ではありません）。
- 期限切れ
応答ヘッダーにキャッシュを無効にする値を持つ「Expires」フィールドが含まれている場合、圧縮を有効にします。- キャッシュなし
応答ヘッダーに「no-cache」パラメーターを持つ「Cache-Control」フィールドが含まれている場合、圧縮を有効にします。- no-store
応答ヘッダーに「no-store」パラメーターを含む「Cache-Control」フィールドが含まれている場合、圧縮を有効にします。- private
応答ヘッダーに「private」パラメーターを持つ「Cache-Control」フィールドが含まれている場合、圧縮を有効にします。- no_last_modified
応答ヘッダーに「Last-Modified」フィールドが含まれていない場合に圧縮を有効にします。- no_etag
応答ヘッダーに「ETag」フィールドが含まれていない場合に圧縮を有効にします。- auth
リクエストヘッダーに「Authorization」フィールドが含まれている場合、圧縮を有効にします。
これらのオプションのほとんどを使用する合理的な理由はわかりません。たとえば、プロキシされたリクエストにAuthorizationヘッダーまたはCache-Control: privateが含まれているかどうかが、gzipで圧縮するかどうかに影響するのはなぜですか。
古いバージョンのNginx gzipで圧縮するときに応答からETagを取り除く を考えると、no_etagのユースケースを見ることができます： gzip圧縮された応答のETagを生成するようにNginxを構成していない場合は、ETagなしで圧縮された応答を生成するよりも、圧縮されていない応答を渡す方がよい場合がありますwith ETag。
しかし、私は他の人を理解することはできません。
これらの各オプションの使用目的は何ですか？
管理ガイド から:(私の強調）
ディレクティブには、NGINXが圧縮するプロキシリクエストの種類を指定するいくつかのパラメータがあります。たとえば、プロキシサーバーにキャッシュされないリクエストに対してのみ応答を圧縮するのが妥当です。この目的のために、gzip_proxiedディレクティブには、応答のCache-Controlヘッダーフィールドをチェックし、値がno-cache、no-store、またはprivateの場合に応答を圧縮するようにNGINXに指示するパラメーターがあります。さらに、Expiresヘッダーフィールドの値を確認するには、expiredパラメーターを含める必要があります。これらのパラメーターは、Authorizationヘッダーフィールドの存在をチェックするauthパラメーターとともに次の例で設定されます（承認された応答はエンドユーザーに固有であり、通常はキャッシュされません）
キャッシュ可能な応答を圧縮しないことが合理的であることに同意します。プロキシでのキャッシュの主な節約は、パフォーマンス（応答時間）を向上させ、プロキシがアップストリームリソースの要求に費やす時間と帯域幅を削減することであると考えてください。これらのパフォーマンス上の利点を得るためのトレードオフは、キャッシュストレージのコストです。キャッシュ可能な応答を圧縮しないことが理にかなっているいくつかのユースケースを次に示します。
多くのサイトの通常のWebトラフィックでは、パーソナライズされていない応答（キャッシュ可能な応答の大部分を構成します）は、Webビルドでスクリプトの縮小、画像サイズの最適化などの手法によってすでに最適化されています処理する。これらの静的リソースは圧縮によってわずかに縮小する可能性がありますが、gzipで圧縮しようとするCPUコストは、プロキシレイヤーマシンリソースを効率的に使用できない可能性があります。ただし、ログインユーザーに提供され、アプリケーションで生成された大量のコンテンツを含む動的に生成されたページは、圧縮の恩恵を受ける可能性が非常に高くなります（通常はキャッシュできません）。
コストのかかるアップストリームサービスの前にプロキシを設定していますが、別のプロキシへの応答を提供する各ユーザーエージェントの圧縮を担当します。たとえば、（地理的に離れたエッジの場所から）同じコストのかかるアップストリームリソースに複数のリクエストを行うCDNがあり、コストのかかる応答を再利用できるようにしたい場合です。 CDNが非圧縮バージョンをキャッシュする場合（圧縮ユーザーエージェントと非圧縮ユーザーエージェントの両方にサービスを提供するため）、プロキシで圧縮してCDNで再度解凍する場合があります。これは、両側のハードウェアと電力の浪費であり、帯域幅を削減します。チェーンの最も高い帯域幅の部分。 （応答gzip圧縮は、ラストワンマイルで最も有益です。ユーザーの電話に応答データを取得します。ユーザーの電話は、地下鉄に入るときに1ドットの信号に低下します。）
サイズの大きい応答エンティティの場合、リソースのバイト範囲に対する要求が（さまざまなユーザーエージェントから、多くの場合はダウンストリームCDN仲介者を介して）、圧縮をサポートしないユーザーエージェントに送信される場合があります。 CDNは、非圧縮バージョンがすでにキャッシュにある場合、独自のキャッシュからバイト範囲要求を処理する可能性があります。