Cuando se habla de versiones de HTTP, normalmente surgen estos pensamientos.

“¿No es todo HTTP en la web? ¿Qué diferencia hay entre 1.1 y 2?”
“¿No puedo simplemente usar la nueva versión, HTTP/2?”

Resumiendo:

  • HTTP/1.1 vs HTTP/2 es más una diferencia en la manera de enviar el mismo significado de HTTP (métodos/headers/códigos de estado, etc.) de manera más eficiente.

  • En la práctica, no es “escoger uno”, sino que el servidor soporta ambos y el cliente elige lo que puede.

A continuación, resumiré los puntos clave desde la perspectiva de un desarrollador.

1. Resumen de HTTP/1.1

Commandbox 광고

1) Protocolo basado en texto

HTTP/1.1 es el tipo de formato de solicitud/respuesta que comúnmente vemos.

GET /index.html HTTP/1.1
Host: ejemplo.com
Connection: keep-alive

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

<html>...</html>

  • Es texto legible por humanos, lo que facilita la depuración,

  • y se puede entender la estructura incluso al usar herramientas como curl, telnet, nc.

2) Conexión persistente + Pipelining

Un gran problema de HTTP/1.0 era abrir una nueva conexión TCP para cada solicitud, pero
HTTP/1.1 lo solucionó haciendo que la conexión persistente (keep-alive) fuera la norma,
permitiendo enviar múltiples solicitudes secuencialmente sobre una sola conexión.

Además, había una característica llamada HTTP Pipelining:

  • Enviar solicitudes en secuencia sin esperar respuestas

  • Recibir respuestas en orden.

Sin embargo, en realidad no se usó mucho en navegadores y,
sigue habiendo problemas de rendimiento debido a la “estructura que debe ser procesada en orden”.

3) Problema de bloqueo HOL (Head-of-Line)

Un cuello de botella representativo de HTTP/1.1 es el bloqueo HOL (Head-of-Line).

  • Debido a que las solicitudes deben procesarse en secuencia en una sola conexión,

  • si la solicitud más rápida se retrasa, también deben esperar las que vienen después.

  • Por lo tanto, los navegadores han estado abriendo múltiples conexiones TCP por dominio (por ejemplo, hasta 6) para mitigar este problema.

En resumen:

HTTP/1.1 es “una manera de crear múltiples tubos para reducir el cuello de botella”
(múltiples conexiones TCP).

2. ¿Qué es diferente en HTTP/2?

El objetivo de HTTP/2 es claro.

  • Reducir la latencia

  • Utilizar los recursos de red de manera más eficiente

Si resumimos las palabras clave:

  1. Framing binario

  2. Multiplexión basada en Streams

  3. Compresión de cabeceras (HPACK)

  4. (Originalmente) Server Push – prácticamente muerto en los navegadores

2-1. De texto a framing binario

HTTP/1.1 hace parsing de texto línea por línea, mientras que en HTTP/2, todo se envía en frames que son fragmentos binarios.

  • Las cabeceras son enviadas en frames de HEADERS

  • El cuerpo es enviado en frames de DATA

  • Estos frames pertenecen a un ID de stream específico.

Es raro que los desarrolladores interactúen directamente con los frames,
pero gracias a esto, se pueden implementar funcionalidades como multiplexión, compresión de cabeceras y prioridades.

2-2. Multiplexión

Es la diferencia más palpable.

  • HTTP/1.1: procesa las solicitudes y respuestas en secuencia en una conexión TCP

  • HTTP/2: transmite múltiples streams simultáneamente en una sola conexión TCP

En otras palabras:

“No hay necesidad de abrir múltiples conexiones TCP,
sino que se pueden enviar solicitudes y respuestas entrelazadas en una sola conexión”

Esto significa que:

  • Cuando una página HTML necesita cargar decenas o cientos de recursos

  • Se puede mantener una sola conexión y cargar todo simultáneamente

  • Esto es especialmente beneficioso en ambientes móviles o con altas latencias (RTT).

Sin embargo, aún persiste el bloqueo HOL a nivel de TCP, así que este aspecto fue mejorado aún más en HTTP/3 (QUIC).

2-3. Compresión de cabeceras (HPACK)

Los headers de solicitudes/respuestas HTTP tienen mucha duplicación.

  • Cookie, User-Agent, Accept-*, entre otros

  • Pueden ocupar cientos de KB en cada solicitud.

HTTP/2 utiliza un método de compresión de headers llamado HPACK para reducir la duplicación entre estos headers.

  • Los headers más utilizados se registran en una tabla y se envían con un índice corto

  • Solo se codifican las partes que han cambiado respecto a la solicitud anterior.

Esto beneficia especialmente a SPA con muchas solicitudes / páginas ricas en recursos.

2-4. Server Push está prácticamente muerto

Al principio, la función de Server Push de HTTP/2, que permitía al servidor enviar antes CSS/JS antes de que el cliente lo solicitara, fue vista como una gran ventaja, pero en la práctica:

  • Es difícil de implementar

  • Problemas de caché/recursos duplicados

  • La mejora en el rendimiento es mínima o incluso puede empeorar

Por lo tanto, Chrome/Chromium deshabilitó esta opción por defecto a partir de 2022 (Chrome for Developers)
y Firefox también eliminará el soporte en 2024, por lo que esta función está prácticamente terminada en el ecosistema de navegadores.

Así que, al hablar de HTTP/2 hoy en día, el Server Push debe considerarse como una “función histórica”.

3. HTTPS, ALPN, y la elección de “h2 vs http/1.1”

Commandbox 광고

En los servicios reales, “¿debería usar HTTP/1.1 o HTTP/2?” es algo que el cliente y el servidor negocian automáticamente durante el proceso de handshake de TLS.

Esto es gestionado por una extensión TLS llamada ALPN (Application-Layer Protocol Negotiation).

  • Cliente: “Sé usar tanto h2 como http/1.1”

  • Servidor: “Entonces usemos h2” (o “solo puedo usar http/1.1”)

Ejemplo de configuración en Apache:

Protocols h2 http/1.1

Con esta configuración:

  • Los navegadores modernos que soportan HTTP/2 utilizan automáticamente HTTP/2 (h2)

  • Los clientes más antiguos comunican automáticamente usando HTTP/1.1

La mayoría de los navegadores principales ya soportan bien HTTP/2,
y muchos sitios web han habilitado HTTP/2.

4. “¿Cuándo es necesario usar ambos?” – Resumen desde la perspectiva del desarrollo

Veamos esta parte clave de la pregunta en diferentes casos.

4-1. Servicios web comunes (dirigidos a navegadores)

Estrategia casi correcta:

“Activar HTTPS + HTTP/2 por defecto,
y dejar HTTP/1.1 como opción de respaldo.”

  • La mayoría de los servidores web (Nginx, Apache, Envoy, etc.) y CDN
    negocian automáticamente solo con habilitar la opción de soporte para HTTP/2.

  • Es raro que a nivel de aplicación se necesite dividir “esta solicitud va en 1.1, y aquella en 2”.

En otras palabras, si estás creando un nuevo servicio, piensa en ‘HTTPS con HTTP/2 habilitado’ como valor por defecto.

4-2. API internas / Comunicación de microservicios

Aquí hay un poco más de opciones.

  • Si ya está funcionando bien con REST + HTTP/1.1,
    no es necesario reescribirlo a HTTP/2.

  • Sin embargo,

    • Si se están enviando o recibiendo muchas solicitudes cortas entre el mismo servicio,

    • y se usa un protocolo basado en HTTP/2 como gRPC,
      → es natural utilizar HTTP/2.

En resumen:

  • “API REST legadas” → mantener 1.1 +, si es necesario, terminación HTTP/2 en proxy/balancer

  • “Introducir gRPC, llamadas de microservicio de alta frecuencia” → usar activamente HTTP/2.

4-3. Depuración, logging, entornos legados

HTTP/1.1 todavía puede ser útil en ciertas situaciones.

  • Es fácil de leer en tcpdump y Wireshark debido a su formato basado en texto

  • Algunos proxies/firewalls/clientes antiguos pueden no soportar HTTP/2.

  • En herramientas internas simples y servidores de prueba, no es necesario utilizar HTTP/2.

De hecho, en muchos entornos:

  • Externo (navegador) ↔ Proxy frontal (CDN/Balancer) : HTTP/2

  • Proxy ↔ Servicio backend : HTTP/1.1

Es común tener una estructura mixta.

5. Respuesta práctica a “¿No puedo usar solo HTTP/2?”

Teóricamente:

“Si estás creando un servicio web público nuevo, puedes considerar HTTP/2 como la norma.”

Eso es correcto.

Pero en la práctica:

  1. Es difícil eliminar completamente HTTP/1.1

    • Los clientes más antiguos o en entornos especiales aún requieren 1.1.

    • En depuración/herramientas/sistemas internos, a menudo es más conveniente usar 1.1.

  2. Desde el punto de vista del servidor, ‘soportar ambos’ es lo común

    • En la configuración del servidor web, lo activas como h2 http/1.1,

    • y dejas que el cliente elija automáticamente el mejor protocolo que soporte.

  3. Estamos considerando la era de HTTP/3 (QUIC)

    • Los navegadores y servicios modernos ya soportan HTTP/3.

    • Pero eso también se hace generalmente manteniendo “HTTP/1.1 + HTTP/2 + HTTP/3” abiertos simultáneamente,
      permitiendo que los clientes negocien.

Por lo tanto, la conclusión práctica es:

“En vez de aferrarte a HTTP/2,
es mejor mantener HTTP/2 habilitado y dejar HTTP/1.1 como una opción de retroceso natural.”

Eso es todo.

Comparación de métodos de transferencia según la versión HTTP

6. Resumen

Resumiendo:

  • HTTP/1.1

    • Basado en texto

    • Conexión persistente + (teóricamente) pipelining

    • Debido al problema de bloqueo HOL, los navegadores utilizan múltiples conexiones TCP.

  • HTTP/2

    • Framing binario

    • Multiplexión que maneja múltiples streams simultáneamente en una conexión TCP

    • Compresión de cabeceras HPACK

    • Server Push ha muerto prácticamente en la práctica.

  • Estrategia de uso

    • Web externas (dirigidas a navegadores): habilitar HTTPS + HTTP/2 y dejar HTTP/1.1 como opción de retroceso

    • API internas: mantener 1.1 para REST existente es aceptable, usar HTTP/2 si hay llamadas de alto volumen/streaming/gRPC

    • Depuración/legacy: HTTP/1.1 sigue siendo conveniente y útil.

Una línea que los desarrolladores deberían recordar:

“No te preocupes por elegir versiones en el código de la app,
deja que el servidor mantenga HTTP/2 habilitado y que el resto sea negociado en protocolo (ALPN).”