Qual é a melhor maneira de compactar back-end para os dados do proxy reverso nginx?

3

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.

    
por anonymous-one 22.08.2012 / 13:05

2 respostas

2

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";
    
por 23.08.2012 / 07:26
0
  1. link - a versão de solicitação HTTP necessária para o gzip compactar as respostas no back-end é por padrão 1.1.

  2. 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.

    
por 28.07.2017 / 17:02