[Este artigo foi editado e expandido pela equipe do InfoQ Brasil]
Nos últimos dois anos tem havido interesse crescente no protocolo WebSockets, atualmente parte do HTML5. Seja no questionamento sobre como funciona dentro da infraestrutura da web ou se suporta serviços web RESTful, parece que o WebSockets está aqui para ficar. E como toda novidade, a tecnologia também tem os seus problemas, por exemplo potenciais vulnerabilidades.
Entretanto, já que uma das motivações do WebSockets é a necessidade de se melhorar o desempenho de interações via web, ele também tem concorrentes. O principal seria o protocolo SPDY do Google, que está sendo considerado pelo Grupo de Trabalho HTTPbis como um candidato em potencial para o HTTP 2.0.
Até o momento foi dada pouca atenção à questão de se o WebSockets e o SPDY competem dentro dos mesmos segmentos e aplicações, e qual seria a melhor alternativa em cada caso. A impressão é de co-existência e cooperação, como afirma Brit Gardnet:
Os dois protocolos são na verdade complementares. O WebSockets faz sua inicialização (handshake) com os servidores usando HTTP para descobrir se o protocolo ws:// é suportado, e uma das principais otimizações do SPDY é comprimir e fazer cache de cabeçalhos HTTP. [...] Então, em um futuro ideal, uma web RESTful seria comandada pelo SPDY, e a comunicação em tempo real e outros protocolos de aplicações seriam encapsulados sob WebSockets. Isso uniria o útil ao agradável.
Em março de 2012 o Google liberou o documento "Encapsulando WebSockets sob SPDY/3" (WebSockets Layering over SPDY/3), indicando que a convivência das duas tecnologias sendo considerada pela empresa.
Por outro lado, em 2009, Mark Nottinghan, o coordenador do HTTPbis, fez um comentário sugerindo que WebSockets e o SPDY poderiam ter futuros separados:
Houve um sentimento forte dentro do IETF nesta semana, em Hiroshima, que deveria ser iniciado um Grupo de Trabalho para a padronização do WebSockets. Se o SPDY seguir o caminho do WAKA, é possível que alguns dos casos de uso planejados para os WebSockets venham a ter outro rumo.
E em junho deste ano, Lori MacVittie, que havia levantado as potenciais vulnerabilidades no WebSockets citadas anteriormente, participou de uma discussão mais aprofundada via Twitter sobre a questão de SPDY versus WebSockets. Assim como Mark Nottinghan, MacVittie vê a resposta ao "dilema" nos modos diferentes em que cada protocolo utiliza o HTTP:
A resposta à pergunta "Por que não considerar o WebSockets aqui?" poderia ser dada em duas palavras: cabeçalhos HTTP. Também poderia ser respondida em três: impacto na infraestrutura. [...] Devido a uma pequena (embora profunda) diferença entre as duas implementações, a tecnologia de WebSockets tem menos chances de gerar impacto sobre a web, tendo maior chance de ter impacto nos datacenters.
Lori MacVittie acredita que, apesar de os dois protocolos serem similares em alguns aspectos (assincronicidade, conexão TCP única, uso de compressão), um protocolo como o SPDY teria mais probabilidade de dominar a próxima geração da web do que o WebSockets.
Ambos os protocolos funcionam "fora" do HTTP e utilizam um mecanismo de promoção (upgrade) para iniciarem. Enquanto que o WebSockets usa os cabeçalhos da requisição HTTP para solicitar uma promoção, o SPDY usa a Negociação do Próximo Protocolo (Next Negotiation Protocol), uma melhoria proposta para a especificação TLS. Esse mecanismo melhora a compatibilidade retroativa, permitindo que sites suportem ao mesmo tempo a nova geração de aplicações e o HTTP tradicional. [...] O WebSockets não usa cabeçalhos HTTP, mas o SPDY usa. Esta diferença aparentemente simples tem impacto inversamente proporcional na infraestrutura de rede.
Na verdade, Lori MacVittie acredita que os vínculos mais fracos do WebSockets com o HTTP podem tornar o WebSockets "mais trabalho do que vale a pena", pelo menos para interações envolvendo firewalls.
Embora ambas as especificações demandem gateways de tradução até que sejam adotados plenamente, o WebSockets tem impacto muito mais intenso na infraestrutura intermediária, se comparado com o SPDY. O WebSockets efetivamente deixa "cega" a infraestrutura.
Qualquer serviço dependente de cabeçalhos HTTP para determinar o tipo de conteúdo ou a localização do objeto requisitado - Firewalls, sistemas de detecção de intrusão, ADC, antivírus - é incapaz de inspecionar ou validar requisições do WebSockets devido à falta de cabeçalhos HTTP. É verdade que o SPDY não torna isso fácil, pois os cabeçalhos HTTP são comprimidos, mas não o torna tão difícil, pois o gzip é bem conhecido e até mesmo dispositivos intermediários seriam capazes de descompactar e recompactar os dados com relativa facilidade (e sem necessidade de informações adicionais, como acontece no em SSL/TLS, em que seriam necessários certificados).
Além disso, já que o SPDY não elimina cabeçalhos HTTP, Lori MacVittie considera que a tecnologia seria mais segura (pressupondo que se concorde com as preocupações dela a respeito de segurança com WebSockets). E novamente, o SPDY seria mais fácil de adaptar à infraestrutura existente:
O SPDY pode ser habilitado em um datacenter inteiro, com o uso de um único componente: um gateway SPDY. Já o WebSockets exige explicitamente a atualização ou substituição de muitos outros serviços e introduz discos que podem ser inaceitáveis para várias organizações.
Lori MacVittie conclui afirmando que as diferenças no modo que o WebSockets e o SPDY usam cabeçalhos HTTP significam que as melhorias de desempenho trazidas pelo SPDY terão adoção bem mais ampla. Para ela, o uso de WebSockets será restrito ao interior das empresas. Entretanto, dado que boa parte da infraestrutura corporativa é baseada em HTTP, a adoção do WebSockets pelas empresas também não será tão fácil.
Nos comentários ao artigo original no InfoQ.com, Cameron Purdy da Oracle alerta que a diferença mais importante entre as duas tecnologias é que todo servidor e todo cliente HTTP irão suportar WebSockets (por conta do padrão ser parte do HTML5), e que essa ubiquidade garantiria a adoção ampla do WebSockets. Já se pode questionar se existe realmente competição entre SPDY e WebSockets, visto que o WebSockets não atende aos casos de uso normais do HTTP, ao contrário do SPDY. Além disso, o SPDY não fornece comunicação síncrona bidirecional, que seria a maior motivação para o uso do WebSockets. Mas certamente o debate irá continuar.