Para atender a essa necessidade, o WebSocket, um protocolo de comunicação popular finalizado em 2011, permite que sites enviem e recebam dados sem demora. Com o WebSockets, você pode construir jogos multiplayer, aplicativos de bate-papo e software de colaboração que funcionem…

A comunicação perfeita é uma obrigação na web moderna. À medida que as velocidades da internet aumentam, esperamos nossos dados em tempo real. Para atender a essa necessidade, o WebSocket, um protocolo de comunicação popular finalizado em 2011, permite que sites enviem e recebam dados sem demora. Com o WebSockets, você pode construir jogos multiplayer, aplicativos de bate-papo e software de colaboração que funcionam na web aberta.

 

 

 

Construí vários projetos com WebSockets antes de começar a me perguntar o que exatamente estava acontecendo sob o capô. Essa pergunta me levou a um buraco de coelho de pesquisa, e estou animado para compartilhar o que aprendi com você. Neste artigo, vamos:

 

explorar o problema Que os WebSockets resolvem e olham para alternativas

 

olhar sob o capô para entender como WebSockets funcionam

 

revisar algum código simples para um aplicativo alimentado pelo WebSocket

 

falar através de algumas implementações do mundo real

 

No final desta peça, você deve se sentir confortável discutindo como os WebSockets funcionam, e talvez até inspirado a usá-lo em seu próximo projeto.

 

Mensagens na internet

 

Vamos começar com o básico: o WebSocket é uma tecnologia que permite ao cliente estabelecer comunicação bidirecional (“full-duplex”) com o servidor. (Uma rápida revisão: o cliente é o aplicativo no computador de um usuário, e o servidor é o computador remoto que armazena o site e os dados associados).

A palavra-chave nessa definição é bidirecional:com o WebSocket, tanto o cliente quanto o servidor podem acionar a comunicação entre si, e ambos podem enviar mensagens, ao mesmo tempo. Por que isso é importante? Para apreciar totalmente o poder do WebSocket, vamos dar um passo atrás e olhar para algumas maneiras comuns de que os computadores podem obter dados do servidor.

 

Solicitação-resposta

 

Em um sistema HTTP tradicional, que é usado pela maioria dos sites hoje, um servidor web foi projetado para receber e responder a solicitações de clientes via mensagens HTTP. Essa comunicação tradicional só pode ser iniciada em uma direção: do cliente ao servidor. O código do servidor define que tipo de solicitações o servidor deve esperar e como responder a cada uma delas. Uma metáfora comum para este tipo de comunicação é uma cozinha de restaurante. É mais ou menos assim:

 

Você (o cliente) faz um pedido (uma solicitação HTTP) que um garçom leva para a cozinha (o servidor).

 

A cozinha recebe o pedido e verifica se eles sabem como fazê-lo (o servidor processa a solicitação).

 

Se a cozinha sabe como fazer o prato, eles preparam o pedido (o servidor busca dados de um banco de dados ou ativos do servidor).

 

Se a cozinha não reconhecer a ordem ou não for permitida a servi-la, eles enviam o garçom de volta com más notícias (se o servidor não sabe ou não responder à solicitação, ele envia de volta um código de erro, como um 404).

 

De qualquer forma, o garçom retorna para você (você recebe uma resposta HTTP com um código associado, como 200 OK ou 403 Proibido).

 

O importante a notar aqui é que a cozinha não tem ideia de quem vem a ordem. A maneira técnica de dizer isso é que “HTTP é apátrida”: trata cada novo pedido como completamente independente. Temos maneiras de contornar isso — por exemplo, os clientes podem enviar cookies que ajudam o servidor a identificar o cliente, mas as próprias mensagens HTTP são distintas e são lidas e cumpridas de forma independente.

Eis o problema: a cozinha não pode mandar um garçom para você; ele só pode dar ao garçom um prato, ou más notícias, quando você enviar o garçom mais. A cozinha não tem nenhum conceito de você— apenas as ordens que entram. Na fala do servidor, a única maneira de os clientes obterem informações atualizadas do servidor é enviar solicitações.

Imagine um aplicativo de bate-papo onde você está falando com um amigo. Você envia uma mensagem para o servidor, como uma solicitação com algum texto como carga útil. O servidor recebe sua solicitação e armazena a mensagem. Mas não tem como falar com o computador do seu amigo. O computador do seu amigo também precisa enviar uma solicitação para verificar novas mensagens; só então o servidor pode enviar sua mensagem.

Do jeito que está, você e seu amigo — ambos os clientes — precisam verificar constantemente as atualizações do servidor, introduzindo atrasos estranhos entre cada mensagem. Isso é bobagem, certo? Quando você envia uma mensagem, você quer que o servidor ping seu amigo imediatamente para dizer “Ei, você tem uma mensagem! Aqui está!” A resposta à solicitação HTTP funciona muito bem quando você precisa carregar uma página estática, mas é insuficiente quando sua comunicação é sensível ao tempo.

 

Votação curta

 

Uma solução simples para este problema é uma técnica chamada votação curta. Basta ter o cliente pingando o servidor repetidamente, digamos, a cada 500ms (ou sobre algum atraso fixo). Dessa forma, você recebe novos dados a cada 500ms. Há algumas desvantagens óbvias para isso: há um atraso de 500ms, ele consome recursos do servidor com uma enxurrada de solicitações, e a maioria das solicitações retornará vazia se os dados não forem atualizados com frequência.

 

Votação longa

 

Outra solução alternativ