¿Cuáles son las diferencias entre HTTP/1.1, HTTP/2 y HTTP/3?

Question

IT Interview Practice · Accepted Answer

Los tres ofrecen la misma semántica HTTP (métodos, cabeceras, códigos de estado) pero difieren en *cómo* mueven los bytes por el cable: cada versión arregla un cuello de botella de la anterior. El tema común es **eliminar el head-of-line (HOL) blocking**, donde una petición atascada retiene a las demás.

```text
HTTP/1.1  over TCP     one request at a time per connection
  conn ──[req A]──[req B]──[req C]──▶   B waits for A (HOL blocking at HTTP layer)

HTTP/2    over TCP     many streams multiplexed on ONE connection
  conn ══[A|B|C interleaved]══▶        but a lost TCP packet stalls ALL streams
                                       (HOL blocking moves down to TCP)

HTTP/3    over QUIC (UDP)   independent streams, per-stream delivery
  conn ══[A][B][C]══▶                  a lost packet stalls only its own stream
```

**HTTP/1.1** envía una petición por conexión cada vez; los navegadores lo sortean abriendo ~6 conexiones paralelas por host, y las cabeceras de texto se envían sin comprimir. **HTTP/2** añade **multiplexing** —muchos **streams** concurrentes sobre una única conexión— más binary framing, compresión de cabeceras (HPACK) y server push. Pero como sigue corriendo sobre TCP, un solo paquete perdido bloquea *todos* los streams hasta que se retransmite: el HOL blocking simplemente se movió de la capa HTTP hacia abajo, a TCP.

**HTTP/3** lo resuelve corriendo sobre **QUIC**, un nuevo transporte construido sobre **UDP**. QUIC implementa los streams por sí mismo, así que la pérdida en un stream no atasca a los demás. También fusiona los handshakes de transporte y TLS (1-RTT, a menudo 0-RTT al reanudar) para un establecimiento de conexión más rápido, y soporta **connection migration** para que una sesión sobreviva a un cambio de red (Wi-Fi → cellular).

## Por qué es importante

Esta es una pregunta favorita de nivel medio porque la respuesta es una historia de *problema → arreglo → nuevo problema → arreglo*, que es exactamente cómo un buen ingeniero razona sobre sistemas en evolución. La idea clave que buscan los entrevistadores es entender el **head-of-line blocking en dos capas**: HTTP/2 lo resolvió en la capa de aplicación pero seguía atrapado bajo TCP, y HTTP/3 tuvo que cambiar el propio transporte para terminar el trabajo. Es además práctico: saber esto guía decisiones reales sobre reutilización de conexiones, si conviene todavía hacer sharding de dominios, y qué ganas al habilitar HTTP/3 en tu CDN.

Por qué es importante

Preguntas relacionadas