Reduzindo a latência do HTTP com o SPDY

O Google revelou um projeto de código aberto experimental no início de novembro, com o objetivo de reduzir o tempo de carregamento de sites. O SPDY é uma modificação do HTTP feita para lidar com situações reais e específicas de latência sem alterar a semântica do GET, do POST ou de qualquer outro tipo de solicitação, e sem exigir alterações no conteúdo das páginas ou da infraestrutura da rede. Para fazer isso, ele implementa prioridades em solicitações, multiplexação de fluxos e compactação de cabeçalhos. Testes com um Chrome e com um servidor web habilitados para o SPDY mostram uma redução no tempo de carregamento de até 60%.

O SPDY é parte da iniciativa “Vamos tornar a web mais rápida” do Google, que também inclui projetos com foco na velocidade do JavaScript, na medição do desempenho e nas ferramentas de análise. Mike Belshe e Roberto Peon anunciaram o SPDY no dia 11 de novembro nos blogs do Chromium e do Google Research, observando que o “HTTP é um protocolo elegantemente simples que surgiu como um padrão web em 1996 após uma série de experimentos. O HTTP vem servindo à web incrivelmente bem. Queremos continuar trabalhando na tradição de experimentação e otimização da web, para ampliar o suporte à evolução dos sites e navegadores.“

Encontrando a latência no HTTP

O documento técnico sobre o SPDY detalha a análise do grupo sobre a latência na web, começando com o comentário de que embora as solicitações de páginas e respostas dependam tanto do HTTP como protocolo de camada de aplicativo quanto do TCP como protocolo de camada de transporte, seria inviável implementar alterações no TCP. Já as experiências com o HTTP, por outro lado, exigem apenas navegadores e servidores compatíveis, e os testes podem ser feitos em condições de rede reais.

O grupo apontou quatro fatores que seriam as maiores fontes de latência no HTTP. Primeiro, depender de uma única solicitação por conexão HTTP implica em um uso pouco eficiente dos canais TCP, forçando os navegadores a abrirem várias conexões HTTP para enviar solicitações e causando sobrecarga. Segundo, o tamanho dos cabeçalhos HTTP descompactados, que correspondem a uma porção significativa do tráfego HTTP devido ao grande número de solicitações HTTP em uma mesma página. Terceiro, o envio de cabeçalhos redundantes, como o Agente de Usuário e o Host – que continuam os mesmos em uma sessão. Por fim, a dependência exclusiva do cliente para iniciar todas as solicitações HTTP, quando há casos em que o servidor sabe que conteúdo relacionado será solicitado, mas não posso impôr esse conteúdo ao cliente.

O SPDY lida com essas fraquezas multiplexando um número ilimitado de fluxos simultâneos em uma única conexão TCP, permitindo que o cliente atribua prioridades às solicitações HTTP para evitar o congestionamento de canais e compactando a solicitação HTTP e os cabeçalhos de resposta com compactação gzip, além de omitir a transmissão de cabeçalhos redundantes. A versão preliminar da especificação SPDY também inclui opções para que servidores iniciem a entrega de conteúdo. Os métodos disponíveis são o “server push”, no qual o servidor inicia a transmissão de um recurso através de um cabeçalho X-Associated-Content, e o “server hint”, no qual o servidor apenas sugere recursos relacionados ao cliente com o X-Subresources.

Além disso, o SPDY foi desenvolvido para rodar sobre o SSL, porque a equipe achou que seria melhor tornar a segurança parte da implementação agora do que adicioná-la mais tarde. Além disso, como o SPDY exige que os agente suportem a compactação gzip para os cabeçalhos, ele também compacta os dados HTTP com o gzip.

O que é importante é observar que as alterações do SPDY só afetam a maneira como os dados são trocados entre o cliente e o servidor; não há alterações no protocolo HTTP atual que um dono de site possa notar. Ou seja, o SPDY não é um substituto do HTTP, mas sim um conjunto de possíveis melhorias.

Os comentários nos blogs indicam que embora a maioria das pessoas notem a importância da compactação dos cabeçalhos e do uso de prioridades nas solicitações, alguns ainda estão céticos quanto à necessidade de multiplexar solicitações HTTP em uma única conexão TCP. Já foram tentadas alternativas no passado, e podemos destacar o pipeline de HTTP e o Protocolo SCTP.

O documento trata desses dois casos. Segundo ele, o SCTP é um protocolo de camada de transporte desenvolvido para substituir o TCP, e embora ofereça algumas melhorias, não resolveria os problemas do próprio HTTP, e é isso o que o SPDY tenta fazer. Implementar o SCTP exigiria grandes mudanças nas pilhas de rede do cliente e do servidor, e também na estrutura da web. O mesmo vale para soluções semelhantes de camada de transporte, como o SST, soluções de camada intermediária como o MUX e substitutos ao HTML como o BEEP.

O problema com o pipeline, segundo o documento, é que mesmo com múltiplas solicitações em pipeline em uma conexão HTTP, a conexão inteira continua sendo do tipo primeiro-a-entrar-primeiro-a-sair, e um pacote perdido ou o atraso no processamento de uma solicitação causa atraso em todas as solicitações subsequentes no pipeline. Além disso, o pipeline de HTTP é de difícil implementação para proxies web, e continua desabilitado por padrão na maioria dos navegadores. No entanto, a abordagem totalmente multiplexada adotada pelo SPDY permite intercalar múltiplas solicitações e respostas HTTP em qualquer ordem, ocupando com maior eficiência o canal TCP. Um pacote perdido ainda teria que ser retransmitido, mas outras solicitações poderiam continuar sendo realizadas sem que pausas fossem necessárias. Uma solicitação que exija processamento no lado do servidor formaria um gargalo em um pipeline HTTP, mas o SPDY pode continuar a responder a solicitações de dados estáticos através do canal enquanto o servidor trabalha em solicitações mais lentas.

Implementação e resultados dos testes

A equipe de desenvolvimento escreveu um servidor web SPDY e adicionou o suporte para cliente em uma árvore do Chrome, para em seguida realizar testes servindo conteúdo típico dos cem sites mais acessados por meio de conexões DSL simuladas e conexões de internet domésticas via cabo. O teste incluiu execuções com e sem SSL, com domínio único e com múltiplos domínios e com os métodos server push e server hint. Os tempos de carregamento das páginas foram menores em todos os cenários, numa redução que ia de 27,93% a 63,53%.

O objetivo declarado da equipe é obter uma redução de 50%; a média dos testes publicados em todas as suas variações foi de 48,76%. Embora considere os resultados iniciais promissores, a equipe também lista diversos problemas, a começar pela falta de modelos de comportamento de perda de pacotes em situações reais que sejam bem compreendidos.

Mas o SPDY ainda é uma experiência, e a equipe quer opiniões sobre várias questões que estão em aberto, como uma forma de lidar com a latência introduzida pelos handshakes do SSL, com a recuperação de uma conexão TCP perdida e a melhor maneira de implementar a lógica do lado do servidor para que haja aproveitamento real do server push e do server hint. As pessoas interessadas são encorajadas a ingressar na lista de discussão e baixar o código.

Até agora, só está disponível o código do cliente do Chrome modificado, e pelo repositório público do Subversion, não nos downloads binários. Peon diz que a versão para servidores sai logo, e a página do projeto diz que o pacote de testes e o código de medições de desempenho usado no testes do Google também será lançado sob uma licença de código aberto.

Uma redução de 50% nos tempos de carregamento não é pouca coisa, especialmente quando todos os ganhos são provenientes de ajustes na conexão HTTP e no comportamento da transferência de dados. Só a compactação de cabeçalhos já proporciona economias notáveis; o documento afirma que ela resultou em uma “redução de aproximadamente 88% no tamanho dos cabeçalhos de solicitações e de aproximadamente 85% no tamanho dos cabeçalhos de resposta.” O futuro da web talvez inclua novos protocolos como o SCTP e o BEEP, mas o SPDY já está mostrando que há muito o que melhorar sem alterações dramáticas na pilha de protocolos.