32.Compresión

La compresión es reducir el tamaño de los datos para que ocupen menos y viajen más rápido por la red. Del otro lado se descomprimen para recuperarlos.

Es como empacar ropa al vacío para una maleta: lo que llevas es lo mismo, pero ocupa mucho menos. Algunas compresiones son así, sin perder nada; otras, como reducir la calidad de una foto, quitan detalles que casi no se notan para ahorrar todavía más.

En términos técnicos

• Es tarea de la capa 6 (Presentación) en el modelo OSI; en TCP/IP la hace la aplicación (el navegador, el servidor web, el códec de video).
• Sin pérdida (lossless): se recupera exactamente lo original. Para texto, código, documentos y archivos: DEFLATE (gzip, ZIP), Brotli, Zstandard.
• Con pérdida (lossy): se descarta información que el ojo o el oído casi no perciben. Para imagen, audio y video: JPEG, WebP, MP3, AAC, H.264, H.265, AV1.
• Se mide con la tasa de compresión: tamaño original entre tamaño comprimido.

¿Dónde lo vas a encontrar?

En casi todas las páginas web (el servidor envía el HTML, CSS y JavaScript con gzip o Brotli), en los archivos ZIP, en las fotos JPEG, en el streaming de video y música, en las videollamadas y en los encabezados de HTTP/2 y HTTP/3.

Las ideas detrás de la compresión sin pérdida

DEFLATE (el de gzip y ZIP) combina LZ77 + Huffman. Brotli y Zstandard usan ideas parecidas con diccionarios más grandes y mejores algoritmos.

Un ejemplo real: un HTML de 11 800 bytes con un párrafo repetido 200 veces quedó en 133 bytes con gzip. En cambio, 10 000 bytes aleatorios quedaron en 10 023: no había nada que repetir y gzip solo agregó su encabezado.

Compresión con pérdida

La compresión en HTTP

1. El navegador anuncia lo que entiende: Accept-Encoding: gzip, deflate, br, zstd.
2. El servidor elige uno, comprime la respuesta y lo indica: Content-Encoding: br.
3. El navegador descomprime y muestra la página.

Además, HTTP/2 comprime los encabezados con HPACK y HTTP/3 con QPACK.

• Texto: siempre comprimido (HTML, CSS, JavaScript, JSON, SVG). Imágenes y video: elige bien el formato, no los pases por gzip.
• Brotli comprime mejor que gzip para la web; Zstandard es muy rápido y se usa en sistemas y respaldos.
• Más compresión, más procesador: los niveles altos (p. ej. gzip -9) ahorran poco más y tardan bastante más. Para contenido que no cambia, conviene comprimirlo una vez de antemano.
• Con pérdida no se recupera: guardar una y otra vez un JPEG lo degrada. Conserva el original.
• Elige formatos modernos: WebP o AVIF para fotos en la web, AV1 o H.265 para video, Opus para voz.
• Compresión en VPN o enlaces WAN: algunos equipos comprimen el tráfico, pero si casi todo ya va cifrado (HTTPS) el beneficio es mínimo.

• IETF. RFC 1951 — DEFLATE Compressed Data Format Specification (1996) y RFC 1952 — GZIP file format (1996). https://www.rfc-editor.org/rfc/rfc1951
• IETF. RFC 7932 — Brotli Compressed Data Format (2016). https://www.rfc-editor.org/rfc/rfc7932
• IETF. RFC 8878 — Zstandard Compression and the 'application/zstd' Media Type (2021). https://www.rfc-editor.org/rfc/rfc8878
• IETF. RFC 9110 — HTTP Semantics (2022), cabeceras Accept-Encoding y Content-Encoding.
• IETF. RFC 7541 — HPACK: Header Compression for HTTP/2 (2015).