Por que usar deflate em vez de gzip para arquivos de texto servidos pelo Apache?

215

Quais as vantagens oferecidas por qualquer método para arquivos html, css e javascript servidos por um servidor LAMP. Existem alternativas melhores?

O servidor fornece informações para um aplicativo de mapa usando o Json, para um alto volume de arquivos pequenos.

Consulte também Existe algum problema de desempenho envolvido na escolha de gzip sobre deflate para compactação http?

Ken
fonte
comutada respostas aceitas ... o consenso atual é de dois para um em favor de gzip
Ken
1
mod_deflate é para o Apache 2, mod_gzip é para o Apache 1.3.
SPRBRN

Respostas:

315

Por que usar deflate em vez de gzip para arquivos de texto servidos pelo Apache?

A resposta simples é não .


O RFC 2616 define deflate como:

deflate O formato "zlib" definido na RFC 1950 em combinação com o mecanismo de compactação "deflate" descrito na RFC 1951

O formato zlib é definido no RFC 1950 como:

     0   1
     +---+---+
     |CMF|FLG|   (more-->)
     +---+---+

       0   1   2   3
     +---+---+---+---+
     |     DICTID    |   (more-->)
     +---+---+---+---+

     +=====================+---+---+---+---+
     |...compressed data...|    ADLER32    |
     +=====================+---+---+---+---+

Assim, alguns cabeçalhos e uma soma de verificação ADLER32

O RFC 2616 define o gzip como:

gzip Um formato de codificação produzido pelo programa de compactação de arquivos "gzip" (GNU zip), conforme descrito na RFC 1952 [25]. Este formato é uma codificação Lempel-Ziv (LZ77) com um CRC de 32 bits.

A RFC 1952 define os dados compactados como:

Atualmente, o formato usa o método DEFLATE de compactação, mas pode ser facilmente estendido para usar outros métodos de compactação.

CRC-32 é mais lento que ADLER32

Comparado a uma verificação de redundância cíclica do mesmo comprimento, troca confiabilidade por velocidade (preferindo o último).

Então ... nós temos 2 mecanismos de compactação que usam o mesmo algoritmo para compactação, mas um algoritmo diferente para cabeçalhos e soma de verificação.

Agora, os pacotes TCP subjacentes já são bastante confiáveis , portanto, o problema aqui não é o Adler 32 vs o CRC-32 que o GZIP usa.


Acontece que muitos navegadores ao longo dos anos implementaram um algoritmo de deflação incorreto. Em vez de esperar o cabeçalho zlib na RFC 1950, eles simplesmente esperavam a carga útil compactada. Da mesma forma, vários servidores web cometeram o mesmo erro.

Assim, ao longo dos anos, os navegadores começaram a implementar uma implementação de deflação de lógica fuzzy , eles tentaram o cabeçalho zlib e a soma de verificação do adler, se isso falhar, tentaram a carga útil.

O resultado de ter uma lógica complexa como essa é que ela geralmente é quebrada. O Verve Studio possui uma seção de teste com contribuição do usuário que mostra o quão ruim é a situação.

Por exemplo: deflate funciona no Safari 4.0, mas está quebrado no Safari 5.1, mas também sempre apresenta problemas no IE.


Portanto, a melhor coisa a fazer é evitar o esvaziamento completo, o pequeno aumento de velocidade (devido ao adler 32) não vale o risco de cargas úteis quebradas.

Sam Saffron
fonte
Não deveria haver um novo padrão que combine adler32 com gzip?
Pacerier
1
@ Sam Saffron, isso significa que se o navegador da web não estiver na imagem, posso usar o deflate sobre o gzip? Por exemplo, se eu vou carregar um arquivo compactado no meu servidor FTP.
Xegara #
1
Outra diferença muito pequena é que o wrapper zlib tem seis bytes vs. 18 bytes para o gzip. Portanto, para pacotes muito pequenos, pode haver uma vantagem em enviar 12 bytes a menos. A conclusão não muda, no entanto, que é porque a Microsoft estragou tudo para todos ao interpretar mal o que "desinflar" significava no que eles entregaram em seus servidores IIS, é mais fácil usar apenas o formato gzip.
Mark Adler
Mas como a carga útil poderia ser quebrada, se é transmitida usando TCP? Toda a idéia do TCP é transmitir cargas úteis ininterruptas.
user1095108
Essa resposta data de 2012. Então, os navegadores modernos ainda sofrem com o problema da implementação incorreta dos algoritmos de esvaziamento ou é seguro usá-lo agora? Essa parte da resposta ainda está atualizada?
Ihebiheb
172

O GZip é simplesmente vazio, mais uma soma de verificação e cabeçalho / rodapé. Desinflar é mais rápido , porém, como aprendi da maneira mais difícil.

gráfico gzip vs deflate

Jeff Atwood
fonte
13
Sem mencionar que o zlib não tem suporte para a extensão e, mesmo que tivesse, a instrução CRC32 no SSE 4.2 usa o polinômio 1EDC6F41, e o formato gzip usa o polinômio EDB88320 - algoritmos totalmente diferentes, efetivamente.
21411 Jack Lloyd
7
E como o desinflar é mais rápido, por que o SO está usando o gzip?
David Murdoch
40
Bem, esta resposta está incorreta ... consulte: zoompf.com/blog/2012/02/lose-the-wait-http-compression ... em particular, o cliente tem 2 maneiras de "interpretar" o esvaziamento, sem cabeçalho / checksumless e com cabeçalho zlib. A implementação nos navegadores de um deflate correto é ruim. desinflar deve ser evitado.
Sam Saffron
4
@sam Além disso, acabei de executar novamente os benchmarks e, em um chip Intel moderno, obtenho o gzip 1441/692 e esvazio o 1286/531. O segundo número é descomprimido, o primeiro é compactação. Para que o esvaziamento seja ainda mais rápido, seus benchmarks mostram o contrário? (Concordo que pode não ser útil para outras razões, mas a resposta está correta , deflate é mais rápido ..)
Jeff Atwood
6
@JeffAtwood mas a pergunta não foi mais rápida?
Ken
16

É provável que você não consiga realmente escolher o esvaziamento como uma opção. Ao contrário do que você pode esperar, mod_deflate não está usando deflate, mas gzip. Portanto, embora a maioria dos argumentos apresentados seja válida, provavelmente não é relevante para a maioria.

Amblyopius
fonte
4

Eu acho que não há grande diferença entre deflate e gzip, porque basicamente o gzip é apenas um cabeçalho envolvido em deflate (consulte RFCs 1951 e 1952).

schnaader
fonte
3

O principal motivo é que a deflação é mais rápida de codificar do que o gzip e em um servidor ocupado que pode fazer a diferença. Com páginas estáticas, é uma pergunta diferente, pois elas podem ser pré-compactadas facilmente uma vez.

Joachim Sauer
fonte
presumivelmente com o gzip, você não pode começar a transmitir o cabeçalho até obter, armazenar e compactar todos os dados? (porque você precisa da soma de verificação para criar o cabeçalho)
OJW
8
No formato gzip, a soma de verificação vem no final do arquivo, especificamente para que se possa começar a escrever blocos de desinfecção à medida que são processados ​​sem ter que segurar tudo.
Jack Lloyd
2

mod_deflate requer menos recursos em seu servidor, embora você possa pagar uma pequena penalidade em termos de quantidade de compactação.

Se você estiver servindo muitos arquivos pequenos, recomendo fazer testes comparativos e de carga de suas soluções compactadas e descompactadas - você pode encontrar alguns casos em que ativar a compactação não resultará em economia.

Dave R.
fonte
Para quem está se perguntando, com deflate meus arquivos de texto vão de 30 KB a 10 KB - portanto, os arquivos precisam ser ainda menores que isso para que não haja economia. Estou supondo menos de 1 KB ou algo semelhante.
Hextech
0

Não deve haver nenhuma diferença no gzip & deflate para descompressão. O Gzip é apenas vazio, com algumas dezenas de bytes de cabeçalho em volta, incluindo uma soma de verificação. A soma de verificação é o motivo da compactação mais lenta. No entanto, quando você está pré-compactando zilhões de arquivos, deseja essas somas de verificação como uma verificação de integridade no seu sistema de arquivos. Além disso, você pode utilizar ferramentas de linha de comando para obter estatísticas sobre o arquivo. Para o nosso site, estamos pré-compactando uma tonelada de dados estáticos (todo o diretório aberto, 13.000 jogos, preenchimento automático para milhões de palavras-chave etc.) e somos classificados 95% mais rápido que o Alexa. Pesquisa Faxo. No entanto, utilizamos um servidor Web proprietário desenvolvido em casa. O Apache / mod_deflate simplesmente não cortou. Quando esses arquivos são compactados no sistema de arquivos, você não apenas acerta o seu arquivo com o tamanho mínimo do bloco do sistema de arquivos, mas toda a sobrecarga desnecessária no gerenciamento do arquivo no sistema de arquivos com o qual o servidor da web não se importa. Suas preocupações devem ser a pegada total do disco e o tempo de acesso / descompressão e, em segundo lugar, acelerar a capacidade de obter esses dados pré-compactados. A área ocupada é importante porque, embora o espaço em disco seja barato, você deseja que o máximo possível caiba no cache.

Steven
fonte
O GZip provavelmente verifica a soma de verificação na descompressão, daí a diferença de velocidade na descompressão.
Seun Osewa 5/11/2009
-1

No Ubuntu com Apache2 e o módulo deflate já instalado (que é por padrão), você pode ativar a compactação gzip deflate em duas etapas fáceis:

a2enmod deflate
/etc/init.d/apache2 force-reload

E você está fora! Encontrei páginas que eu veiculava na minha conexão adsl carregadas muito mais rapidamente.

Edit: Conforme o comentário de @ GertvandenBerg, isso permite a compactação gzip, não desinflar.

aidan
fonte
6
Só que permite que gzip, uma vez mod_deflate confusamente implementos somente a compressão gzip ...
Gert van den Berg
@GertvandenBerg Eu atualizei a minha resposta, mas para o registro, gzip é desinflar, apenas com cabeçalhos extras e um checksum
Aidan
@aiden sim, mas a soma de verificação tem um impacto no desempenho ... (e desinflar crua não é compatível com padrão)
Gert van den Berg
-4

se eu me lembro bem

  • O gzip comprimirá um pouco mais do que desinflar
  • desinflar é mais eficiente
JimmyJ
fonte
2
O gzip é esvaziado com um cabeçalho. E HTTP 1.1 deflate é realmente zlib (que também é um invólucro em torno deflate)
David Murdoch