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?

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.

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.

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.

• 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