Compressão de Dados na Camada de Apresentação

1. Por que Comprimir na Camada 6

A compressão de dados reduz o volume de bytes transmitidos, economizando banda, baixando latência (especialmente em redes móveis) e melhorando a experiência do usuário. Como é uma transformação de representação — o dado é o mesmo, apenas codificado de forma mais compacta — pertence conceitualmente à camada de Apresentação.

A compressão pode ser:

• Lossless (sem perdas): o dado descomprimido é idêntico ao original bit a bit. Obrigatória para texto, código, documentos.
• Lossy (com perdas): aceita perda controlada para ganhar mais compressão. Usada para imagens, áudio e vídeo, onde o olho/ouvido humano tolera artefatos.

2. Compressão Lossless

Princípios Fundamentais

• Redundância: padrões repetidos são codificados de forma mais curta.
• Entropia: o limite teórico (Shannon) define o quão longe se pode ir.
• Dicionários: tabelas de padrões frequentes.
• Codificação estatística: símbolos frequentes recebem códigos curtos (Huffman, arithmetic).

Algoritmos Clássicos

LZW (Lempel-Ziv-Welch, 1984)

Dicionário dinâmico construído em tempo de execução, sem necessidade de transmitir o dicionário. Foi a base do GIF e do compress do Unix. Patenteado pela Unisys até 2003, o que motivou o desenvolvimento do PNG.

DEFLATE (Phil Katz, 1993)

Combina LZ77 + Huffman. Definido na RFC 1951. Base do:

• gzip (RFC 1952) — wrapper com cabeçalho e CRC32.
• zlib (RFC 1950) — wrapper com Adler-32.
• ZIP — formato de arquivo, usado DEFLATE internamente.
• PNG — substituto sem patente do GIF.

DEFLATE é o "denominador comum" da web: todo navegador suporta Content-Encoding: gzip.

Brotli (Google, 2015)

Definido na RFC 7932. Mais eficiente que DEFLATE em ~20% para conteúdo web:

• Dicionário estático pré-carregado com palavras comuns em HTML/JS/CSS.
• Janela de contexto maior (16 MB).
• Suporta modo texto e modo binário.

Adotado como Content-Encoding: br no HTTP. Suporte é anunciado via Accept-Encoding: br no ClientHello.

Zstandard (Facebook/Meta, 2018)

RFC 8478. Substitui gzip com:

• Razão de compressão melhor (~10-15%).
• Velocidade de descompressão muito maior (até 2-3 GB/s).
• Níveis ajustáveis de 1 (rápido) a 22 (máximo).
• Modo "dicionário" pré-treinado para pequenos arquivos.

Adotado em Content-Encoding: zstd, kernels Linux (4.14+), btrfs, e backups empresariais.

LZ4 (2011)

Extremamente rápido em descompressão (>1 GB/s em CPU comum). Razão de compressão média. Popular em pipelines de baixa latência.

BZIP2 (1996)

Algoritmo Burrows-Wheeler Transform + Huffman. Excelente compressão, mas lento. Ainda usado em distribuições Linux antigas (.bz2).

LZMA/LZMA2 (1998+)

Base do .xz. Compressão melhor que bzip2, com velocidade similar. Usado em pacotes .deb e .rpm.

Comparação Lossless

Algoritmo	Velocidade decode	Razão	Latência	Uso típico
LZ4	Muito alta	Média	Muito baixa	Real-time
gzip/DEFLATE	Alta	Boa	Baixa	Web (legacy)
Brotli	Alta	Excelente	Baixa	Web moderno
Zstandard	Muito alta	Excelente	Baixa	Web moderno, backups
bzip2	Média	Excelente	Alta	Distribuições Linux
LZMA/XZ	Média-baixa	Excelente	Alta	Pacotes

3. Compressão Lossy

Imagens

JPEG (1992, ITU T.81)

Compressão lossy para fotografias. Pipeline:

1. Converter RGB → YCbCr.
2. Subamostrar crominância (4:2:0): olho humano é menos sensível a cor que a luminância.
3. DCT (Discrete Cosine Transform) em blocos 8x8.
4. Quantização: divide por matriz de quantização (controla qualidade).
5. Codificação Huffman dos coeficientes.

Típicos: foto de 2 MB PNG → 200 KB JPEG com perda imperceptível.

PNG (1996)

Lossless — usa DEFLATE. Ideal para gráficos, logos, capturas de tela. Não substitui JPEG para fotos.

WebP (Google, 2010)

Modos lossy e lossless. ~30% menor que JPEG equivalente. Suporte amplo hoje (browsers modernos).

AVIF (2019)

Baseado em AV1. ~50% menor que JPEG para mesma qualidade. Suporte em crescimento (Chrome, Firefox).

Áudio

Formato	Ano	Bitrate típico	Algoritmo
MP3 (MPEG-1 L3)	1993	128-320 kbps	Huffman + MDCT + filterbank
AAC	1997	96-256 kbps	Sucessor do MP3
Opus	2012	6-510 kbps	CELT + SILK, padrão IETF RFC 6716
Vorbis (Ogg)	2000	64-500 kbps	Lossy, open source
FLAC	2001	~700 kbps	Lossless, Linear Predictive + Golomb-Rice

Vídeo

Codec	Ano	Alvo	Eficiência
MPEG-2	1995	DVD, TV digital	Referência
H.264/AVC	2003	Streaming, Blu-ray	2x MPEG-2
H.265/HEVC	2013	4K, HDR	2x H.264
VP9 (Google)	2013	YouTube 4K	Similar a HEVC
AV1	2018	Web aberta	~30% melhor que HEVC
H.266/VVC	2020	8K	2x HEVC

Vídeo moderno usa intra (I-frames), inter predicted (P-frames) e bidirecional (B-frames), explorando redundância espacial e temporal.

4. Compressão em Protocolos

HTTP

GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip, deflate, br, zstd

Resposta:

HTTP/1.1 200 OK
Content-Encoding: br
Content-Type: text/html
Vary: Accept-Encoding

A compressão HTTP acontece tipicamente no gateway/servidor web (nginx, Apache) e é transparente para o navegador.

SSH

SSH suporta compressão opcional (Compression yes no ssh_config). Útil em links lentos, mas raramente habilitado hoje — em links rápidos a sobrecarga de CPU supera o ganho.

TLS

TLS teve compressão nativa até TLS 1.2 (TLSCompression), removida em TLS 1.3 devido ao ataque CRIME (2012) e BREACH (2013), que exploravam vazamento de informações via tamanho da resposta comprimida.

Modem/PPP

Histórico: Stac LZS (RFC 1967) e Predictor (RFC 1978) em PPP. Com o fim dos modems dial-up, caíram em desuso.

5. Trade-offs: Comprimir ou Não?

Quando Comprimir

• Texto (HTML, JSON, XML) — sempre.
• Imagens já comprimidas (JPEG, PNG) — comprimir de novo não ajuda.
• Dados em links lentos (móvel, satélite).

Quando NÃO Comprimir

• Payload pequeno (<1 KB) — o overhead do cabeçalho de compressão supera o ganho.
• Dados pré-comprimidos (JPEG, MP4, ZIP).
• Em links de alta velocidade com CPU limitada.
• Quando há risco de side-channel (CRIME/BREACH em TLS).

6. Compressão na Prática

Servidores Web

• nginx: gzip on; gzip_types text/plain application/json;
• Apache: mod_deflate, mod_brotli
• CDN: Cloudflare, Fastly, CloudFront aplicam Brotli automaticamente.

APIs

REST APIs devem sempre comprimir JSON — o ganho é tipicamente 80-90% em payloads verbosos.

7. Conclusão

A compressão na camada de Apresentação é um dos ganhos mais baratos de performance disponíveis. Sem alterar semântica, sem quebrar compatibilidade, ela reduz latência e custo de banda. A evolução de LZW → DEFLATE → Brotli → Zstandard mostra que o tema permanece ativo: cada nova geração de algoritmos oferece 10-30% de ganho adicional. Para vídeo e imagens, a transição JPEG → WebP → AVIF e H.264 → HEVC → AV1 → VVC continua reduzindo drasticamente o custo de armazenar e transmitir mídia na internet.