BT
x Por favor preencha a pesquisa do InfoQ !

Jetty ganha suporte ao protocolo SPDY do Google

por Alex Blewitt , traduzido por Vitor Puente em 05 Abr 2012 |

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.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

Percebemos que você está utilizando um bloqueador de propagandas

Nós entendemos porquê utilizar um bloqueador de propagandas. No entanto, nós precisamos da sua ajuda para manter o InfoQ gratuito. O InfoQ não compartilhará seus dados com nenhum terceiro sem que você autorize. Procuramos trabalhar com anúncios de empresas e produtos que sejam relevantes para nossos leitores. Por favor, considere adicionar o InfoQ como uma exceção no seu bloqueador de propagandas.