5. Comparativa entre HTTP/1.1, HTTP/2 y HTTP/3

Tras estudiar cada protocolo por separado, es momento de verlos en perspectiva. Esta comparativa te ayudará a decidir cuándo mantener HTTP/1.1, cuándo sacar ventaja de HTTP/2 y en qué escenarios conviene apostar por HTTP/3. Evaluaremos transporte, multiplexación, seguridad, velocidad y su comportamiento ante distintas condiciones de red.

5.1 Diferencias clave: transporte, multiplexación, seguridad y velocidad

El siguiente resumen ubica a cada versión dentro de la pila de red:

Dimensión HTTP/1.1 HTTP/2 HTTP/3
Transporte TCP clásico. TCP + mejoras en la capa aplicación. QUIC sobre UDP (transporte propio).
Multiplexación Pipelining limitado y propenso a bloqueos. Streams paralelos en una conexión. Streams paralelos con pérdidas aisladas.
Seguridad HTTPS opcional, handshake adicional. HTTPS prácticamente obligatorio. TLS 1.3 integrado en QUIC.
Latencia percibida Elevada en sitios con muchos recursos. 20-40 % menos tiempo al primer byte. Hasta 100 ms menos en redes móviles gracias a 0-RTT.
Compatibilidad Universal, incluso en dispositivos legados. Alta, requiere soporte ALPN. En expansión, depende de clientes/browsers recientes.

La conclusión inmediata es que HTTP/2 y HTTP/3 atacan las mismas debilidades, pero HTTP/3 va un paso más allá al controlar también el transporte.

5.2 Tablas de rendimiento y casos de uso

La teoría se valida con métricas. A continuación se muestra un experimento típico en un entorno controlado con 120 recursos estáticos (CSS, JS, imágenes) y una red de 80 ms de RTT.

Métrica HTTP/1.1 HTTP/2 HTTP/3
Tiempo total de carga 2.4 s 1.5 s 1.2 s
Conexiones simultáneas necesarias 6-8 1 1
Overhead de cabeceras 210 KB 70 KB (HPACK) 68 KB (QPACK)
Recuperación ante pérdida Bloquea toda la cola. Bloquea la conexión por ser TCP. Afecta solo al stream que perdió paquetes.

Estos datos provienen de pruebas con webpagetest.org y herramientas internas. Aunque los números varían según el sitio, el orden de magnitud se mantiene en escenarios reales.

Casos de uso recomendados:

  • HTTP/1.1: servicios internos, APIs sencillas o dispositivos embebidos donde actualizar el stack resultaría costoso.
  • HTTP/2: aplicaciones web complejas, sitios con CDNs tradicionales, APIs REST expuestas al público.
  • HTTP/3: plataformas móviles, streaming, videojuegos, dashboards críticos y cualquier sistema sensible a la latencia en redes cambiantes.

5.3 Cuándo conviene cada versión según el entorno de red

Más allá de la teoría, la decisión depende de las restricciones de tu infraestructura y de tus usuarios. Considerá los siguientes criterios:

Entorno de red Condición típica Versión recomendada Justificación
LAN corporativa estable Baja latencia, routers administrados. HTTP/2 Se obtiene multiplexación y compresión sin depender de clientes con soporte HTTP/3.
Usuarios globales en 4G/5G Cambios constantes de IP y pérdida ocasional. HTTP/3 QUIC mantiene la sesión al migrar de red y aísla los streams afectados.
IoT o hardware legado Pilas TCP limitadas, sin soporte TLS moderno. HTTP/1.1 (con optimizaciones) Mantener compatibilidad hasta que el hardware pueda actualizarse.
CDN multi-región Balanceo entre millones de clientes. HTTP/2 + HTTP/3 en paralelo Negocia automáticamente la mejor opción según el agente de usuario.

Recomendaciones prácticas:

  • Ofrecer HTTP/2 y HTTP/3 simultáneamente es viable: los navegadores eligen el protocolo más avanzado disponible mediante ALPN y compatibilidad QUIC.
  • Registrar métricas por protocolo (por ejemplo, usando Server-Timing o dashboards de CDN) ayuda a medir el impacto real antes y después de cada despliegue.
  • Planificar caídas controladas para clientes antiguos: definir fechas límite para HTTP/1.1 evita mantener hacks como domain sharding indefinidamente.

En síntesis, HTTP/1.1 seguirá existiendo como base de compatibilidad, HTTP/2 es el estándar dominante actual y HTTP/3 se convierte rápidamente en la mejor opción para optimizar experiencias móviles y multimedia.

Retornar