HTTP/2 y HTTP/3 - La evolución de los protocolos web | Conceptos

La evolución de HTTP

HTTP es el protocolo fundamental de la Web. Comenzó con HTTP/0.9 en 1991 y ha evolucionado hasta HTTP/3 en la actualidad.

flowchart LR
    H09["HTTP/0.9<br/>(1991)"] --> H10["HTTP/1.0<br/>(1996)"]
    H10 --> H11["HTTP/1.1<br/>(1997)"]
    H11 --> H2["HTTP/2<br/>(2015)"]
    H2 --> H3["HTTP/3<br/>(2022)"]

Problemas de HTTP/1.1

Head-of-Line Blocking

En una sola conexión TCP, las solicitudes deben procesarse en orden.

sequenceDiagram
    participant C as Cliente
    participant S as Servidor

    Note over C,S: HTTP/1.1 - Procesamiento secuencial
    C->>S: Solicitud 1
    S-->>C: Respuesta 1
    C->>S: Solicitud 2
    S-->>C: Respuesta 2
    C->>S: Solicitud 3
    S-->>C: Respuesta 3

    Note over C,S: Si una solicitud anterior se bloquea,<br/>las siguientes también esperan

Necesidad de múltiples conexiones

Para garantizar el paralelismo, los navegadores utilizan de 6 a 8 conexiones TCP por dominio.

flowchart TB
    subgraph Domain["Dominio: example.com"]
        TCP1["Conexión TCP 1: script.js"]
        TCP2["Conexión TCP 2: style.css"]
        TCP3["Conexión TCP 3: image1.jpg"]
        TCP4["Conexión TCP 4: image2.jpg"]
        TCP5["Conexión TCP 5: image3.jpg"]
        TCP6["Conexión TCP 6: image4.jpg"]
    end

    Note["Sobrecarga de conexiones, desperdicio de recursos"]

Características de HTTP/2

Multiplexación (Multiplexing)

Una sola conexión TCP puede procesar múltiples solicitudes/respuestas en paralelo.

flowchart TB
    subgraph TCP["HTTP/2: Conexión TCP única"]
        subgraph Requests["Solicitudes (paralelas)"]
            R1["Req 1"]
            R2["Req 2"]
            R3["Req 3"]
            R4["Req 4"]
        end
        subgraph Responses["Respuestas (paralelas)"]
            S1["Res 1"]
            S2["Res 2"]
            S3["Res 3"]
            S4["Res 4"]
        end
        R1 --> S1
        R2 --> S2
        R3 --> S3
        R4 --> S4
    end

    Note["Procesamiento paralelo, sin dependencia de orden"]

Protocolo binario

Cambio del formato de texto de HTTP/1.1 a frames binarios.

flowchart TB
    subgraph HTTP11["HTTP/1.1 (texto)"]
        Text["GET /index.html HTTP/1.1\r\n<br/>Host: example.com\r\n"]
    end

    subgraph HTTP2["HTTP/2 (frames binarios)"]
        Header["Length | Type | Flags"]
        StreamID["Stream ID"]
        Payload["Payload"]
        Header --> StreamID --> Payload
    end

Compresión de cabeceras (HPACK)

Comprime eficientemente las cabeceras y omite las cabeceras duplicadas.

flowchart LR
    subgraph First["Primera solicitud"]
        F1[":method: GET"]
        F2[":path: /index.html"]
        F3[":authority: example.com"]
        F4["user-agent: Mozilla/5.0..."]
        F5["accept: text/html"]
    end

    subgraph Second["Segunda solicitud"]
        S1[":path: /style.css"]
        S2["(Se omite el resto porque es igual al anterior)"]
    end

    First --> Second
    Note["El tamaño de las cabeceras se reduce significativamente"]

Server Push

El servidor puede enviar recursos antes de que el cliente los solicite.

sequenceDiagram
    participant C as Cliente
    participant S as Servidor

    C->>S: Solicitud de index.html
    S-->>C: Respuesta de index.html
    S-->>C: Push de style.css (enviado sin solicitud)
    S-->>C: Push de script.js

    Note over C,S: Reduce el RTT

Nota: Server Push no se usa mucho en la práctica y ha sido deshabilitado desde Chrome 106.

Control de prioridad

Se puede establecer prioridad a los streams para procesar primero los recursos importantes.

flowchart TB
    subgraph Priority["Control de prioridad"]
        S1["Stream 1 (HTML): Prioridad alta"]
        S2["Stream 2 (CSS): Prioridad alta"]
        S3["Stream 3 (imagen): Prioridad baja"]
    end

    S1 & S2 --> Load["HTML/CSS se cargan primero"]
    S3 -.-> Load

Problemas de HTTP/2

El Head-of-Line Blocking a nivel TCP no se ha resuelto.

flowchart TB
    subgraph TCP["HTTP/2 sobre TCP"]
        P1["Paquete 1 ✓"]
        P2["Paquete 2 ✓"]
        P3["Paquete 3 ✗ (pérdida de paquete)"]
        P4["Paquete 4 ✓ → Esperando en capa TCP"]
        P5["Paquete 5 ✓ → Esperando en capa TCP"]
    end

    P3 --> Block["Una pérdida de paquete<br/>bloquea todos los streams"]

    style P3 fill:#f99,stroke:#f00
    style P4 fill:#ff9,stroke:#f90
    style P5 fill:#ff9,stroke:#f90

HTTP/3 y QUIC

HTTP/3 utiliza el protocolo QUIC (construido sobre UDP) en lugar de TCP.

Características de QUIC

flowchart TB
    subgraph Traditional["Tradicional"]
        T_App["Capa de aplicación: HTTP/2"]
        T_Trans["Capa de transporte: TCP + TLS"]
        T_Net["Capa de red: IP"]
        T_App --> T_Trans --> T_Net
    end

    subgraph HTTP3["HTTP/3"]
        H_App["Capa de aplicación: HTTP/3"]
        H_Trans["Capa de transporte: QUIC<br/>(UDP + TLS 1.3 integrado)"]
        H_Net["Capa de red: IP"]
        H_App --> H_Trans --> H_Net
    end

Independencia de streams

Cada stream es independiente, y la pérdida de un paquete no afecta a otros streams.

flowchart TB
    subgraph QUIC["HTTP/3 sobre QUIC"]
        S1["Stream 1: Paquete 1 ✓ → Procesamiento continúa"]
        S2["Stream 2: Paquete 2 ✗ (pérdida)<br/>→ Solo este stream espera retransmisión"]
        S3["Stream 3: Paquete 3 ✓ → Procesamiento continúa"]
    end

    Note["Independiente entre streams"]

    style S2 fill:#ff9,stroke:#f90

Conexión 0-RTT

La reconexión a servidores previamente conectados se acelera.

sequenceDiagram
    participant C as Cliente
    participant S as Servidor

    Note over C,S: TCP + TLS tradicional
    C->>S: 1. TCP SYN
    S->>C: 2. TCP SYN-ACK
    C->>S: 3. TCP ACK + TLS ClientHello
    S->>C: 4. TLS ServerHello
    S->>C: 5. TLS Finished
    C->>S: 6. Inicio de envío de datos

    Note over C,S: QUIC 0-RTT
    C->>S: 1. QUIC Initial (información de sesión anterior + datos)
    Note over C,S: Es posible enviar datos desde el primer paquete

Migración de conexión

La conexión se puede mantener incluso si cambia la dirección IP.

flowchart LR
    subgraph Traditional["Tradicional"]
        T1["WiFi"] --> T2["Red móvil"]
        T2 --> T3["Cambio de IP"]
        T3 --> T4["Conexión interrumpida"]
        T4 --> T5["Reconexión"]
    end

    subgraph QUIC["QUIC"]
        Q1["WiFi"] --> Q2["Red móvil"]
        Q2 --> Q3["ID de conexión se mantiene"]
        Q3 --> Q4["Continúa sin interrupciones"]
    end

    style T4 fill:#f99,stroke:#f00
    style Q4 fill:#9f9,stroke:#0f0

Comparación de rendimiento

Aspecto	HTTP/1.1	HTTP/2	HTTP/3
Número de conexiones	Múltiples necesarias	1 conexión	1 conexión
Bloqueo HoL	Presente	Parcialmente resuelto	Resuelto
Establecimiento de conexión	Lento	Lento	Rápido
Tolerancia a pérdida de paquetes	Baja	Baja	Alta
Soporte móvil	Débil	Normal	Fuerte

Verificación del soporte

// Verificación en el navegador
if (window.performance) {
  const entries = performance.getEntriesByType('navigation');
  console.log(entries[0].nextHopProtocol);
  // → "h2" (HTTP/2) o "h3" (HTTP/3)
}

# Verificación con curl
curl -I --http2 https://example.com
curl -I --http3 https://example.com

Ejemplo de configuración de servidor

Nginx (HTTP/2)

server {
    listen 443 ssl http2;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
}

Cloudflare (HTTP/3)

Si usas Cloudflare, puedes habilitar HTTP/3 desde el panel de control.

Resumen

HTTP/2 mejoró significativamente los problemas de HTTP/1.1 mediante la multiplexación y la compresión de cabeceras. HTTP/3, con el protocolo QUIC, refuerza aún más la tolerancia a la pérdida de paquetes y el soporte móvil. Para los sitios web modernos, se recomienda el soporte de HTTP/2 o superior.

← Volver a la lista