WebSocket é uma tecnologia integral em muitas aplicações web modernas. Se você escreve código para a web, provavelmente já ouviu o termo antes, mas talvez não tenha certeza do que exatamente é ou como usá-lo. Felizmente, o WebSocket não é um conceito complexo, e você pode obter um entendimento básico dele rapidamente.
O que é WebSocket?
WebSocket, infelizmente, é um daqueles nomes que não parecem fazer sentido à primeira vista. WebSocket é na verdade o nome de um protocolo de comunicação que permite a comunicação bidirecional entre o cliente e o servidor web.
Em termos mais simples, WebSocket é uma tecnologia que permite que um cliente e um servidor criem uma conexão onde qualquer uma das partes pode enviar uma mensagem à outra a qualquer momento.
Isso é diferente de uma conexão HTTP normal, onde o cliente deve iniciar uma solicitação e somente então o servidor pode enviar uma resposta. Na verdade, o WebSocket é um protocolo de comunicação completamente diferente do HTTP que foi projetado para ser compatível com HTTP. Quando um aplicativo cliente deseja iniciar uma conexão WebSocket, ele precisa usar o
Mecanismo de atualização HTTP para mudar para o protocolo WebSocket.Neste ponto, você pode estar pensando: "um protocolo é apenas um conjunto de regras, como você pode usar isso para codificar?".
A peça que falta é algo chamado pilha de protocolos. Essencialmente, os dispositivos que suportam um protocolo têm hardware e software integrados que permitem escrever aplicativos que se comunicam usando o protocolo. O protocolo não é usado diretamente para construir nada.
Por que o WebSocket foi criado?
Para ilustrar a necessidade do WebSocket, considere o mecanismo por trás do bate-papo na Internet.
Alguém envia uma mensagem para o servidor de bate-papo de seu dispositivo, mas o servidor ainda precisa enviar essa mensagem para seu dispositivo antes que você possa lê-la. Se o servidor usa HTTP, o servidor não pode encaminhar essa mensagem diretamente para você, porque o servidor não pode iniciar solicitações.
Existem algumas maneiras de corrigir esse problema com HTTP. Uma maneira é o cliente enviar constantemente solicitações de atualização para o servidor, e o servidor encaminhará todos os dados que tiver na resposta. Essa técnica é chamada de polling e cada solicitação é chamada de polling. Existem duas variantes de sondagem: sondagem longa e sondagem curta.
Usar a variante de sondagem longa significa que o dispositivo cliente está constantemente perguntando ao servidor se alguma nova mensagem está disponível. Se novas mensagens estiverem disponíveis, o servidor enviará as mensagens como resposta. Caso contrário, o servidor atrasaria a resposta e manteria a conexão aberta até que tivesse dados para enviar de volta e, em seguida, o cliente faria uma nova solicitação imediatamente.
Essa técnica é ineficiente, porque o HTTP não foi projetado para ser usado dessa maneira. Ele funciona adequadamente em pequena escala, mas cada solicitação HTTP envolve o envio de dados extras no cabeçalho e resulta em uma carga significativamente maior no servidor quando muitos clientes estão pesquisando isto.
Aqui está um diagrama que ilustra uma sondagem longa:
A variante de sondagem curta é ainda menos eficiente. Na pesquisa curta, o servidor não mantém a conexão aberta até que haja novos dados, o que significa que o cliente precisa continuar pesquisando o servidor em intervalos fixos e muito curtos.
Outra técnica para comunicação bidirecional em HTTP é chamada de streaming.
No streaming, após o envio da primeira solicitação, o servidor mantém a conexão aberta indefinidamente, enviando novas informações como respostas parciais contínuas ao cliente.
O uso de streaming resulta em uma sobrecarga de dados e carga de servidor menores do que a pesquisa, porque, idealmente, o cliente faz apenas uma solicitação HTTP. Infelizmente, o streaming cria problemas sob certas condições porque navegadores e intermediários de rede (como proxies) geralmente tentam lidar com o respostas parciais como partes quebradas de uma grande resposta HTTP (que é um comportamento HTTP normal), em vez de como as mensagens separadas que deveriam ser ser.
O WebSocket foi criado para resolver esses problemas. Ao contrário do HTTP, o WebSocket foi projetado especificamente para comunicação bidirecional. Com o WebSocket, uma vez que uma conexão é aberta, o cliente e o servidor podem enviar mensagens para frente e para trás sem os problemas de polling ou streaming.
Casos de uso para WebSocket
O WebSocket é ótimo, mas isso não significa que deva ser usado em todos os lugares.
A implementação do WebSocket pode adicionar complexidade ao seu aplicativo, especialmente no lado do servidor, portanto, isso não deve ser feito a menos que você tenha um bom motivo. Isso levanta a questão: como é uma boa razão?
O WebSocket é ideal para casos de uso em que é necessária comunicação bidirecional frequente com baixa latência. Em outras palavras, o WebSocket oferece uma vantagem para aplicativos que precisam se comunicar com frequência ou em grande escala. Se a comunicação não precisar ser em tempo real ou o aplicativo nunca crescer em grande escala, a sondagem ou o streaming podem ser suficientes para uso nesse aplicativo.
Os usos típicos do WebSocket são na criação de aplicativos de bate-papo, jogos multiplayer online, colaboração em tempo real e software de notificação, etc.
Como usar o WebSocket no lado do cliente
O uso do WebSocket no lado do servidor pode ser bastante complicado, e o processo varia substancialmente dependendo do idioma (como C#, Java, etc.) e a biblioteca de sua escolha, portanto, não a abordaremos aqui. A seguir, discutiremos brevemente como usar o WebSocket no lado do cliente.
Todos os navegadores modernos implementam uma API da Web chamada API WebSocket, que é a pilha de protocolos do navegador para o protocolo WebSocket. Você pode usar WebSocket em JavaScript usando esta API. A API permite criar um objeto WebSocket, por meio do qual você cria uma conexão WebSocket e interage com o servidor WebSocket.
Você pode usar o seguinte formato de código para criar um objeto WebSocket:
deixe exemploSocket = new WebSocket("wss://www.example.com/socketserver", "dummyProtocol");O primeiro argumento para o construtor é o URI do servidor WebSocket com o qual você deseja criar uma conexão. Ele sempre começará com "ws" ou "wss". O segundo argumento é opcional. Seu valor é uma string ou uma matriz de strings, que especifica os subprotocolos aos quais você dá suporte.
O objeto WebSocket tem uma propriedade somente leitura chamada readyState. Acessar essa propriedade fornece o estado atual da conexão WebSocket. readyState tem quatro valores possíveis: "connecting", "open", "closing" e "closed".
Quando essa linha de código for executada, o navegador tentará se conectar ao servidor especificado. A conexão não será concluída de uma vez, então o readyState de exampleSocket estará "conectando". Nenhuma mensagem pode ser enviada ou recebida até que a conexão seja concluída, quando o valor de readyState se tornará "aberto".
o exemploSoquete objeto tem um ouvinte de evento (que é diferente de Ouvintes de eventos DOM) chamado "onopen" que permite que você execute outras ações somente após a conexão ter sido estabelecida. O objeto também possui um método "send" que permite enviar strings, Blobs (dados binários) e ArrayBuffers como mensagens para o servidor.
Aqui está um exemplo usando-os juntos:
exampleSocket.onopen = função (evento) {
exemploSoquete.send("WebSocket é muito legal");
};A API também fornece uma maneira de você reagir às mensagens que o servidor envia. Isso é feito com o ouvinte de eventos "onmessage". Aqui está um exemplo:
exampleSocket.onmessage = função (evento) {
console.registro(evento.dados);
}Em vez disso, você também pode escrever uma função de seta:
exampleSocket.onmessage = (evento) => { console.log (evento.dados); }A API também fornece um perto() método para fechar a conexão. Aqui está o que parece:
exemploSoquete.perto();WebSocket permite comunicação bidirecional eficiente
WebSocket é um protocolo de comunicação bidirecional. Servidores e navegadores implementam pilhas de protocolos para se comunicar usando WebSocket. O WebSocket existe porque o HTTP não foi projetado para ser bidirecional. Existem métodos para implementar conexões bidirecionais com HTTP, mas eles apresentam problemas.
O WebSocket é uma tecnologia poderosa, mas não é necessária em todos os casos, pois pode complicar significativamente a arquitetura do aplicativo. O uso do WebSocket no lado do cliente é feito com a API WebSocket do navegador.
