Gzip: o que é, de onde veio e por que ele é essencial na comunicação HTTP

Se você já configurou um servidor web ou analisou os headers de uma requisição HTTP, provavelmente já viu a palavra gzip aparecendo em algum lugar. Neste post, vamos entender em profundidade o que é o gzip, como o algoritmo funciona por dentro, sua origem (bem anterior à web como conhecemos hoje), como ele se encaixa no protocolo HTTP, seus trade-offs, implicações de segurança, e por que ele continua sendo uma das otimizações de performance mais importantes na internet.

O que é o Gzip

Gzip é um formato de compressão de dados — um algoritmo que reduz o tamanho de um arquivo removendo redundâncias, de forma que ele possa ser reconstruído exatamente igual ao original depois. É importante destacar: gzip é uma compressão sem perdas (lossless). Isso é bem diferente, por exemplo, da compressão de uma imagem JPEG, que descarta informação visual permanentemente em troca de um arquivo menor. Com gzip, o dado descomprimido é byte a byte idêntico ao original.

Como o algoritmo funciona por dentro

O gzip usa um algoritmo chamado DEFLATE, que combina duas técnicas complementares:

1. LZ77 (Lempel-Ziv 77)

Essa técnica procura por trechos de dados que se repetem dentro do próprio arquivo e substitui as repetições por referências curtas a ocorrências anteriores. Por exemplo, num arquivo HTML cheio de tags como <div class="container"> repetidas várias vezes, o LZ77 identifica essa repetição e, em vez de gravar o texto inteiro de novo a cada ocorrência, grava algo como "volte X bytes atrás e copie Y bytes daqui" — uma referência muito mais compacta que o texto original.

2. Codificação de Huffman

Depois que o LZ77 já reduziu as repetições, a codificação de Huffman entra numa segunda etapa: ela analisa a frequência de cada símbolo (caractere, byte) no resultado e atribui códigos binários mais curtos pros símbolos mais frequentes e códigos mais longos pros símbolos raros. Isso é o mesmo princípio usado no código Morse, por exemplo — letras comuns como "E" têm um código curtíssimo, enquanto letras raras como "Q" têm código mais longo.

A combinação dessas duas técnicas é o que forma o DEFLATE — e esse mesmo algoritmo, aliás, é a base do formato .zip também. Ou seja, gzip e zip são "primos" tecnicamente, usando o motor de compressão por baixo.

A origem: nada a ver com a web

Uma curiosidade importante: o gzip não nasceu pensado pra internet. Ele foi criado em 1992, por Jean-loup Gailly e Mark Adler, como parte do projeto GNU (o mesmo ecossistema de software livre que originou ferramentas fundamentais do Linux), com um objetivo bem específico: ser um substituto livre do utilitário compress do Unix.

O compress usava um algoritmo chamado LZW (Lempel-Ziv-Welch), que na época estava sob patente comercial ativa (detida pela Unisys). Isso gerava restrições legais reais para uso e distribuição — softwares que implementassem LZW podiam, em teoria, precisar pagar royalties. O gzip surgiu justamente como alternativa aberta e sem essas amarras, focado em compactar arquivos comuns no sistema operacional:

gzip arquivo.txt        # gera arquivo.txt.gz, remove o original
gzip -k arquivo.txt     # mantém o arquivo original também
gunzip arquivo.txt.gz   # descompacta de volta
gzip -9 arquivo.txt     # compressão máxima (mais lenta, arquivo menor)
gzip -1 arquivo.txt     # compressão mínima (mais rápida, arquivo maior)

Nessa época, gzip era simplesmente um comando de terminal usado por administradores de sistema. A web comercial mal existia ainda — o primeiro navegador gráfico popular (Mosaic) só apareceria em 1993, e o HTML mal tinha um ano de existência.

Como o gzip "migrou" para o protocolo HTTP

Com o crescimento da web ao longo dos anos 90, um problema ficou evidente: páginas HTML, arquivos de estilo e scripts trafegavam pela rede como texto puro, ocupando mais banda do que precisavam. E conexões de internet da época eram muito mais lentas e caras — boa parte dos usuários ainda se conectava via modem discado, com velocidades de 14.4kbps a 56kbps (pra efeito de comparação, isso é milhares de vezes mais lento que uma conexão de fibra óptica comum hoje). Nesse contexto, cada kilobyte economizado fazia diferença perceptível no tempo de carregamento de uma página.

A solução natural foi aproveitar um formato de compressão que já existia havia anos e era amplamente testado e confiável: o gzip. Mas pra isso funcionar dentro do HTTP, era preciso um mecanismo pelo qual cliente e servidor negociassem se a compressão seria usada ou não — afinal, nem todo navegador (especialmente os mais antigos) sabia descomprimir gzip, e enviar dados comprimidos pra um cliente que não entende isso quebraria a comunicação completamente.

A negociação de conteúdo

O HTTP resolveu esse problema com dois headers específicos, parte de um mecanismo mais amplo chamado negociação de conteúdo (content negotiation):

• Accept-Encoding: o cliente (navegador) envia esse header na requisição, dizendo quais formatos de compressão ele é capaz de entender e descomprimir
• Content-Encoding: o servidor responde informando qual compressão foi de fato aplicada no conteúdo que está sendo enviado

Exemplo de uma troca completa entre navegador e servidor:

# O navegador envia, dizendo o que ele aceita
GET /pagina.html HTTP/1.1
Host: exemplo.com
Accept-Encoding: gzip, deflate, br

# O servidor responde, avisando que comprimiu com gzip
HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Content-Length: 3421
Vary: Accept-Encoding

[conteúdo comprimido em binário]

O navegador recebe o conteúdo comprimido, descomprime automaticamente em memória (isso é totalmente transparente pro usuário final) e renderiza a página normalmente, como se tivesse recebido o HTML original sem compressão nenhuma.

Repare também no header Vary: Accept-Encoding — ele existe pra avisar sistemas de cache intermediários (proxies, CDNs) que a resposta pode variar dependendo do que o cliente aceita, evitando que uma versão comprimida seja servida erroneamente pra um cliente que não suporta gzip (ou vice-versa).

Linha do tempo resumida

Um ponto importante aqui: o HTTP/1.1 não criou o gzip — ele apenas padronizou e estabilizou o mecanismo de negociação de compressão dentro do protocolo. O gzip, como algoritmo, já existia havia quase uma década antes disso. E o mecanismo de negociação continua presente e funcional em versões mais recentes do protocolo, como HTTP/2 e HTTP/3 — não é algo exclusivo do HTTP/1.1, apenas foi formalizado ali.

Por que isso importa tanto na prática

A compressão gzip resolve um problema muito concreto: reduzir a quantidade de dados transferidos pela rede. Isso traz benefícios diretos e mensuráveis:

• Páginas carregam mais rápido: menos bytes trafegando significa menos tempo de espera, especialmente perceptível em conexões mais lentas ou com latência alta
• Menor consumo de banda: relevante tanto pra quem paga por dados (usuários com planos limitados, redes móveis) quanto para quem hospeda o serviço (menor custo de tráfego de saída, especialmente em provedores de nuvem que cobram por banda)
• Melhor experiência em conexões móveis: onde a latência e a banda disponível costumam ser bem mais restritas que em redes fixas
• Ganho especialmente grande em conteúdo textual: arquivos como HTML, CSS, JavaScript e JSON são compostos por muito texto repetitivo — tags fechando e abrindo, indentação, nomes de classes repetidos, estrutura previsível — exatamente o tipo de padrão que o LZ77 e a codificação de Huffman exploram bem. Em muitos casos reais, reduções de 60% a 80% no tamanho do arquivo não são incomuns para HTML/CSS/JS

O trade-off: CPU vs. tamanho do arquivo

Vale entender que comprimir dados não é "grátis" — exige processamento do servidor. O gzip permite configurar um nível de compressão (geralmente de 1 a 9):

• Nível baixo (1-3): compressão rápida, mas reduz menos o tamanho do arquivo
• Nível médio (6, geralmente o padrão): bom equilíbrio entre velocidade de processamento e taxa de compressão
• Nível alto (9): compressão máxima, mas consome bem mais CPU — e o ganho adicional de tamanho, comparado ao nível 6, costuma ser pequeno, não compensando o custo extra na maioria dos casos

Por isso, em ambientes de produção, é comum ver o nível configurado em algo intermediário (como 5 ou 6) em vez do máximo — já que o objetivo é equilíbrio, não compressão máxima a qualquer custo.

O que geralmente não vale a pena comprimir

Arquivos que já são binários "densos" — como imagens JPEG/PNG, vídeos MP4, arquivos de áudio MP3, ou arquivos já compactados como ZIP — não se beneficiam de compressão adicional via gzip. Esses formatos já aplicam suas próprias técnicas de compressão internamente durante sua criação. Rodar gzip sobre eles gasta processamento do servidor sem ganho real de tamanho — e em alguns casos pode até aumentar ligeiramente o tamanho final, porque o próprio cabeçalho e metadados do gzip adicionam alguns bytes extras sem conseguir comprimir nada de fato (dado já denso em informação não tem redundância sobrando pra explorar).

Uma implicação de segurança que vale conhecer

Embora o foco principal do gzip seja performance, existe um detalhe de segurança interessante que vale mencionar: ataques como CRIME (2012) e BREACH (2013) exploraram o fato de que a compressão pode vazar informação indiretamente. A ideia, resumida: se um atacante consegue observar o tamanho de respostas compactadas e influenciar parte do conteúdo sendo comprimido junto com dados sensíveis (como um token de sessão), ele pode, em certas condições, inferir informações sobre esse dado sensível analisando como o tamanho da resposta comprimida varia.

Isso não significa que gzip seja "inseguro" de forma geral — significa que, em contextos específicos (como comprimir respostas HTTPS que misturam dados de entrada do usuário com segredos, tipo tokens CSRF), é preciso ter cuidado. Esse é o tipo de detalhe que frameworks web modernos e bibliotecas de segurança já levam em conta, mas é bom saber que existe.

E o que veio depois do Gzip?

Vale mencionar que o gzip não é mais a única opção disponível hoje. Existe o Brotli, um algoritmo de compressão mais moderno, desenvolvido pelo Google e lançado publicamente em 2015, que costuma atingir taxas de compressão melhores que o gzip para conteúdo web, especialmente texto — em boa parte porque o Brotli usa um dicionário estático pré-treinado com padrões comuns encontrados em HTML, CSS e JavaScript da web real, algo que o gzip não tem.

Ele aparece no mesmo header de negociação:

Accept-Encoding: gzip, deflate, br

(o br ali indica suporte a Brotli). O servidor, ao ver que o cliente aceita br, pode preferir usá-lo em vez do gzip, já que geralmente comprime mais.

Mesmo assim, o gzip continua extremamente relevante — é suportado universalmente por praticamente qualquer cliente HTTP existente há décadas, o que o torna uma escolha segura e confiável até hoje como fallback garantido, mais de 30 anos depois de ter sido criado.

Resumindo

O gzip é um exemplo interessante de como uma tecnologia criada para um propósito específico e completamente diferente — compactar arquivos no Unix, em 1992, como alternativa livre a um formato com patente comercial — acabou se tornando peça fundamental de uma infraestrutura completamente distinta (a comunicação via HTTP na web) anos depois. O protocolo HTTP não inventou a compressão — ele criou um mecanismo elegante de negociação entre cliente e servidor, permitindo que ambos combinassem o uso de um formato de compressão já maduro e testado havia quase uma década.

O resultado é algo que hoje passa despercebido pela maioria dos usuários, mas que impacta diretamente a velocidade de praticamente toda página que carregamos: uma parte invisível, porém essencial, de como a web funciona de forma eficiente.