2. Evolución del protocolo HTTP

HTTP nació como un protocolo extremadamente simple: un cliente solicitaba un recurso y el servidor respondía. Con el crecimiento de la web se convirtió en la columna vertebral del comercio electrónico, del streaming y de las aplicaciones móviles, lo que obligó a extenderlo sin perder compatibilidad. En este tema revisamos los hitos que llevaron de HTTP/1.1 a HTTP/2 y HTTP/3.

Analizaremos las limitaciones técnicas que arrastraba HTTP/1.1, los objetivos perseguidos por las siguientes versiones y la forma en la que el protocolo se apoya en TLS, TCP o UDP según la capa de transporte disponible.

2.1 Limitaciones de HTTP/1.1: múltiples conexiones, latencia y cabeceras repetidas

HTTP/1.1 introdujo avances importantes frente a su predecesor (mantener conexiones abiertas, pipelining y dominios virtuales), pero heredó supuestos que ya no se sostienen hoy. Entre los más notorios se encuentran:

  • Conexiones simultáneas limitadas: los navegadores abrían entre 6 y 8 conexiones por dominio para descargar en paralelo, provocando competencia por recursos y mayor uso de CPU tanto en el cliente como en el servidor.
  • Head-of-line blocking: las respuestas debían enviarse en el mismo orden en que se solicitaban. Si la primera tardaba, las siguientes quedaban bloqueadas aunque estuvieran listas.
  • Cabeceras redundantes: cada solicitud repetía campos idénticos como User-Agent o cookies, incrementando el ancho de banda desperdiciado.
  • Limitaciones de pipelining: aunque la especificación lo permitía, pocas implementaciones lo usaban por problemas de intermediarios (proxies y balanceadores incapaces de manejar múltiples respuestas pendientes).
Problema Impacto en 2000-2010 Impacto actual
Conexiones por dominio Latencias aceptables porque los sitios tenían pocos recursos. Bloqueos evidentes en sitios SPA con cientos de solicitudes.
Head-of-line blocking Se mitigaba repartiendo recursos en subdominios (domain sharding). Genera cascadas de retrasos y obliga a hacks como sprites o bundling excesivo.
Cabeceras repetidas Poco perceptible en conexiones fijas. Aumenta costos en móviles donde cada byte cuenta.

2.2 Objetivos de las versiones posteriores: reducción de latencia y mejor multiplexación

Para resolver esas limitaciones se diseñaron protocolos experimentales como SPDY. La experiencia obtenida se volcó en HTTP/2 y HTTP/3, cuyos objetivos principales fueron:

  • Multiplexar múltiples solicitudes en una sola conexión: evita abrir sockets extra y reduce el tiempo de establecimiento.
  • Comprimir cabeceras: el mecanismo HPACK (y posteriormente QPACK) asegura que los campos repetidos ocupen solo unos bytes.
  • Priorizar recursos críticos: los flujos pueden declararse dependientes, permitiendo que scripts esenciales se entreguen antes que imágenes diferibles.
  • Eliminar optimizaciones forzadas: técnicas como concatenar archivos o usar sprites dejan de ser necesarias y se puede volver a empaquetados por módulo.

En pruebas realizadas por CDNs y navegadores, pasar de HTTP/1.1 a HTTP/2 reduce entre un 20 % y un 40 % el tiempo total de carga en sitios con más de 100 recursos estáticos, incluso sin modificar el contenido.

HTTP/3 continúa esta línea pero replantea el transporte: usa UDP y flujos independientes para que la pérdida de un paquete no detenga al resto. Además integra desde el inicio características como el cero round-trip (0-RTT) que permiten retomar una sesión casi al instante.

2.3 Relación entre HTTP, TLS y TCP/UDP

HTTP es un protocolo de capa de aplicación, por lo que necesita apoyarse en una capa de transporte para entregar sus mensajes. Tradicionalmente se ejecutaba encima de TCP y, cuando se requería privacidad, se encapsulaba dentro de TLS (HTTPS).

La cronología puede resumirse así:

  1. HTTP/1.0 y HTTP/1.1: operan sobre TCP. Para cifrar se negocia TLS 1.3 (o versiones previas) mediante un handshake adicional.
  2. HTTP/2: también usa TCP, pero la especificación exige TLS en la mayoría de implementaciones públicas para prevenir ataques de intermediarios.
  3. HTTP/3: reemplaza TCP por QUIC, que a su vez se ejecuta sobre UDP y combina transporte y cifrado en un único handshake.

Este cambio tiene dos implicancias técnicas:

  • Control de congestión integrado: QUIC permite experimentar sin esperar despliegues del kernel, algo esencial para Google o Cloudflare.
  • Reanudación rápida: al incorporar criptografía en el transporte, HTTP/3 puede retomar sesiones sin renegociar claves completa y repetidamente.

Es importante comprender que HTTP sigue siendo el mismo lenguaje semántico (métodos, cabeceras, códigos). Lo que cambia son las reglas con las que se empaqueta y se envía por la red para alcanzar mejores tiempos de entrega y mayor resiliencia.

2.4 Importancia del rendimiento y la eficiencia en conexiones persistentes

Las conexiones persistentes son el cimiento de la web moderna: permiten enviar varios recursos sin cerrar el socket y mantienen activa la negociación criptográfica. Sin embargo, son un arma de doble filo cuando no se optimizan.

Buenas prácticas para aprovecharlas:

  • Evitar el “chattiness” innecesario: agrupa solicitudes lógicas para no despertar al servidor en ráfagas muy cortas.
  • Habilitar HTTP keep-alive con tiempos razonables: muy largos implican sockets ociosos; muy cortos obligan a rehacer handshakes.
  • Usar compresión y cacheo selectivo: aunque HTTP/2 y HTTP/3 reducen la sobrecarga, aún es clave definir políticas de cache para CSS, JS e imágenes.
  • Medir con herramientas reales: DevTools, curl --http2 o curl --http3 permiten verificar rápidamente qué versión está en uso y cuántos RTT se consumen.

Recordá que cualquier degradación en la latencia afecta directamente métricas de negocio como conversiones o permanencia. Incluso unos pocos cientos de milisegundos adicionales pueden hacer que una app móvil parezca “trabada”. Por eso, migrar a versiones modernas de HTTP debe ir acompañado de monitoreo continuo y pruebas A/B que validen el beneficio percibido por los usuarios.

Retornar