Vamos executar um proxy reverso nginx que irá extrair dados de um backend pela Internet.
O que queremos dizer com a Internet é que a máquina de back-end não estará em uma lan com a frente voltada para o proxy reverso.
Pensamos que seria interessante aceitar esses pedidos antes de enviá-los pela Internet.
Do jeito que eu vejo, deve funcionar algo assim:
O cliente solicita conteúdo com um cabeçalho de aceitação de codificação ou gzip.
O proxy reverso envia isso para o servidor backend.
Backend comprime este conteúdo, já que um cabeçalho de codificação de aceitação do gzip foi enviado.
Solicitação enviada até a cadeia comprimida.
Isso tudo pode ser feito de maneira direta. A pergunta que tenho é como isso funcionará se tivermos a compactação gzip ativada no lado do proxy reverso nginx?
O nginx tentará gzipar conteúdo que já tenha sido compactado?
Espero que isso faça sentido. Obrigado.
UPDATE 1:
Eu entendo as implicações do cache de conteúdo já gzipped (e desta veiculação). Modificamos a chave de cache para incluir o cabeçalho de codificação de aceitação e, assim, servir (e armazenar em cache) o conteúdo corretamente compactado / descompactado de acordo com o que o agente do usuário pode aceitar.
Não, não há problema com a configuração do gzip no proxy reverso e no servidor backend. Pelo menos eu nunca tive problemas. O proxy irá reconhecer o conteúdo já gzipado e simplesmente entregá-lo.
Se você quiser que qualquer conteúdo seja compactado a partir do back-end, simplesmente adicione o cabeçalho apropriado.
proxy_set_header Accept-Encoding "gzip";
link - a versão de solicitação HTTP necessária para o gzip compactar as respostas no back-end é por padrão 1.1.
link - a versão de solicitação HTTP usada por padrão pelo módulo proxy é 1,0
Isso significa que, por padrão, a solicitação GET 1.1 do navegador se transforma em uma solicitação GET 1.0 quando o proxy a solicita do back-end. O back-end precisa 1.1 para executar a compactação gzip e, portanto, não compacta a resposta.
Minha sugestão é usar proxy_http_version 1.1; no proxy reverso e as configurações padrão gzip on; etc. no servidor back-end.
Há duas coisas adicionais para otimizar isso. Uma é a configuração de 'gzip_static' (um módulo extra). Quando uma solicitação é feita para 'index.html', essa configuração procura e entrega um arquivo 'index.html.gz', se existir. Isso tem um impacto positivo no uso da CPU, já que a compactação não é executada em tempo real.
Quanto à outra parte da sua pergunta, o que realmente é compactado é definido com a opção gzip_types. Por padrão, somente texto / html é compactado. Se você tiver arquivos gzip, tenha cuidado para excluí-los. Se você usar a opção * (compactar tudo), os arquivos compactados também serão compactados com gzip antes de serem enviados. Isso não é ideal para a maioria das imagens (jpg, png, gif), pois elas têm algum tipo de camada de compactação LZW já implementada. A compactação de um arquivo compactado resulta, portanto, apenas em uma pequena diminuição ou até mesmo em um aumento de tamanho, enquanto utiliza recursos significativos da CPU para realizar a compactação. Você deve examinar cuidadosamente o que deseja compactar com base na frequência de solicitações e no tipo de conteúdo solicitado (ou sua taxa de compactação). Em termos de imagens, otimizá-las com ferramentas extras (optipng, etc.) é mais eficaz do que ativar a compactação gzip.