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

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?

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.

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.

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

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

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.

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.

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.

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.

se eu me lembro bem

• O gzip comprimirá um pouco mais do que desinflar
• desinflar é mais eficiente