Protocolos HTTP/2 y HTTP/3: rendimiento, seguridad y ventajas

Los usas a diario, aunque probablemente nunca los hayas examinado en detalle. En realidad, se trata de una evolución natural hacia mayor seguridad y estructuras modernas para la distribución de contenido.

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

HTTP es el protocolo que impulsa la World Wide Web. Mientras que HTTP/1.1 estableció el estándar durante décadas, HTTP/2 y HTTP/3 trajeron mejoras significativas de rendimiento. En este artículo te explico las diferencias, ventajas y fundamentos técnicos.

Por qué HTTP necesitaba evolucionar

HTTP/1.1 tiene dos problemas fundamentales:

1. Head-of-Line Blocking: Una única petición se procesa por conexión TCP a la vez. Los navegadores lo contornean usando múltiples conexiones paralelas, pero cada una requiere tiempo para el establecimiento y el handshake TLS.
2. Headers sin comprimir: Los headers se transmiten completos e sin comprimir en cada petición y respuesta. Esto genera sobrecarga considerable cuando hay muchas peticiones.

Estos problemas dieron origen a HTTP/2 y HTTP/3.

Fundamentos de HTTP/2

HTTP/2 se publicó en 2015 como RFC 7540. Modifica la capa de transporte, no la semántica. Para los desarrolladores web, las peticiones y respuestas lucen igual, pero se transportan de forma más eficiente.

Binary Framing

HTTP/1.1 transmite datos como texto legible. HTTP/2 usa framing binario. Los mensajes se dividen en paquetes pequeños llamados frames. Estos frames pertenecen a streams, que a su vez pertenecen a una conexión.

Ejemplo:

Cuando accedes a una página web, el HTML, CSS, JavaScript e imágenes se transmiten a través de streams separados dentro de una única conexión TCP.

Multiplexing

HTTP/2 permite multiplexing. Múltiples peticiones y respuestas se ejecutan simultáneamente sobre una única conexión TCP. Esto elimina el Head-of-Line Blocking de HTTP/1.1.

Comparación: HTTP/1.1 es una calle de un carril. HTTP/2 es una autopista con múltiples carriles.

Compresión de headers con HPACK

HTTP/2 usa HPACK para comprimir headers. Los campos de header repetidos se almacenan en una tabla y solo se transmiten cuando cambian.

Ejemplo: User-Agent: Mozilla/5.0 se retransmite en cada petición con HTTP/1.1. Con HTTP/2, solo se referencia después de la primera petición.

Server Push

Con HTTP/2, el servidor puede enviar recursos de forma proactiva al cliente antes de que los solicite explícitamente. Si el cliente pide un archivo HTML, el servidor puede enviar CSS y JavaScript junto con él. En la práctica, Server Push es controvertido porque puede causar transferencias excesivas de datos.

Priorización de streams

HTTP/2 permite priorizar streams individuales. Los recursos importantes como CSS o JavaScript crítico se transmiten primero.

Ventajas de rendimiento en HTTP/2

• Tiempos de carga más rápidos: El multiplexing y la compresión de headers reducen la latencia.
• Menos conexiones TCP: Una conexión por host es generalmente suficiente.
• Mejor uso de recursos: El servidor y la red se utilizan de forma más eficiente.
• Menos sobrecarga: La transmisión binaria y los headers comprimidos ahorran datos.

Fundamentos de HTTP/3

HTTP/3 se publicó en 2022 como RFC 9114. Mientras que HTTP/2 se basa en TCP, HTTP/3 se basa en QUIC, que funciona sobre UDP.

QUIC en lugar de TCP

QUIC es un protocolo de transporte desarrollado por Google:

• Establecimiento de conexión más rápido: QUIC combina el establecimiento de conexión y el handshake TLS en un solo paso. Esto ahorra típicamente un viaje de ida y vuelta.
• Reanudación 0-RTT: En una reconexión, el cliente puede enviar datos inmediatamente sin un nuevo handshake.
• Migración de conexión: QUIC usa una ID de conexión independiente de la dirección IP y el puerto. El cambio de WiFi a datos móviles es transparente.

UDP como base

UDP es un protocolo sin conexión e inseguro. No hay garantía de orden o entrega. QUIC se construye sobre UDP e implementa confiabilidad, orden y control de flujo por sí mismo.

Integración con TLS 1.3

HTTP/3 requiere TLS 1.3. La seguridad es obligatoria en HTTP/3. TLS 1.3 es más rápido que TLS 1.2 porque reduce el handshake y elimina algoritmos obsoletos.

Head-of-Line Blocking mejorado

En HTTP/2, un paquete TCP perdido puede bloquear todos los streams. En HTTP/3, cada stream es independiente. Un paquete perdido solo bloquea el stream afectado.

Ventajas de rendimiento en HTTP/3

• Establecimiento de conexión aún más rápido: QUIC y TLS 1.3 eliminan el handshake TCP separado.
• Mayor movilidad: La migración de conexión permite cambios de red transparentes.
• Menos Head-of-Line Blocking: Los streams son más independientes.
• Mayor seguridad: TLS 1.3 es obligatorio.
• Mejor rendimiento en redes deficientes: QUIC responde más rápido a la pérdida de paquetes.

Comparación entre HTTP/1.1, HTTP/2 y HTTP/3

Seguridad en HTTP/2 y HTTP/3

Seguridad en HTTP/2

HTTP/2 se implementa en la práctica casi siempre con TLS. Aspectos de seguridad importantes:

• Cifrado TLS: Los datos están protegidos durante la transmisión.
• Protección DoS en HPACK: Los límites en tamaños de header y cantidad de streams dificultan ataques de denegación de servicio.
• Límites de recursos: Los servidores limitan el número de streams simultáneos.

Seguridad en HTTP/3

• TLS 1.3 obligatorio: No existe conexión HTTP/3 sin cifrar.
• Seguridad más rápida: El handshake TLS es más eficiente.
• Riesgos de 0-RTT: La reanudación 0-RTT teóricamente puede explotarse para ataques de replay. Las acciones sensibles no deben ejecutarse en el primer paquete 0-RTT.

¿Qué versión de TLS debe soportar mi servidor?

Cuando configuras un servidor web o servidor HTTP, generalmente puedes activar múltiples versiones de TLS. La pregunta es cuáles tienen sentido y cuáles conviene desactivar.

Activar solo TLS 1.2 y TLS 1.3

Esta es la configuración estándar recomendada para servidores web modernos:

• TLS 1.3 es la versión actual. Es más rápida y segura que TLS 1.2.
• TLS 1.2 aún es necesaria porque algunos clientes antiguos o sistemas no soportan TLS 1.3.

Desactivar TLS 1.0 y TLS 1.1

No deberías usar estas versiones:

• Vulnerabilidades de seguridad: TLS 1.0 y TLS 1.1 contienen debilidades conocidas como BEAST y POODLE.
• Algoritmos obsoletos: Soportan cipher suites inseguras como RC4 o SHA-1.
• Soporte de navegadores: Los navegadores modernos advierten sobre sitios que usan TLS 1.0 o 1.1.

Nunca actives SSL 2.0 y SSL 3.0

SSL es la versión anterior a TLS. SSL 2.0 y SSL 3.0 se consideran inseguros y deben estar completamente desactivados.

Activar todas las versiones de TLS es un error

Puede parecer atractivo maximizar la compatibilidad permitiendo todas las versiones, pero es un riesgo de seguridad:

• Ataques de degradación: Un atacante puede forzar una conexión a una versión de TLS más débil si se permiten versiones antiguas.
• Algoritmos obsoletos: Las versiones antiguas de TLS permiten procedimientos de cifrado inseguros.
• Cumplimiento normativo: Muchos estándares de seguridad como PCI DSS prohíben TLS 1.0 y 1.1.

Configuración recomendada

Para la mayoría de servidores web modernos:

• Activar TLS 1.3: Sí, siempre.
• Activar TLS 1.2: Sí, para compatibilidad con clientes más antiguos.
• TLS 1.1 y TLS 1.0: No, desactivar.
• SSL: No, bajo ningún concepto.

Si solo atiendes clientes modernos, puedes desactivar TLS 1.2 y permitir solo TLS 1.3. Para sitios públicos, sin embargo, es recomendable activar también TLS 1.2 para no excluir clientes antiguos.

Ten presente que tal vez tampoco quieras atraer como visitante a un cliente con infraestructura anticuada.

Ejemplos prácticos de HTTP

Los siguientes ejemplos ilustran bien por qué lo nuevo también es mejor.

Ejemplo 1: Tiempo de carga de una página web

Una página web necesita 100 recursos. Con HTTP/1.1, el navegador abre varias conexiones TCP. Con HTTP/2, todos los recursos se transfieren en paralelo. Con HTTP/3, además se elimina el handshake de TCP.

Ejemplo 2: Streaming de video

En el streaming de video, la baja latencia es crítica. HTTP/3 responde más rápido a los cambios de red y se ve menos afectado por la pérdida de paquetes.

Ejemplo 3: Aplicaciones móviles

Los dispositivos móviles cambian frecuentemente entre WiFi y redes móviles. HTTP/3 con QUIC puede mantener la conexión incluso con cambios de dirección IP.

Qué versión usar en cada caso

• HTTP/1.1: Solo para sistemas legacy antiguos o especiales.
• HTTP/2: Hoy el estándar ampliamente difundido para sitios web y APIs.
• HTTP/3: Cada vez más extendido, especialmente en aplicaciones móviles, streaming y servicios en la nube.

HTTP/2 y HTTP/3 resuelven las mayores debilidades de HTTP/1.1. HTTP/2 ofrece ventajas de rendimiento significativas gracias al multiplexing y la compresión de encabezados. HTTP/3 va un paso más allá con QUIC y UDP, mejorando el establecimiento de conexiones, la movilidad y la robustez ante pérdida de paquetes. Para el desarrollo web moderno, entender estos protocolos es esencial.

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert

Recomendaciones de libros sobre desarrollo web

Si quieres profundizar en protocolos de red, rendimiento web y desarrollo web moderno, te recomendamos los siguientes libros:

FAQ: HTTP/2 y HTTP/3

Continúa en la ruta de aprendizaje de API

El siguiente artículo en la ruta de aprendizaje de API aborda principios de diseño de API — los principios fundamentales para diseñar APIs de calidad, desde la estructura de recursos hasta las convenciones de nombres.