インターネット経由でバックエンドからデータをプルするnginxリバースプロキシを実行します。
インターネット経由で意味するのは、バックエンドマシンは、前面がリバースプロキシに面しているLAN上にはないということです。
これらのリクエストをインターネット経由で送信する前に把握しておくとよいと考えていました。
私の見方では、次のように機能するはずです。
クライアントは、accept-encodingヘッダーまたはgzipを使用してコンテンツを要求します。
リバースプロキシはこれをバックエンドサーバーに送信します。
Gzipのacceptエンコーディングヘッダーが送信されたため、バックエンドはこのコンテンツを圧縮します。
リクエストは圧縮されたチェーンのずっと上に送信されました。
これは、私たち全員が非常に簡単にできることです。私が持っている質問は、nginxリバースプロキシ側でgzip圧縮を有効にした場合、これはどのように機能するのでしょうか?
Nginxはすでにgzip圧縮されているコンテンツをgzip圧縮しようとしますか?
これが理にかなっていることを願っています。ありがとうございました。
更新1:
すでにgzip圧縮されたコンテンツ(およびこのサービング)をキャッシュすることの意味を理解しています。キャッシュキーを変更して、acceptエンコーディングヘッダーを含め、ユーザーエージェントが受け入れることができる内容に応じて、適切に圧縮/非圧縮されたコンテンツを提供(およびキャッシュ)します。
いいえ、リバースプロキシとバックエンドサーバーでgzipを設定しても問題はありません。少なくとも私は何の問題もありませんでした。プロキシはすでにgzip圧縮されたコンテンツを認識し、単に配信します。
コンテンツをバックエンドからgzipで圧縮したい場合は、適切なヘッダーを追加するだけです。
proxy_set_header Accept-Encoding "gzip";
http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_http_version -gzipがバックエンドで応答を圧縮するために必要なHTTPリクエストのバージョンはデフォルトで1.1です。
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version -プロキシモジュールがデフォルトで使用するHTTPリクエストのバージョンは1.0です
これは、デフォルトでは、プロキシがバックエンドから要求すると、ブラウザのGET1.1要求がそれ自体をGET1.0要求に変換することを意味します。バックエンドはgzip圧縮を実行するために1.1を必要とするため、応答を圧縮しません。
私の提案は、リバースプロキシでproxy_http_version 1.1;
を使用し、バックエンドサーバーで標準のgzip on;
などの設定を使用することです。
これを最適化するには、さらに2つのことがあります。 1つは「gzip_static」(追加モジュール)の設定です。 'index.html'に対してリクエストが行われると、この設定は 'index.html.gz'ファイルが存在する場合はそれを検索して配信します。圧縮はオンザフライで実行されないため、これはCPU使用率にプラスの影響を与えます。
質問の他の部分については、実際に圧縮されるものはgzip_typesオプションで設定されます。デフォルトでは、text/htmlのみが圧縮されます。 gzipファイルがある場合は、それらを除外するように注意する必要があります。 *
オプション(すべてを圧縮)を使用すると、圧縮ファイルも送信前にgzipで圧縮されます。ほとんどの画像(jpg、png、gif)には、ある種のLZW圧縮レイヤーが既に実装されているため、これは最適ではありません。したがって、圧縮ファイルを圧縮すると、サイズがわずかに減少するか、さらには増加するだけですが、圧縮を実行するために大量のCPUリソースが使用されます。要求の頻度と要求されたコンテンツのタイプ(または圧縮率)に基づいて、圧縮する対象を慎重に検討する必要があります。画像に関しては、gzip圧縮をオンにするよりも、追加のツール(optipngなど)を使用して画像を最適化する方が効果的です。