Antes de falar no novo protocolo Web criado pelo Google, uma pergunta simples:
Você sabe qual a missão do Google?
R – Organizar toda informação do mundo
Pretensioso? Só o tempo poderá dizer, mas a turma do “do not be evil” (lema do Google) não pára de inovar. Desta vez ele criaram um novo protocolo que diminui a latência (atraso) no carregamento das páginas Web, melhorando sensivelmente a experiência de navegar na Internet.
O novo protocolo chama-se “SPDY” (em inglês pronuncia-se “speedy“, como aquele produto de uma operadora de telefonia… …só que este, ao contrário do outro, até agora funcionou sem panes).
E o que a turma do Google obteve em ganho de performance não foi pouco:
- Aumento de 64% no carregamento das páginas (testes em laboratório com os 25 websites mais visitados do mundo)
É um “HTPP Speedy Gonzales“!
É um substituto do HTTP?
Não. O Google faz questão de deixar isto bem claro. O SPDY é parte da iniciativa “Let’s Make the Web Faster“, que tem como objetivo aumentar a velocidade de carga das páginas em 50%.
Tanto o Web server quanto o browser precisam ser “SPDY enabled”. Claro, o Google já tem uma versão do Chrome que entende “SPDY” e vai lançar em breve (SIC) uma versão do “SPDY enabled” Web server (claro que será open-source).
Segundo o draft do protocolo, pouca ou nenhuma mudança será feita nas aplicações Web (ufa!).
Qual o problema com o HTTP?
Nenhum, a questão que o HTTP não foi planejado para resolver problemas de latência. E as páginas dinâmicas e carregadas de conteúdo, flash, vídeos etc, em nada se compara àquelas de 10 anos atrás (veja a 1a. página Web).
Alguns dos problemas do HTTP:
- Uma requisição por conexão. Um servidos aguarda 500 ms entre conexões para prevenir o reuso do canal TCP para requisições adicionais. Os browsers tem um “quebra-galho” para contornar esta limitação: aumentaram o números de conexões por domínio de 2 para 6
- Apenas o lado cliente pode realizar uma solicitação (request). Mesmo quando o “server” sabe que seu “client” precisa daquele recurso, não há mecanismo de informar o cliente… …o servidor deve aguardar o request
- Request/Response headers não “compactados”. Headers podem variar de 200 bytes até 2K, com 700 – boo bytes na média. Em conexões ADSL onde temos “upload link” bem mais lentos (menor banda), esta latência é relevante
E como o “SPDY” vai ajudar a contornar estes problemas?
- Multiplexed requests. Em português, diferente do HTTP, não haverá limite de requests concorrentes em uma conexão “SPDY”.
- Priorização de requests. Sonho de todo administrador de servidor Web. Isto evita problemas de congestionamento do canal TCP com requisições não prioritárias enquanto os requets mais importantes ficam “na fila”
- Header compactados. Se uma página pode enviar de 50 a 100 subrequests, veja a quantidade de informação redundante e sem utilidade que trafega quando você solicita uma página
Onde está a mágica?
HTTP se baseia em múltiplas conexões para implementar concorrência. O resultado desta abordagem é uma sobrecarga no servidor e um trabalho extra no cliente para evitar esta situação (muitas conexões no servidor).
“SPDY” adiciona uma camada (framing layer) que faz a multiplexação de vários streams concorrentes através de uma única conexão TCP. E este layer é otimizado para o padrão request-response do nosso velho HTTP.
Google tem todos os motivos do mundo para deixar a Internet mundial mais rápida, sem necessidade de grandes mudanças além, é claro, de tentar “emplacar” um novo protocolo que pode (sim!) substituir o HTTP.
Repetindo a pergunta, pretensioso demais? Não sabemos. Agora, você gostaria que a sua nagevação fosse 64% mais rápida? Alguma dúvida?
