PagSeguro
Canais iMasters

Tecnologia + Web Standards

Anatomia de uma requisição HTTP

Muitos fatores podem afetar a performance de uma página: largura de banda, distância entre o cliente e o servidor, tamanho e quantidade de elementos em uma página, como esses elementos são carregados e etc. Precisamos conhecer exatamente como as coisas acontecem por debaixo dos panos, só assim conseguiremos otimizar nossas páginas e deixar nossos usuários felizes.

Devemos começar por algum lugar a procura por gargalos. Existem muitas ferramentas que podem nos ajudar com isso. O que todas elas possuem em comum é o que chamamos de Waterfall chart, um gráfico em cascata que mostra como os elementos da página estão sendo carregados.

Figura 1: Aba Net do FireBug

Figura 2: Waterfall View da ferramenta WebPageTest.org

As duas figuras acima mostram o Waterfall view da página inicial do site do Google. Cada linha da cascata representa um componente de página sendo baixado para o browser do usuário. Perceba que primeiro o HTML é baixado e depois todos os componentes associados a ele (imagens, arquivos CSS, arquivos JS e etc).

No caso da visualização do WebPageTest.org cada componente (linha) tem uma barra com pedaços coloridos que representam diferentes atividades para aquela requisição HTTP, vejamos:

Figura 3: Requisição HTTP

Figura 4: Legenda

DNS Lookup

DNS (Domain Name System) Lookup é o processo de resolução de nome (de domínio) em IP, ou seja, é achar através de uma url, como http://www.google.com.br, o IP associado a mesma, que é o que o browser precisa para fazer a conexão com o servidor remoto.

Um ponto importantissímo é que um DNS Lookup irá acontecer para cada domínio diferente que sua página possa ter associado a ela, por exemplo: http://images.seusite.com.br ,http://static1.seusite.com.br. Cada um desses subdomínios gerará um novo DNS Lookup já que diferentes subdomínios podem estar associados a difentes IP's.

Initial Connection

Todos as requisições HTTP que um browser faz para o servidor são trafegadas através de conexões TCP (Transmission Control Protocol), portanto toda requisição precisa de uma conexão TCP ativa para que se possa baixar os componentes da página.

Para se estabelecer uma conexão TCP um three-way handshake é feito entre o cliente e o servidor através de metadados enviados nos pacotes. Os pacotes do handshake são muito pequenos e depois de enviados e reconhecidos pelas duas pontas a conexão é estabelecida e a transferência do arquivo pode ser iniciada.

Figura 5: Handshake

  1. Browser envia um pacote com o metadado SYN (Sequence Number) para o servidor;
  2. Servidor responde com ACK (Acknowledged) e um outro SYN;
  3. Browser finaliza o cumprimente (handshake) com mais um ACK;
  4. Conexão estabelecida.

Keep-Alive Header

Um novo header foi introduzido no HTTP 1.1 com o intuito de reaproveitar conexões TCP para difentes requisições. Quando utilizamos o header Connection: keep-alive uma conexão TCP aberta e que nao tenha dado timeout ainda será reaproveitada para trafegar outras requisições HTTP, evitando assim o overhead de se estabelecer conexões TCP (handshake).

Figura 6: Visualização de conexões

Perceba que em uma mesma linha diferentes tipos de componentes são trafegados em momentos diferentes, uma mesma conexão TCP é reaproveitada.

Time to First Byte

O Time to First Byte, também conhecido como TTFB, é o tempo que o browser espera para receber o primeiro byte de informação da requisição, em páginas dinâmicas podemos considerar esse tempo a demora do processamento server side, por exemplo. Se o TTFB de uma request está muito alto, investigue, pois pode ser um ponto importante para otimizações (índice de bancos de dados, melhorias de algoritmos na aplicação e etc).

Content Download

Depois de receber o primeiro byte, o “resto” em azul é o tempo de download do componente. Perceba na figura 3 que só de bater o olho percebemos que mais da metade do tempo gasto nessa requisição foi com REDE!, DNS Lookup, estabelecimento de conexão TCP e TTFB (resumidamente, consideramos esse tempo simplesmente como LATÊNCIA).

Conclusão

Digo novamente, nós desenvolvedores web precisamos conhecer muito tudo isso. Esse tipo de conhecimento esta escondido e poucas pessoas têm, ou tentam aprender, mas com certeza saber isso faz de você um melhor desenvolvedor.


Cleber Dantas

Cleber Dantas

é especialista em desenvolvimento web. Atua há 7 anos no mercado de TI registrando passagens por empresas de consultoria, software houses e internet. Adepto ao desenvolvimento ágil de software, possuí as certificações MCAD e MCTS. É palestrante em eventos da comunidade técnica Microsoft (MS Dev Day, MsTechDay, MVC Summit, Saturday Fast Code, TechEd Brasil entre outros). Ministra cursos e workshops sobre tecnologias de desenvolvimento Microsoft. Colaborador dos portais iMasters, Linha de Código e DevMedia. Gosta de escrever sobre ASP.NET (principalmente MVC =D), IIS, desenvolvimento Web em geral, mercado, testes e boas práticas.


Comente também

8 Comentários

Rafael Bilar
Rafael Bilar

Muito bom este artigo. Parabéns Cleber.

Celão
Celão

Se todos os desenvolvedores conhecessem o cenário que envolve a aplicação deles, o mundo seria perfeito! heheheheh

Muito interessante o artigo, parabéns pela iniciativa!

abs

Luiz Estevam
Luiz Estevam

Parabéns pelo artigo.

Diogo Nicoleti
Diogo Nicoleti

Muito bom o artigo. Parabéns.

Roberto Lamartine
Roberto Lamartine

Parabéns !

Fabrizio Gianfratti
Fabrizio Gianfratti

Parabens !

Guilherme Oderdenge
Guilherme Oderdenge

Ótimo artigo. Algumas dúvidas foram sanadas, mas dói a cabeça processar tanta informação.

Tharcisio Marcos F. de Q. Mendonça
Tharcisio Marcos F. de Q. Mendonça

Muito bom! parabéns!

Qual a sua opinião?

Comentários considerados ofensivos serão moderados.

Parceiros

IBM
PagSeguro
Internet Innovation
Dialhost
HostNet
Tecla
KingHost
DotStore
Dinamize