BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Google trabalha em um Protocolo Destinado a substituir HTTP

Google trabalha em um Protocolo Destinado a substituir HTTP

Favoritos

O Google propõe SPDY, um novo protocolo de aplicação executado em cima do SSL, um protocolo para substituir o HTTP, que é considerado por introduzir latências. Eles já criaram um protótipo com um servidor web e um navegador Chrome aperfeiçoado que supostamente carrega páginas da web, duas vezes mais rápido.

Iniciativa do Google, "Vamos tornar a web mais rápida", lançada há algum tempo atrás que visa melhorar a velocidade na Internet. A iniciativa abrange vários domínios, desde a construção de um servidor web mais rápida ate a construção de um navegador mais rápido. Por exemplo, o Page Speed é uma ferramenta utilizada para melhorar a páginas da web de modo que elas sejam baixadas mais rapidamente. O Google abriu o código de uma série de ferramentas e tutoriais publicados para ajudar os desenvolvedores de todo o mundo a melhorar a velocidade de seus sites.

Mas o Google não parou por aí. Eles jogam com um protocolo novo aplicativo chamado SPDY, pronunciado SPeeDY, que, se bem sucedido e amplamente adotado, substituiria o HTTP no que seria uma revisão de todo o backbone da Internet. O whitepaper SPDY menciona a ideia de ir para baixo da pilha e substituir o protocolo de transporte (TCP) por um melhor, mas reconhecem que seria muito difícil de implementar, de modo que pretendem melhorar o protocolo de aplicação HTTP.

O Whitepaper SPDY menciona uma série de limitações no protocolo HTTP introduzindo latência na entrega de página:

  • Pedido único por conexão. Como o HTTP só pode buscar um recurso de cada vez (HTTP pipelining ajuda, mas ainda impõe apenas uma fila FIFO), um atraso de 500 ms servidor impede a reutilização do canal TCP para solicitações adicionais.  Navegadores contornam esse problema usando conexões múltiplas.  Desde 2008, a maioria dos navegadores, finalmente, passou de 2 conexões por domínio a 6.
  • Client-iniated requests exclusivas. Em HTTP, apenas o cliente pode iniciar uma solicitação. Mesmo se o servidor sabe que o cliente precisa de um recurso, ele não tem nenhum mecanismo para informar o cliente e deve esperar em vez de receber uma solicitação para o recurso do cliente.
  • Requisições não compactadas e cabeçalhos de resposta. Cabeçalhos de requisições hoje variam em tamanho de ~200 bytes a mais de 2KB. As aplicações utilizam mais cookies e os agentes do utilizador ampliam os recursos, os tamanhos de cabeçalho típicos de 700-800 bytes é comum. Para modems ou conexões ADSL, em que a conexão banda larga é bastante baixa, esta latência pode ser significativa. Reduzir os dados nos cabeçalhos pode melhorar diretamente a latência de serialização para enviar pedidos.
  • Cabeçalhos redundantes. Além disso, vários cabeçalhos são repetidamente enviado através de visitas no mesmo canal. No entanto, cabeçalhos, como o User-Agent, Host e Accept* são geralmente estáticos e não precisam ser reenviados.
  • Compressão de dados opcional. HTTP usa a codificação de compressão de dados opcional. Conteúdo sempre devem ser enviados em um formato compactado.

Um dos objetivos do SPDY é reduzir o tempo de carregamento da página em 50%, tornando a navegação duas vezes mais rápido. Apesar de algumas centenas de milésimos de segundo poder não significar muito para um usuário, cada milissegundo vai contar para os aplicativos web altamente interconectados em um futuro próximo. O conteúdo da web atual não é afetado pela introdução do novo protocolo, apenas os servidores web e seus clientes precisam de ser melhorados para fazer uso dele.

O que exatamente o Google quer com SPDY?

  • Permitir muitas solicitações simultâneas de HTTP para funcionar através de uma única sessão TCP.

  • Reduzir a largura de banda atualmente utilizadas pelos cabeçalhos HTTP, compactar e eliminar os cabeçalhos desnecessários.

  • Definir um protocolo que é fácil de implementar e eficiente no servidor. Temos esperança de reduzir a complexidade do HTTP através da redução dos casos de borda e definição de formatos de mensagens facilmente interpretados.

  • Tornar o SSL em um protocolo transporte fundamental, para melhor segurança e compatibilidade com a infra-estrutura de rede existente. Embora a SSL não introduz uma penalidade na latência, acreditamos que o futuro a longo prazo da web depende de uma conexão de rede segura. Além disso, o uso de SSL é necessário para garantir que a comunicação através de proxies existentes não estará quebrada.
  • Habilitar o servidor para iniciar a comunicação com o cliente e enviar dados para o cliente, sempre que possível.

Para atingir estes objetivos, SPDY é construído pela adição de uma camada de sessão em cima do SSL permitindo a "múltipla concorrência, streams intercalados por uma única conexão TCP. Os formatos de mensagens HTTP GET e POST permanecem inalteradas, mas spdy propõe um novo formato de enquadramento "para codificação e transmissão dos dados ao longo dos fios". Os fluxos devem ser bi-direcionais, sendo iniciada tanto pelo cliente e o servidor.

Até agora, o Google tem construído um servidor em memória que lida com os protocolos HTTP e SPDY com o código a ser aberto em breve. Além disso, existe uma versão do Chrome modificada, internamente e, dizem, temporariamente chamada código fonte flip (disponível), que funciona tanto com HTTP e SPDY. Eles também criaram um conjunto de ferramentas de teste para se certificar de que as páginas são baixadas corretamente com SPDY. Estas ferramentas serão também lançadas em breve.

Baseado no protótipo, os resultados são promissores procurando até agora:

Nós baixamos 25 dos "top 100" sites através de conexões de rede doméstica simulada, com 1% de perda de pacotes. Nos repetimos os downloads de 10 vezes para cada site, e calculado o tempo de carregamento médio de página para cada site, e em todos os sites. Os resultados mostram um aumento de velocidade sobre o HTTP, de 27% a 60% no tempo de carga de TCP simples (sem SSL), e 39% - 55% em relação ao SSL.

É óbvio que o Google não conseguirá sozinho nessa empreitada, mesmo que crie o melhor protocolo poderá haver. É necessário que a comunidade abrace e junte-se no esforço para criar um protocolo de aplicação. É interessante ver como os outros grandes jogadores irão reagir.

Recursos: Especificação do projeto de protocolo SPDY, SPDY habilitado no Chrome.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT