306

Estou criando um pequeno aplicativo de bate-papo para amigos, mas não tenho certeza de como obter informações em tempo hábil, que não sejam tão manuais ou rudimentares quanto forçar a atualização de uma página.

Atualmente, estou implementando isso usando o AJAX simples, mas isso tem a desvantagem de atingir regularmente o servidor quando um temporizador curto passa.

Ao pesquisar pesquisas longas / curtas, deparei com WebSockets HTML5. Isso parece fácil de implementar, mas eu não tenho certeza se existem algumas desvantagens ocultas. Por exemplo, acho que o WebSockets é suportado apenas por determinados navegadores. Existem outras desvantagens do WebSockets que eu devo conhecer?

Como parece que as duas tecnologias fazem a mesma coisa, em que tipos de cenário uma prefere usar uma sobre a outra? Mais especificamente, o HTML5 WebSockets tornou obsoleta a pesquisa longa / curta do AJAX, ou existem razões convincentes para preferir o AJAX ao WebSockets?

— sombrio
fonte

508

WebSockets é definitivamente o futuro.

A pesquisa longa é uma solução alternativa suja para impedir a criação de conexões para cada solicitação, como o AJAX - mas a pesquisa longa foi criada quando o WebSockets não existia. Agora, devido ao WebSockets, a longa pesquisa está desaparecendo.

O WebRTC permite a comunicação ponto a ponto.

Eu recomendo aprender WebSockets .

Comparação:

de diferentes técnicas de comunicação na web

AJAX - request→ response. Cria uma conexão com o servidor, envia cabeçalhos de solicitação com dados opcionais, obtém uma resposta do servidor e fecha a conexão. Suportado em todos os principais navegadores.
Pesquisa longa - request→ wait→ response. Cria uma conexão com o servidor como o AJAX, mas mantém uma conexão keep-alive aberta por algum tempo (embora não demore muito). Durante a conexão, o cliente aberto pode receber dados do servidor. O cliente precisa se reconectar periodicamente após o fechamento da conexão, devido a tempos limite ou perda de dados. No lado do servidor, ele ainda é tratado como uma solicitação HTTP, igual ao AJAX, exceto que a resposta a pedido ocorrerá agora ou em algum momento no futuro, definida pela lógica do aplicativo. gráfico de suporte (completo) | wikipedia
WebSockets - client↔ server. Crie uma conexão TCP com o servidor e mantenha-a aberta pelo tempo que for necessário. O servidor ou cliente pode facilmente fechar a conexão. O cliente passa por um processo de handshake compatível com HTTP. Se for bem-sucedido, o servidor e o cliente poderão trocar dados nas duas direções a qualquer momento. É eficiente se o aplicativo exigir troca frequente de dados nos dois sentidos. Os WebSockets possuem um enquadramento de dados que inclui mascaramento para cada mensagem enviada do cliente para o servidor, para que os dados sejam simplesmente criptografados. gráfico de suporte (muito bom) | wikipedia
WebRTC - peer↔ peer. Transporte para estabelecer comunicação entre clientes e é independente de transporte, para que ele possa usar UDP, TCP ou ainda mais camadas abstratas. Isso geralmente é usado para transferência de dados de alto volume, como streaming de vídeo / áudio, onde a confiabilidade é secundária e alguns quadros ou redução na progressão da qualidade podem ser sacrificados em favor do tempo de resposta e, pelo menos, de alguma transferência de dados. Ambos os lados (pares) podem enviar dados uns aos outros de forma independente. Embora possa ser usado de forma totalmente independente de qualquer servidor centralizado, ainda requer alguma forma de troca de dados endPoints, onde na maioria dos casos os desenvolvedores ainda usam servidores centralizados para "vincular" pares. Isso é necessário apenas para trocar dados essenciais para estabelecer uma conexão, após o qual não é necessário um servidor centralizado. gráfico de suporte (médio) | wikipedia
Eventos enviados pelo servidor - client← server. O cliente estabelece uma conexão persistente e de longo prazo com o servidor. Somente o servidor pode enviar dados para um cliente. Se o cliente quiser enviar dados para o servidor, seria necessário o uso de outra tecnologia / protocolo para fazer isso. Esse protocolo é compatível com HTTP e simples de implementar na maioria das plataformas do servidor. Este é um protocolo preferível a ser usado em vez da pesquisa longa. gráfico de suporte (bom, exceto IE) | wikipedia

Vantagens:

A principal vantagem do WebSockets no lado do servidor é que não é uma solicitação HTTP (após o handshake), mas um protocolo de comunicação adequado baseado em mensagens. Isso permite obter enormes vantagens de desempenho e arquitetura . Por exemplo, no node.js, você pode compartilhar a mesma memória para diferentes conexões de soquete, para que cada um possa acessar variáveis compartilhadas. Portanto, você não precisa usar um banco de dados como um ponto de troca no meio (como no AJAX ou no Long Polling com uma linguagem como PHP). Você pode armazenar dados na RAM ou até republicar imediatamente entre os soquetes.

Considerações de segurança

As pessoas geralmente se preocupam com a segurança dos WebSockets. A realidade é que faz pouca diferença ou até coloca WebSockets como melhor opção. Primeiro, com o AJAX, há uma chance maior de MITM , pois cada solicitação é uma nova conexão TCP que está atravessando a infraestrutura da Internet. Com o WebSockets, uma vez conectado, é muito mais difícil interceptar, com mascaramento de quadro adicionalmente imposto quando os dados são transmitidos do cliente para o servidor, além de compactação adicional, o que exige mais esforço para investigar os dados. Todos os protocolos modernos suportam: HTTP e HTTPS (criptografados).

PS

Lembre-se de que os WebSockets geralmente têm uma abordagem lógica muito diferente da rede , mais parecida com os jogos em tempo real, e não com http.

— moka
fonte

15

Não se trata de compatibilidade. O mais importante é que esteja prestes a repensar completamente o modo como a comunicação está acontecendo. Como as APIs RESTful funcionam com o padrão Request> Response, a comunicação bidirecional aqui não faz sentido. Portanto, tentar usar o WebSockets para consultar a API RESTful - é uma tentativa um pouco estranha e não vê nenhum benefício disso. Se você precisar de dados da API RESTful, mas de maneira em tempo real, crie uma API do WebSockets para enviar dados que funcionarão com a comunicação bidirecional como WebSockets. Você está tentando comparar coisas no ângulo que eles não são comparáveis :)

— moka

2

Oi @pithhelmet tudo depende do software do lado do servidor (idioma / tecnologia). O WebSocket é sobreposto ao TCP e existem várias maneiras de implementar implementações de fluxo TCP. Servidores web modernos usam arquitetura baseada em eventos e são muito eficientes com conjuntos de threads. Qual tecnologia você está usando? O Node.js usa eventos nos bastidores para E / S e eventos com thread único no contexto de execução, por isso é incrivelmente eficiente. O uso de encadeamentos para cada conexão - é muito ineficiente em termos de RAM (1mb + por encadeamento) e CPU, pois esses encadeamentos ficam ociosos ou pior - loop infinito de verificação de dados.

— Mok

4

A pesquisa longa não é uma solução alternativa suja e é diferente do webSocket. Esses dois devem ser usados em cenários diferentes.

— bagz_man

5

@bagz_man Long Polling é um uso "hacky" da tecnologia para alcançar resultados que a tecnologia não permitia por definição e que não havia alternativa padrão disponível. A razão pela qual a Pesquisa Longa existe é exatamente o fato de o WS não existir, Período.

— moka

4

@moka: o nível gratuito do Cloudflare absorverá um ataque sustentado de 400 + Gbps. Sua carteira pode absorver a conta da AWS? Além disso, a AWS e o Cloudflare têm pontos de vista opostos quando se trata de lidar com reclamações contra sua origem. É apenas algo a ter em mente, desde que discutamos as vantagens e desvantagens. :)

— danneu

11

Uma tecnologia rival que você omitiu é Eventos enviados pelo servidor / Origem do evento. O que são pesquisas longas, Websockets, eventos enviados pelo servidor (SSE) e cometa? tem uma boa discussão sobre tudo isso. Lembre-se de que alguns deles são mais fáceis de integrar do que outros no lado do servidor.

— bmm6o
fonte

De tudo isso, em quem você sugeriria analisar?

— somdow

Eu tive sucesso com pesquisas longas, o único truque (para ele e outras tecnologias) não é amarrar um encadeamento de servidor. Se você não usar código de servidor assíncrono, ele não será escalado.

— bmm6o

1

@somdow Maksims-Mihejevs respondeu bem à sua pergunta nos dois primeiros parágrafos da resposta. Use websockets.

— Jeff Sheffield

7

Para aplicativos de bate-papo ou qualquer outro aplicativo que esteja em constante conversa com o servidor, WebSocketsé a melhor opção. No entanto, você só pode usar WebSocketscom um servidor que os suporte, o que pode limitar sua capacidade de usá-los se você não conseguir instalar as bibliotecas necessárias. Nesse caso, você precisaria usar Long Pollingpara obter funcionalidades semelhantes.

— Brant Olsen
fonte

5

Os WebSockets são suportados por todos os servidores ... Você só precisa instalar o node.js ou algo semelhante.

— Noob

9

Ajustado um pouco para explicar que sim, qualquer servidor suportará WebSockets. No entanto, se você estiver usando o serviço de hospedagem, talvez não consiga usá-lo.

— Brant Olsen

Sei que esse segmento é um pouco antigo, mas ... Os WebSockets podem não ser a melhor resposta para todas as comunicações bidirecionais. Recentemente, notei que a documentação para o suporte a soquetes da Web do Spring 4 sugere que os WebSockets são mais adequados para mover grandes quantidades de dados ou baixa latência. Se essas informações não são aplicáveis ou não são uma prioridade, acredito que sugerem o uso de pesquisas longas. Não conheço a justificativa completa para essa visão, apenas imaginei que o pessoal da Primavera sabe do que está falando em geral.

— Stoney

1

@Stoney, exceto pelo fato de que você precisaria configurar o websocket no servidor (manipuladores, etc.) Simplesmente não há razão para usar a pesquisa longa no websocket. O Websocket é muito mais rápido (baixa latência) e permite que o servidor "converse" com o cliente sem que o cliente solicite. Atualmente, uso o signalr (uma das melhores implementações de websocket já feitas na minha opinião - ele roda no cliente e no servidor e permite que o cliente chame métodos no servidor e o servidor no cliente como se não houvesse diferença) em todos os site que eu faço - carregamento dinâmico de conteúdo, páginas sem fundo, etc.

— DividedByZero

0

Sondagem XHR Uma solicitação é respondida quando o evento ocorre (pode ser imediatamente ou após um atraso). Solicitações subsequentes deverão ser feitas para receber outros eventos.

O navegador faz uma solicitação assíncrona do servidor, que pode esperar pela disponibilidade dos dados antes de responder. A resposta pode conter dados codificados (geralmente XML ou JSON) ou Javascript a serem executados pelo cliente. No final do processamento da resposta, o navegador cria e envia outro XHR, para aguardar o próximo evento. Assim, o navegador sempre mantém uma solicitação pendente com o servidor, para ser respondida à medida que cada evento ocorre. Wikipedia
Eventos enviados pelo servidor O cliente envia uma solicitação ao servidor. O servidor envia novos dados para a página da web a qualquer momento.

Tradicionalmente, uma página da web precisa enviar uma solicitação ao servidor para receber novos dados; isto é, a página solicita dados do servidor. Com os eventos enviados pelo servidor, é possível que um servidor envie novos dados para uma página da web a qualquer momento, enviando mensagens para a página da web. Essas mensagens recebidas podem ser tratadas como Eventos + dados dentro da página da web. Mozilla
WebSockets Após o handshake inicial (via protocolo HTTP). A comunicação é feita bidirecionalmente usando o protocolo WebSocket.

O handshake começa com uma solicitação / resposta HTTP, permitindo que os servidores lidem com conexões HTTP e com conexões WebSocket na mesma porta. Depois que a conexão é estabelecida, a comunicação muda para um protocolo binário bidirecional que não está em conformidade com o protocolo HTTP. Wikipedia

— JSON C11
fonte

Em que situações a pesquisa longa / curta do AJAX seria preferível aos WebSockets HTML5?

Comparação:

Vantagens:

Considerações de segurança

PS