SOA, Simples Assim!

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?