Dissecando o protocolo HTTP/2.0

Dissecando o protocolo HTTP/2 Rafael Rinaldi

http://rinaldi.io

http://netshoes.com.br

http://sp.femug.com

http://zofe.com.br

Hypertext Transfer Protocol (HTTP)

Base da comunicação de dados na World Wide Web

Comunicação entre o servidor e o client com o intuito
de transferir arquivos

Primeiro draft disponibilizado em 1991

1. Client se conecta ao host; 2. Servidor aceita a
conexão; 3. Client faz requisição de um arquivo; 4. Servidor envia uma resposta.

λ http -v server.com GET / HTTP/1.1 Accept: */* Accept-Encoding:
gzip, deflate Connection: keep-alive Host: server.com User-Agent: HTTPie/0.9.2

λ http server.com HTTP/1.1 301 Moved Permanently Accept-Ranges: bytes Age:
887 Connection: keep-alive Content-Encoding: gzip Content-Length: 298 Content-Type: text/html; charset=iso-8859-1 Date: Thu, 05 Mar 2015 03:24:18 GMT Location: http://www.server.com Server: Apache/2.2.22 (Debian) PHP/5.3.3-7+squeeze25 with OpenSSL/0.9.8o Usou: Cache Vary: Accept-Encoding Via: 1.1 varnish X-Varnish: 180850535 180830146 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html>…</html>

TCP/IP

TCP/IP Internet Protocol

TCP/IP Responsável por conectar uma rede a outra

TCP/IP Transmission Control Protocol

TCP/IP Mecanismo que nos permite transferir dados

A B TCP

IP → TCP → HTTP

HTTP/1.x

Introduzido em 1999 com diversas mudanças drásticas ao primeiro draft

›❯ Conexões persistentes e reutilizáveis; ›❯ Transferência de dados em
blocos; ›❯ Processamento paralelo de requests; ›❯ Mecanismos de cache mais inteligentes.

›❯ Muitas features implementadas, poucas de fato utilizadas; ›❯ Integração
inadequada com o protocolo TCP. ¯\_(ツ)_/¯

A web evoluiu muito e de forma rápida

Um website comum hoje possui tranquilamente mais de 90 dependências

77 725K 1900K 100 Fonte: httparchive.org Últimos 4 anos

Performance se torna o grande gargalo

Otimização

Keep alive

Reutilizar uma única conexão TCP para enviar e receber múltiplos
requests (ao invés de abrir uma nova conexão para cada request)

λ http PUT server.com foo=bar HTTP/1.1 200 OK Connection: keep-alive
Content-Length: 332 Content-Type: application/json Date: Thu, 05 Mar 2015 03:24:18 GMT Location: http://www.server.com Server: Apache/2.2.22 (Debian) PHP/5.3.3-7+squeeze25 with OpenSSL/0.9.8o { isSuccess: true }

›❯ Diminuição do uso de memória e CPU; ›❯ Reduz
congestionamento na rede; ›❯ Reduz latência dos requests posteriores.

No HTTP/1.1 todas as conexões são persistentes (possibilidade de opt-out)

A grande maioria dos browsers modernos implementam esse recurso por
padrão

HTTP Pipelining

Client Servidor

Uma forma de enviar um request enquanto se aguarda a
resposta do anterior (processo síncrono)

Client Servidor

Head-of-line Blocking (HOL Blocking)

Client Servidor Fila de responses ¯\_(ツ)_/¯

HTTP Pipelining não funciona na prática

Até hoje navegadores desktop vem com essa feature desabilitada por
padrão

Domain sharding

O HTTP/1.1 nos permite apenas abrir de 6 a 8
conexões por origem (a primeira spec tinha uma limitação de apenas 2)

Criar novos host names com o objetivo de aumentar o
número de conexões (diminuindo tempo de carregamento)

Utilizando essa técnica, alguns sites conseguem habilitar até 100 conexões
simultâneas

Otimização no front-end

›❯ Concatenação e miniﬁcação de arquivos; ›❯ Utilização de sprites
para imagens; ›❯ Inline de recursos; ›❯ Compressão de imagens.

PageSpeed Module (modpagespeed)

Implementa boas práticas de otimização de performance automaticamente

Disponível para Apache e Nginx

›❯ Reduzir lookup de DNS; ›❯ Reduzir número de requests;
›❯ Servir recursos através de uma CDN; ›❯ Adicionar “Expires header”; ›❯ Compressão GZIP em arquivos baseados em texto; ›❯ Evitar redirecionamento de URL.

Surgiu então a necessidade de se pensar em otimização na
camada de protocolo

Construir algo em cima do HTTP era a única solução
viável

Introduzido em 2009

Prova de conceito do Google de que a otimização na
camada de protocolo era algo positivo e factível

Reduzir latência e melhorar a segurança no tráfego de dados

›❯ Compressão de header via zlib; ›❯ Depende de conexão
segura para funcionar (HTTPS); ›❯ Adotado pela grande maioria dos navegadores modernos; ›❯ Suporte via módulos para web servers populares; ›❯ Introduziu muitos conceitos de melhoria de performance.

HTTP/2

Introduzido em 2012 como uma extensão do SPDY/3

Retrocompatível com a arquitetura do HTTP

Multiplexing

Múltiplos requests rodando em paralelo

Uma única conexão TCP assíncrona

Client Servidor

Binary framing

Headers seguem formato binário

Apenas informações do header que mudam entre requisições são enviadas
(User-Agent, por exemplo, só é enviado uma única vez)

Parsing simples e eﬁciente

Client e servidor conversam através de frames

Streams

Todo frame negociado via HTTP/2 é associado a um stream

Player toca o que já foi carregado (Buffer) O resto
é carregado em paralelo

No HTTP/2 podemos ter centenas de streams simultâneos pois seu
custo é muito baixo

Compressão

Arquivos textuais são comprimidos com GZIP por padrão

Compressão de headers por padrão

Testes com compressão dos headers via GZIP mostraram vulnerabilidades (BREACH
e CRIME)

Um novo formato de compressão foi criado, o HPACK

Priorização

Graças a análise detalhada de dados via streams, conseguimos priorizar
o carregamento de recursos

Browser tem a capacidade de manipular a prioridade de carregamento
com o intuito de otimizar a renderização da página

Server Push

Habilidade de sugerir arquivos a serem carregados

Client Servidor index.html index.html style.css app.js logo.svg

<!DOCTYPE html> <html lang="en"> <head> <style> .inline-css { // ...
} </style> <script> function inlineScript() { // ... } </script> </head> <body> </body> </html>

Inline de recursos, sem gambiarra e com suporte a cache!

<link rel='prefetch' href='//example.com/next-page.html' as='html'> <link rel='prefetch'
href='/library.js' as='script'>

Extensões

A spec do HTTP/2 diz que frames com tipos desconhecidos
devem ser ignorados

Temos nisso a oportunidade de se pensar em plugins e
extensões que podem implementar tipos próprios

Load balancers como Varnish e Squid podem se conectar diretamente
ao protocolo

Deploy

Um dos problemas de se fazer mudanças no protocolo principal
da web é de como será a adoção e a evolução disso

Muito da forma como o controle de tráfego de rede
funciona foi alterada e isso tem potencial para causar problemas

Server

Server Client

Server Client }Middle boxes

A necessidade de se usar SSL com HTTP/2 é uma
forma de contornar isso. (Criptograﬁa vem de brinde)

Tirar proveito das melhorias sem quebrar compatibilidade com a estrutura
atual da web.

Com o TLS/SSL o servidor consegue negociar o uso do
novo protocolo sem quebrar middle boxes

TLS + ALPN =

Mudanças de workﬂow

›❯ Continue miniﬁcando JS, CSS; ›❯ Continue comprimindo imagens; ›❯
GZIP automático; ›❯ Mate bundles de arquivos; ›❯ ES6 modules + HTTP/2 = ❤; ›❯ Server push substitui inline de recursos sem gambiarra; ›❯ Sem necessidade de múltiplos hostnames; ›❯ Cookies em servidores estáticos não são mais problema.

›❯ Retrocompatível; ›❯ Compressão; ›❯ Multiplexing; ›❯ Binary framing; ›❯
Streams; ›❯ Priorização; ›❯ Extensões.

Cenário atual

›❯ Não use componentes de carrossel; ›❯ É bolacha, não
biscoito! ›❯ HTTP/2 é bacon/donut (e não é do Google); ›❯ Brinks com seu servidor HTTP/2 (Node.js, Go, Ruby); ›❯ Servidores mais inteligentes; ›❯ Módulos experimentais para Apache e Nginx; ›❯ Utilize SPDY/HTTP/2 hoje! Pela ciência! ›❯ Acompanhar progresso do QUIC.

http://moourl.com/http2book

Muito obrigado http://rinaldi.io

Dissecando o protocolo HTTP/2.0

Dissecando o protocolo HTTP/2.0

More Decks by Rafael Rinaldi

Other Decks in Technology

Featured

Transcript