nginx: o gzip no servidor é perdido durante o proxy

Question

Usando o nginx como um proxy reverso / balanceador de carga na frente dos servidores de aplicativos iis / .NET.

Nossos servidores são configurados para gzip payloads de resposta. Funciona bem.

Quando colocamos o gzip na frente, as respostas não são mais compactadas.

Pergunta 1: Precisamos reconfigurar o gzip no nginx?

Pergunta 2: É apropriado fazer o trabalho gzip duas vezes?

• nginx passa a solicitação para o servidor da web
• resposta dos gzips do servidor web
• (eu acho) nginx descompacta resposta, re-gzips resposta

Qual é a coisa certa a fazer aqui?

(Eu sinto que o gzip deve acontecer apenas em uma camada, embora haja uma vantagem de reduzir a carga no fio, mesmo atrás do nginx).

Aqui estão os meus parâmetros de configuração atuais para o gzip (na seção http, antes do primeiro bloco upstream)

# ******************************  begin gzip section ********************
# Compression 
gzip on;     # Enable Gzip compressed.

# Enable compression both for HTTP/1.0 and HTTP/1.1.
gzip_http_version  1.1;

# Compression level (1-9).
# 5 is a perfect compromise between size and cpu usage, offering about
# 75% reduction for most ascii files (almost identical to level 9).
gzip_comp_level    5;

# Don't compress anything that's already small and unlikely to shrink much
# if at all (the default is 20 bytes, which is bad as that usually leads to
# larger files after gzipping).
gzip_min_length    1000;

# Compress data even for clients that are connecting to us via proxies,
# identified by the "Via" header (required for CloudFront).
gzip_proxied       any;

# Tell proxies to cache both the gzipped and regular version of a resource
# whenever the client's Accept-Encoding capabilities header varies;
# Avoids the issue where a non-gzip capable client (which is extremely rare
# today) would display gibberish if their proxy gave them the gzipped version.
gzip_vary          on;

# Compress all output labeled with one of the following MIME-types.
# text/html is always compressed by HttpGzipModule
gzip_types
    text/css
    text/*
    text/javascript
    message/*
    application/x-javascript
    application/json
    application/xml
    application/atom+xml
    application/xaml+xml;
# ******************************  end gzip section ********************

    

Answer 1

Isso provavelmente se deve à versão HTTP em que o IIS está executando o gzip.

O proxy Nginx faz solicitações de backend por padrão pelo HTTP 1.0. A maioria dos navegadores neste momento usa o HTTP 1.1.

Não tenho certeza sobre o IIS, mas o nginx executa o gzip no HTTP 1.1.

Assim, sem o proxy no meio, a solicitação provavelmente está chegando ao backend pelo HTTP 1.1. Com o proxy no meio, o pedido está atingindo o backend no HTTP 1.0.

Tente definir proxy_http_version 1.1 no seu servidor proxy. Isso enviará solicitações de backend pelo HTTP 1.1.

Você só deve gzip uma vez. Em geral, é melhor fazê-lo no aplicativo real (como você está fazendo) para que a resposta gzipped possa ser armazenada em cache por camadas de cache downstream etc. O desenvolvedor do aplicativo deve determinar se o gzip seria ou não benéfico sobre o tamanho da resposta, se é compressível, etc). Então, eu recomendaria desativar o gzip no seu proxy.