Como criar um chat web com WebSockets, Spring e SockJS

A web tem sido largamente construída em torno do chamado paradigma de request/response (requisição/resposta) da HTTP. Um cliente carrega uma página web e, em seguida, nada acontece até que o usuário clique para a próxima página.

Por volta de 2005, o Ajax começou a fazer a web ficar mais dinâmica, com seus processamentos assíncronos, sem a necessidade de recarregar as páginas sempre que algo deve ser buscado no servidor.

Ainda assim, toda a comunicação HTTP sempre foi dirigida pelo cliente, o que exigia a interação do usuário ou de sondagem periódica (existem vários algoritmos JavaScript para isso) para carregar novos dados a partir do servidor, como por exemplo nos casos de páginas de jornais ou notícias que precisam mostrar ao cliente informações em tempo real sem que o mesmo precise estar recarregando a página o tempo todo.

A solução via Ajax, se beneficiava de um recarregamento simples que simulava o click no botão de load do browser via JavaScript. Todavia, as tecnologias que permitem ao servidor enviar dados para o cliente, no exato momento em que ele sabe que novos dados estarão disponíveis, é algo bem recente no universo de programação front-end.

Os nomes mais comuns para defini-las são "Push" ou "Comet" (essa última representa um novo modelo de protocolo, baseado no HTTP, que permite ao servidor enviar dados para um browser, sem a necessidade de uma requisição).

Um dos hacks mais comuns para criar a ilusão de uma conexão de servidor iniciada é chamado de long polling (ou chamada seletiva, em tradução livre). Com ele, o cliente abre uma conexão HTTP com o servidor que a mantém aberta até que o envio da resposta seja efetuado.

Sempre que o servidor realmente tem novos dados ele envia a resposta (outras técnicas envolvem Flash, requests multipart do tipo XHR e os chamados HtmlFiles).

O long polling e as outras técnicas funcionam muito bem. Um dos usos mais famosos desse tipo de tecnologia está no chat do Gmail, já que o Google adota a mesma em várias de suas ferramentas e soluções.

No entanto, todas estas soluções alternativas compartilham um problema: elas precisam lidar com o overhead (sobrecarga) que a HTTP traz consigo, o que as tornam inadequadas para aplicações de baixa latência. Por exemplo, pense em um jogo multiplayer de tiro em primeira pessoa no browser ou qualquer outro jogo on-line com componentes em tempo real; o protocolo HTTP é muito pesado para lidar com o tráfego de tantas informações pesadas e oferecer um retorno eficiente ao mesmo tempo.

Para ir de encontro a esse problema, o W3C lançou em meados de 2011 a tecnologia dos WebSockets, que basicamente é um novo protocolo que fornece canais de comunicação full-duplex (nas duas direções – servidor e cliente) sobre uma conexão TCP (Transmission Control Protocol).

O TCP é o protocolo núcleo do IPS (Internet Protocol Suite), famoso pela sua combinação com o IP (Internet Protocol) para formar o modelo mais usado nas redes de computadores: TCP/IP. Ele é extremamente mais rápido que o HTTP e, ao contrário deste, não precisa criar pacotes de cabeçalhos e configurações nas requisições para que o servidor reconheça os pedidos e devolva respostas apropriadas.

A tecnologia em si é dividia em duas partes: a WebSocket API (que fornece todo o código fonte necessário para implementações via JavaScript) e o WebSocket Protocol (que padroniza a forma como todos os browsers devem implementar a tecnologia).

Na seção Links do artigo você encontra as URLs oficiais de cada parte. Ambas são um padrão no mundo front-end e, portanto, estão disponíveis nos principais browsers do mercado, como Chrome, Safari, IE e Firefox.

Enquanto os WebSockets foram projetados originalmente para ser implementados em ambos navegador e servidor web, os mesmos fornecem benefícios arquiteturais significativos para o ambiente cliente-servidor em si, mas também para arquiteturas de aplicações móveis que precisam se comunicar diretamente com os servidores, ou entre os próprios dispositivos.

Na Figura 1 temos uma representação de como os WebSockets estão arranjados dentro da web. A melhor maneira de pensar no WebSocket é como uma camada de transporte no topo do qual qualquer outro protocolo pode ser executado.

A API do WebSocket suporta a capacidade de definir sub-protocolos: bibliotecas do protocolo que possam interpretar protocolos mais específicos. Exemplos destes incluem XMPP, STOMP e AMQP.

Desta forma, os desenvolvedores não têm que pensar em termos de paradigma solicitação-resposta da HTTP, mas em vez disso, eles podem escolher o protocolo mais apropriado para o tipo de aplicações que estão escrevendo.

O único requisito do lado do navegador é executar uma biblioteca JavaScript que pode interpretar os pacotes do WebSocket, estabelecer e manter uma conexão com o mesmo e interpretar protocolos específicos que venham a ser usados.

No lado do servidor, o padrão da indústria é a utilização de bibliotecas do protocolo existentes que rodam em cima do TCP e que implementam algum gateway WebSocket de terceiros, como os protocolos da Kaazing WebSocket Gateways, por exemplo.

Figura 1. Arquitetura dos WebSockets.

As implementações nos lados cliente e servidor que temos exibidas na figura usam bibliotecas específicas para tratar os WebSockets. Na Tabela 1 você encontra uma relação das tecnologias que os suportam, suas APIs oficiais e a URL para cada uma.