O servidor Jetty ganhou suporte ao protocolo SPDY em várias das suas versões. Com a versão 7.6.2 do Jetty, o SPDY (lê-se "speedy") é agora suportado por esse servidor. Inicialmente previsto para a inclusão na versão 8.2, o suporte ao SPDY foi portado de volta para as versões 7.6.2 e 8.1.2. Há suporte também para o Jetty Hightide.
O SPDY é uma evolução da camada de transporte para conexões HTTP, disponível por padrão no Google Chrome e através de uma opção de configuração no Firefox. Embora ainda não seja um padrão, foi submetido para o Internet Engineering Task Force (IETF) como uma proposta inicial para o httpbis working group. Muitos dos serviços do Google estão disponíveis através do SPDY e outros sites (como o Webtide e o Twitter) disponibilizam suporte ao protocolo.
O SPDY funciona sobre o protocolo Transport Layer Security (TLS) com uma atualização através da proposta de aprimoramento do Next Protocol Negotiation para a especificação do TLS. Como resultado, o protocolo é inerentemente seguro; além disso, proxies HTTP que atualmente permitem tráfego através da porta 443, e que não realizam a inspeção "man-in-the-middle", irão suportar o SPDY de forma transparente.
Para entender os benefícios que o SPDY irá acrescentar, o InfoQ.com entrevistou Greg Wilkins e Simone Bordet, ambos do projeto Jetty:
InfoQ: De onde vêm as melhorias de velocidade do SPDY?
Greg Wilkins: Há vários aspectos do SPDY que trarão melhorias no desempenho. Primeiramente, dado que o SPDY utiliza uma conexão multiplexada, a latência associada à criação de novas conexões (até seis conexões por navegador) não existirá. E devido à compressão dos cabeçalhos do HTTP, são economizadas centenas de bytes em cada requisição/resposta. Considerando que cada página executa dez, vinte ou mais requisições ao todo, é uma redução significativa. Além disso, com a redução do número de conexões necessárias devido à utilização do SPDY, o total de recursos utilizados por cliente no servidor diminui, liberando memória e processador para outras tarefas.
Mas note que há também desvantagens. O SPDY requer a utilização do TLS e de compressão, e exige o uso adicional de CPU e memória. No entanto, isso é o tipo de coisa que pode facilmente ser delegada para intermediários de SPDY, caso a carga adicional da CPU se torne um problema.
Simone Bordet: A conexão multiplexada também traz algumas vantagens no carregamento de recursos. Uma página web simples possui de dez a trinta recursos secundários que precisam ser entregues pelo servidor. Embora atualmente um navegador possa executar somente seis requisições concorrentes ao mesmo servidor, com o SPDY esse limite deixa de existir, e o navegador pode executar quantas requisições forem necessárias. Isso acelera o carregamento da página consideravelmente e remove a necessidade de utilizar técnicas como a de HTTP pipeline. Além disso, streams multiplexados podem ser priorizados, favorecendo recursos mais importantes, como o CSS, no lugar de recursos de menor relevância, como favicons. Isto, por sua vez, melhora a utilização da conexão TCP, resultando também em melhoria de desempenho do TCP.
A habilidade de multiplexar streams sem o limite de seis conexões deixa as aplicações web de tempo real (baseadas na técnica Comet) menos acopladas aos detalhes de implementação. Hoje, uma aplicação web Comet deve garantir não exceder o limite de quatro a seis conexões; mais uma vez, com o SPDY esse limite não existe.
InfoQ: Há benchmarks que demonstrem a diferença entre o SPDY e o HTTP com relação à performance?
Greg Wilkins: Para o Jetty, ainda não. O Google observou melhorias na latência, de mais de 60% por carregamento de página, mas ainda não demonstrou como a CPU ou a memória foram afetadas.
Quanto ao Jetty, nossa implementação inicial está mais relacionada com a arquitetura da aplicação, que não foi projetada para HTTP com multiplexação; por isso não esperamos melhoras significativas de performance. No entanto, já estamos trabalhando no jetty-9, que está sendo projetado para conexôes no estilo SPDY. Esperamos ter alguns números com relação à performance em breve e que essas informações continuem apoiando melhorias conforme trabalhamos no jetty-9.
InfoQ: Qual o impacto do SPDY em proxies HTTP com caching? Há planos para um servidor SPDY com caching?
Greg Wilkins: Haverá um enorme impacto. Os proxies HTTP existentes não serão capazes de ver o interior do fluxo de dados do SPDY, por estar criptografado. Porém, o SPDY possui um ótimo suporte a caching, devido aos seus mecanismos de busca e inferência de conteúdo, para antecipação de recursos que o cliente deverá precisar. Mas qualquer cache de um proxy teria de "entender" o SPDY e ser parte de um sessão SSL. Assim, algumas extensões TLS provavelmente serão necessárias para permitir intermediários ativos em uma conexão SPDY.
InfoQ: Há mudanças necessárias, no código ou em configurações de uma aplicação web, para suportar o SPDY no Jetty?
Greg Wilkins: O SPDY atua através de requisições HTTP, logo não é necessária nenhuma mudança nas aplicações atuais, e a semântica de requisição/resposta também é mantida. Ocasionalmente haverá chamadas para aplicações diretamente na camada do SPDY, mas por ora pode-se considerar que a mudança é transparente para as aplicações.
Simone Bordet: As aplicações web existentes poderão realizar o deploy no Jetty exatamente da mesma maneira que antes, e serão beneficiadas com a maioria das vantagens do SPDY, tais como compressão do cabeçalho e multiplexação de streams, tudo isso sem mudanças. Somente as confgurações do servidor precisarão ser atualizadas, mas as mudanças são mínimas: apenas uma substituição do conector SSL pelo conector do SPDY (org.eclipse.jetty.spdy.http.HTTPSPDYServerConnector).
InfoQ: Como os clientes atualizam suas conexões HTTP para o SPDY? Isto é feito de forma transparente nas classes de cliente HTTP do Jetty?
Greg Wilkins: Uma conexão SPDY é estabelecida abrindo uma conexão TLS na porta 443, utilizando extensões do Next Protocol (NPN). Se o servidor entender a extensão NPN, perceberá que uma conexão SPDY está sendo oferecida e poderá aceitá-la. Do contrário, a conexão volta a ser considerada uma conexão HTTP normal.
A extensão NPN ainda não é um padrão e não é suportada pelas JVMs. Simone tem trabalhado para estender o suporte do OpenJDK ao NPN. Esperamos que logo isto se torne um padrão e passe a ser suportado por todas as JVMs.
Simone Bordet: Ainda não integramos o SPDY ao HttpClient do Jetty, mas oferecemos um cliente SPDY, que pode ser utilizado para realizar chamadas SPDY para servidores que suportem o protocolo. Por conta disso, a organização em camadas do HTTP tem de ser feita manualmente pelo cliente, por enquanto.
Outra característica interessante do SPDY é poder enviar recursos para o cliente antes mesmo que o cliente realize a requisição. Por exemplo, quando o servidor faz o download de uma página HTML, ele pode perceber que a página contém um arquivo CSS, um arquivo JavaScript, imagens etc. O servidor pode então começar o download de algumas linhas do HTML, então enviar o CSS, voltar ao download de mais algumas linhas, enviar o JS, fazer o download de mais algumas linhas, enviar as imagens... até completar a tarefa. Esse processo economiza muitos roundtrips e resulta em grandes ganhos na renderização da página.
Há uma discussão em andamento sobre como o servidor pode ser avisado sobre esses recursos adicionais. As soluções vão desde adicionar arquivos de metadados (como por exemplo, um arquivo chamado index.html.spdy contendo os recursos a serem enviados para a página index.html); até o perfil de requisições em tempo de execução pelo servidor, preenchendo um "cache por recurso" com recursos secundários que sempre são requisitados depois do recurso primário; e assim por diante. Se os servidores irão ou não implementar essas funcionalidades, depende da implementação do servidor; mas o importante é que o SPDY possibilita diversas otimizações do lado do servidor que são impossíveis somente com HTTP.
Um último aspecto é que nos navegadores o SPDY é completamente integrado a todas as características do HTTP; ou seja, integra-se não apenas nas requisições que vêm da barra de endereços do browser, mas também via XMLHttpRequest.
InfoQ: É possível que os clientes e servidores utilizem o SPDY para fazer requisições adicionais, além do HTTP, para o servidor enviar informações via push, por exemplo?
Greg Wilkins: Ainda não é possível fazer isso através do navegador, mas do lado do servidor pode-se acessar o SPDY diretamente. Ainda veremos se o navegador irá expor a semântica do SPDY, ou o protocolo continuará escondido sob a camada de aplicações, como o HTTP e o WebSockets.
InfoQ: Para ter uso universal, o SPDY precisaria se tornar um padrão IETF, em vez de um projeto do Google. Há uma RFC que especifique o protocolo em seu estágio atual? Seria um problema o Google deter o SPDY como uma marca registrada?
Greg Wilkins: Primeiramente, quero parabenizar o Google pela maneira com que conduz o projeto. De várias maneiras, o uso do SPDY poderia ser considerado como um abuso de poder do Google, dado que a empresa estaria utilizando seu browser (o Chrome) e seus serviços na web para forçar um novo protocolo proprietário. Por outro lado, O Google tem sido muito claro quanto às intenções com relação ao desenvolvimento do protocolo. O SPDY foi um projeto do Google por mais de dois anos e os desenvolvedores permaneceram próximos da comunidade para ouvir e considerar as contribuições para o projeto.
Partiu do Google a iniciativa de se levar o protocolo ao IETF para padronização, e já foi submetido um esboço de especificação voltado ao grupo httpbis. Acho que a abordagem tomada até agora se encaixa bem com as preferências de padrões do IETF, que são baseadas em consenso e código funcionando.
Há realmente algumas questões sobre se isto é um uso ou um abuso do poder do Google, mas não acredito que precisamos ficar tão preocupados, pois o protocolo já foi levado ao IETF num tempo razoável. É importante lembrar que não existem funcionalidades oferecidas que sejam amarradas ao SPDY. Se não gostar do SPDY, você pode bloquear o protocolo e obter os mesmos serviços através do HTTP com um pouco mais de latência.
InfoQ: O Jetty também suporta WebSockets como um mecanismo genérico para comunicação, o qual usa HTTP para o transporte de frames. Pode explicar quais as diferenças entre o SPDY e o WebSocket, e se os dois pretendem se juntar no futuro?
Greg Wilkins: O WebSockets, assim como o HTTP, deve ser considerado de duas maneiras: a semântica da troca de comunicação e o protocolo para transporte dessa semântica. O WebSocket introduz datagramas bidirecionais para o navegador web e oferece um protocolo para transportar os datagramas de/para o servidor. Assim como o SPDY substitui o protocolo de transferência pelo HTTP, ele pode ser utilizado para substituir o protocolo de transferência para o WebSocket. Já existe uma proposta e uma implementação, ainda em beta, para o WebSocket sobre o SPDY.
Para conhecer mais sobre o Jetty e o SPDY, visite os sites oficiais do servidor e do protocolo.