O Google e a Microsoft querem aperfeiçoar o protocolo HTTP com o SPDY e o Speed+Mobility. Este artigo revisa ambas as propostas destacando quais benefícios trazem ao protocolo mais utilizado na Internet.
Junto com a W3C, o Internet Engineering Task Force (IETF) está coordenando os esforços relacionados a rede de roteamento, transporte e segurança do HTTP, incluindo a proposta de especificação para a RFC 2616.
Mais de doze anos se passaram desde que a última versão do HTTP foi adotada. Alguns defendem que agora o HTTP deve ser reforçado a fim de enfrentar as necessidades desta época. Propostas foram submetidas ao IETF para a formulação do HTTP 2.0, incluindo o SPDY do Google e o HTTP Speed+Mobility da Microsoft. Ambas as propostas mencionadas são retrocompatíveis com as versões anteriores do protocolo.
O Google está tentando tratar os problemas de velocidade existentes no HTTP 1.1:
Um dos gargalos das implementações do HTTP é a sua dependência de múltiplas conexões para tratar concorrência. Esta característica causa muitos problemas, incluindo comunicações adicionais para o estabelecimento da conexão, desperdício de tempo provocado pelo algorítmo de Início-lento, e racionamento de conexão pelo cliente, cuja finalidade é prevenir a abertura excesiva de conexões para um único servidor.
Por estas razões, o SPDY:
...adiciona uma camada de enquadramento para potencializar a multiplexação e as transmissões concorrentes através de uma única conexão TCP (ou qualquer transmissão de transporte confiável). A camada de enquadramento é otimizada para comunicações requisição-resposta, como no HTTP, para que as aplicações que rodam atualmente sobre o HTTP possam trabalhar sobre o SPDY com pouca ou nenhuma alteração para o desenvolvedor destas aplicações web.
Na prática, o SPDY traz 4 grandes melhorias para o HTTP 1.1: Requições multiplexadas; Requisições priorizadas; Cabeçalhos comprimidos; e Server Pushed Streams. O SPDY já está implementado e em produção, embora o protocolo ainda seja uma proposta. O Google utiliza o SPDY através de diversos dos seus serviços no Chrome. Outras implementações do protocolo SPDY são: o módulo SPDY do Apache; o servidor SPDY para node.js; o Netty; o Firefox; o Amazon Silk; e em breve o Ngnix.
A Microsoft propôs uma especificação para o HTTP 2.0 que irá tratar problemas relacionados, principalmente, a velocidade, mas também a questões relacionadas a mobilidade, partindo do SPDY até os WebSockets. Em uma troca de e-mails com a InfoQ Americana, Adalberto Foresti, gerente sênior do Programa de Tecnologias Abertas e signatário da proposta da Microsoft, disse que "O SPDY fez um grande trabalho de sensibilização para o desempenho da web e traz uma abordagem "repensada do zero" para aperfeiçoar o HTTP, tornando a web mais rápida".
A proposta da Microsoft altera o SPDY simplificando "as mensagens de controle de sessão para remover itens que são redundantes para os frames de controle dos WebSockets, quebra a compatibilidade com a semântica HTTP atual, ou implementa conceitos mais bem endereçados na camada de rede".
O HTTP Speed+Mobility da Microsoft também adiciona duas seções destinadas a melhorar o uso do HTTP através da "Internet das Coisas", considerando o consumo de CPU, a bateria e recursos do dispositivo, segurança, entre outros aspectos. A seção 1.1.4, chamada "O cliente está no controle do conteúdo", especifica:
Devido a variedade de clientes na Internet e ao número de cenários de conexão, os clientes estão em melhor posição para definir o conteúdo que deseja obter. O navegador ou a aplicação tem informações de primeira mão sobre o que o usuário está fazendo e que dados já estão disponíveis localmente. Por exemplo, a maioria dos navegadores em uso atualmente possuem mecanismos de cache poderosos que devem ser aproveitados para armazenar elementos da web que mudam com uma frequência baixa.
As propostas para o HTTP 2.0 não devem forçar o navegador ou aplicação a obter conteúdos que não foram requisitados e que já possam estar cacheados. Além disso, o cliente deve ter a opção de rejeitar conteúdos não desejados ou desnecessários. Os clientes precisam da habilidade de informar o servidor sobre elementos cacheados que não precisam ser baixados. Idealmente, este feedback do cliente para o servidor permitiria uma aprovação incremental do conteúdo, permitindo uma extensão eficiente do "push" para entregar o conteúdo correto, com segurança e formatação adequada.
Na seção 1.1.5, chamada "O custo de rede e de energia", os autores tratam da questão do consumo de energia e banda:
A escolha entre velocidade, custo, e energia não é algo simples. Às vezes, a velocidade pode ser o fator mais importante. Em outras, o custo de banda ou a durabilidade da bateria podem ser os fatores decisivos. O HTTP 2.0 deve permitir que os desenvolvedores otimizem a forma como utilizam o HTTP de acordo com as restrições de seus domínios (que podem mudar ao longo do tempo) ao invés de impor uma solução monolítica para um problema genérico....
Os objetivos de aumento de velocidade, redução de custos e economia de energia podem, muitas vezes, ser alinhados. Por exemplo, tendo menos dados enviados via cabo as páginas podem ser carregadas mais rapidamente, permite que o rádio desligue mais cedo e consuma menos banda. Porém, dada a variedade de cenários onde o HTTP 2.0 será usado, o alinhamento desses objetivos nem sempre será obtido. Dispositivos cuja bateria esteja prestes a acabar, ou cuja capacidade de cache esteja próxima de seu limite, podem ter sua experiência de usuário melhorada através da desativação das atualizações "server push", preservando as demais otimizações disponíveis no HTTP 2.0. Portanto, o grupo de trabalho da nova especificação deve considerar energia e custos, bem como a velocidade.
Com intenção de abordar as questões que foram mencionadas, a Microsoft propõe utilizar um upgrade de WebSocket para inicialização, manutenção e definição de sessões. A especificação contém, ainda, todos os detalhes de baixo nível esperados de um documento desta finalidade.
A Microsoft submeteu a sua proposta de especificação durante o 83o encontro da Força Tarefa para Engenharia da Internet (IETF), ocorrido em Março deste ano e ainda implementaram um protótipo open-source, como prova de conceito, permitindo que os desenvolvedores avaliassem a proposta do HTTP Speed+Mobility. O código pode ser encontrado no GitHub.
Resta, agora, ver o que a indústria irá escolher para implementar. De acordo com o Processo de Padrões do IETF, "uma especificação passa por um período de desenvolvimento, de várias iterações de revisão por parte da comunidade da Internet, e também por revisões baseadas na experiência. É adotada, então, como padrão pelo órgão competente ... e, por fim, é publicada."
Conteúdo relacionado: SPDY ou WebSockets: complementares ou concorrentes?