Posts sobre: HTTP

Front-end HTTP WPO

Anatomia de uma requisição HTTP

02/12/2011 – 12:23 am

Precisamos conhecer exatamente como as coisas acontecem por debaixo dos panos, só assim conseguiremos otimizar nossas páginas e deixar nossos usuários felizes :) .

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.

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 primeiramente 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

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 esta 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 em sí.

Perceba na figura 3 que só de bater o olho percebemos que mais da metade do tempo gasto nessa requisição foi gasto com REDE!, DNS Lookup, estabelecimento de conexão TCP e TTFB (resumidamente consideramos esse tempo como simplesmente LATÊNCIA).

Conclusão

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

Abraços

Tags , , , , | Comments (3)
HTTP WPO

Content Delivery Network – CDN, Você ainda vai usar uma

26/11/2011 – 9:00 pm

Uma CDN (Content Delivery Network) é uma rede de computadores distribuídos geograficamente com cópias de conteúdos a serem acessados.

A CDN tem dois grandes objetivos o primeiro é tornar mais próximo o conteúdo que esta sendo distribuído e solicitado (Imagens, Stylesheets, Scripts, Flashs, Músicas, PDF’s e etc) dos usuários assim diminuindo o tempo de resposta e latência destes componentes, o segundo é diminuir custos com banda/tráfego de dados (do site que esta utilizando a CDN) e por conseqüência diminuir a quantidade de requisições diretas ao servidor real do site desafogando e muito a infra “local”.

É normal um site sendo acessado de uma país ter grandes diferenças no tempo de resposta das páginas quando acessado de um país vizinho, até mesmo diferenças entre cidades ou bairros. Isto ocorre devido ao roteamento entre as requisições e os servidores que estão sendo solicitados que dependendo do link ou região que o usuário se encontra os saltos são maiores ou menores e com velocidades diferentes também.

Uma solução interessante seria entregar para cada usuário ou região o conteúdo que esteja mais próximo da requisição que esta sendo feita e é justamente ai que uma CDN faz a diferença melhorando incrivelmente a experiência do usuário e o tempo de resposta dos componentes que estão sendo solicitados pelo usuário.

Existem CDN’s comerciais ou pagas e CDN’s gratuitas abaixo listo algumas bem famosas e recomendadas pela indústria.

CDN’s Comerciais:
Akamai
EdgeCast Networks
Limelight Networks

Curiosidade

Daniel M. Lewin um dos fundadores da Akamai estava em um dos vôos do 11 de setembro de 2001 e faleceu.

Conclusão

Aumente a performance do tempo de resposta dos componentes de suas páginas, faça os usuários mais felizes e ainda diminua alguns gastos com o alto tráfego que você tem hoje sem uma CDN pra te dar uma força.

Tags | Comment (1)
HTTP

O porquê não utilizar GET para alterar estado no servidor

04/10/2011 – 9:20 pm

Olá pessoal,

É muito comum (ainda) desenvolvedores Web utilizarem os verbos Http Get e Post de maneira meio que “indiscriminada” para acessarem e/ou buscarem recursos no servidor Web, e digo isso independentemente da tecnologia de servidor que esta sendo utilizada (PHP, ASP.NET, JSF, Rails, Django e etc).

A ideia desse post é simplesmente alertar os desenvolvedores de alguns “perigos” da utilização errada dos verbos para fazer “ações” no servidor.

Em geral devemos pensar nos dois verbos literalmente como nós os lemos, ou seja, GET (SOMENTE para pegar recursos, ok?) e POST (Para postar algo, levar algo ao servidor e provavelmente mudar o estado de algo).

Existem vários motivos de não utilizarmos GET para fazer alterações de estado no servidor, alguns:

  • As requisições podem ser cacheadas
  • Podem ficar no histórico do navegador
  • Podem ser favoritadas
  • São repetíveis naturalmente (Vários F5 tranquilamente sem alerta do browser)

Portanto muito cuidado quando for alterar estado no servidor (adicionar/atualizar/deletar) via GET, pode ser um tanto quanto “perigoso” em alguns casos.

OK então vou sempre utilizar POST para fazer alteração de estado!

Perfeito, mas nesse caso se não fizermos “nada” na resposta dessa requisição teremos um problema chato.

Quem nunca depois de um POST de formulário tentou recarregar a página e PAM! Sim! Alerta do browser dizendo que vai reenviar tudo para o server (outro POST pra ser mais exato, podendo repetir por exemplo a inserção de algo no banco), é eu sei, você assim como eu já passou por isso.

Como resolver?

Até que é fácil, nesse caso devemos utilizar o padrão Post/Redirect/Get (sim é considerado um padrão), dessa forma evitamos esse comportamento chato que sempre acontece, no ASP.NET MVC é bem tranquilo de implementar inclusive.

Bom fica a dica, espero que vocês parem de utilizar GET pra fazer alteração de estado no server =)

Críticas, dúvidas ou sugestões vamos conversar nos comentários.

Comments (3)