HTTP/2 e HTTP/3 - A Evolucao dos Protocolos Web | Conceitos

A Evolucao do HTTP

O HTTP e o protocolo fundamental da Web. Comecou com o HTTP/0.9 em 1991 e evoluiu ate o HTTP/3 atual.

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 do HTTP/1.1

Head-of-Line Blocking

Em uma unica conexao TCP, as requisicoes precisam ser processadas em ordem.

sequenceDiagram
    participant C as Cliente
    participant S as Servidor

    Note over C,S: HTTP/1.1 - Processamento Sequencial
    C->>S: Requisicao 1
    S-->>C: Resposta 1
    C->>S: Requisicao 2
    S-->>C: Resposta 2
    C->>S: Requisicao 3
    S-->>C: Resposta 3

    Note over C,S: Se uma requisicao anterior bloquear,<br/>as seguintes tambem ficam aguardando

Necessidade de Multiplas Conexoes

Para garantir paralelismo, os navegadores usam de 6 a 8 conexoes TCP por dominio.

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

    Note["Overhead de conexao, desperdicio de recursos"]

Caracteristicas do HTTP/2

Multiplexacao (Multiplexing)

E possivel processar multiplas requisicoes/respostas em paralelo em uma unica conexao TCP.

flowchart TB
    subgraph TCP["HTTP/2: Conexao TCP Unica"]
        subgraph Requests["Requisicoes (Paralelas)"]
            R1["Req 1"]
            R2["Req 2"]
            R3["Req 3"]
            R4["Req 4"]
        end
        subgraph Responses["Respostas (Paralelas)"]
            S1["Res 1"]
            S2["Res 2"]
            S3["Res 3"]
            S4["Res 4"]
        end
        R1 --> S1
        R2 --> S2
        R3 --> S3
        R4 --> S4
    end

    Note["Processamento paralelo, sem dependencia de ordem"]

Protocolo Binario

Mudanca do formato baseado em texto do HTTP/1.1 para 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 (Frame Binario)"]
        Header["Length | Type | Flags"]
        StreamID["Stream ID"]
        Payload["Payload"]
        Header --> StreamID --> Payload
    end

Compressao de Cabecalhos (HPACK)

Comprime cabecalhos de forma eficiente e omite cabecalhos duplicados.

flowchart LR
    subgraph First["Primeira Requisicao"]
        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 Requisicao"]
        S1[":path: /style.css"]
        S2["(Os demais sao iguais aos anteriores, omitidos)"]
    end

    First --> Second
    Note["Reducao significativa no tamanho dos cabecalhos"]

Server Push

O servidor pode enviar recursos antes que o cliente os solicite.

sequenceDiagram
    participant C as Cliente
    participant S as Servidor

    C->>S: Requisicao index.html
    S-->>C: Resposta index.html
    S-->>C: Push style.css (enviado sem requisicao)
    S-->>C: Push script.js

    Note over C,S: Reducao do RTT

Observacao: O Server Push nao e muito utilizado na pratica e foi desabilitado a partir do Chrome 106.

Controle de Prioridade

E possivel definir prioridades nos streams para processar recursos importantes primeiro.

flowchart TB
    subgraph Priority["Controle de Prioridade"]
        S1["Stream 1 (HTML): Prioridade Alta"]
        S2["Stream 2 (CSS): Prioridade Alta"]
        S3["Stream 3 (Imagem): Prioridade Baixa"]
    end

    S1 & S2 --> Load["Carregar HTML/CSS primeiro"]
    S3 -.-> Load

Problemas do HTTP/2

O Head-of-Line Blocking no nivel TCP nao foi resolvido.

flowchart TB
    subgraph TCP["HTTP/2 sobre TCP"]
        P1["Pacote 1 ✓"]
        P2["Pacote 2 ✓"]
        P3["Pacote 3 ✗ (Perda de pacote)"]
        P4["Pacote 4 ✓ → Aguardando na camada TCP"]
        P5["Pacote 5 ✓ → Aguardando na camada TCP"]
    end

    P3 --> Block["Uma perda de pacote<br/>bloqueia todos os streams"]

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

HTTP/3 e QUIC

O HTTP/3 usa o protocolo QUIC (construido sobre UDP) em vez do TCP.

Caracteristicas do QUIC

flowchart TB
    subgraph Traditional["Tradicional"]
        T_App["Camada de Aplicacao: HTTP/2"]
        T_Trans["Camada de Transporte: TCP + TLS"]
        T_Net["Camada de Rede: IP"]
        T_App --> T_Trans --> T_Net
    end

    subgraph HTTP3["HTTP/3"]
        H_App["Camada de Aplicacao: HTTP/3"]
        H_Trans["Camada de Transporte: QUIC<br/>(UDP + TLS 1.3 integrado)"]
        H_Net["Camada de Rede: IP"]
        H_App --> H_Trans --> H_Net
    end

Independencia de Streams

Cada stream e independente, e a perda de um pacote nao afeta os outros streams.

flowchart TB
    subgraph QUIC["HTTP/3 sobre QUIC"]
        S1["Stream 1: Pacote 1 ✓ → Processamento continua"]
        S2["Stream 2: Pacote 2 ✗ (Perda)<br/>→ Apenas este stream aguarda retransmissao"]
        S3["Stream 3: Pacote 3 ✓ → Processamento continua"]
    end

    Note["Streams independentes entre si"]

    style S2 fill:#ff9,stroke:#f90

Conexao 0-RTT

Reconexoes a servidores previamente conectados sao mais rapidas.

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 do envio de dados

    Note over C,S: QUIC 0-RTT
    C->>S: 1. QUIC Initial (informacoes da sessao anterior + dados)
    Note over C,S: Envio de dados possivel desde o primeiro pacote

Migracao de Conexao

A conexao e mantida mesmo quando o endereco IP muda.

flowchart LR
    subgraph Traditional["Tradicional"]
        T1["WiFi"] --> T2["Rede Movel"]
        T2 --> T3["Mudanca de IP"]
        T3 --> T4["Conexao Interrompida"]
        T4 --> T5["Reconexao"]
    end

    subgraph QUIC["QUIC"]
        Q1["WiFi"] --> Q2["Rede Movel"]
        Q2 --> Q3["ID de Conexao Mantido"]
        Q3 --> Q4["Continuacao Transparente"]
    end

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

Comparacao de Performance

Aspecto	HTTP/1.1	HTTP/2	HTTP/3
Numero de conexoes	Multiplas necessarias	1 conexao	1 conexao
Bloqueio HoL	Presente	Parcialmente resolvido	Resolvido
Estabelecimento de conexao	Lento	Lento	Rapido
Resistencia a perda de pacotes	Baixa	Baixa	Alta
Suporte a dispositivos moveis	Fraco	Normal	Forte

Verificando Compatibilidade

// Verificacao no navegador
if (window.performance) {
  const entries = performance.getEntriesByType('navigation');
  console.log(entries[0].nextHopProtocol);
  // → "h2" (HTTP/2) ou "h3" (HTTP/3)
}

# Verificacao com curl
curl -I --http2 https://example.com
curl -I --http3 https://example.com

Exemplo de Configuracao do 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)

Se voce estiver usando Cloudflare, pode habilitar o HTTP/3 pelo painel de controle.

Resumo

O HTTP/2 melhorou significativamente os problemas do HTTP/1.1 com multiplexacao e compressao de cabecalhos. O HTTP/3 fortalece ainda mais a resistencia a perda de pacotes e o suporte a dispositivos moveis atraves do protocolo QUIC. Para sites modernos, e recomendado o suporte a HTTP/2 ou superior.

← Voltar para a lista