WebSockets vs. eventos enviados pelo servidor / EventSource

838

Os WebSockets e os eventos enviados pelo servidor são capazes de enviar dados para os navegadores. Para mim, elas parecem ser tecnologias concorrentes. Qual a diferença entre eles? Quando você escolheria um sobre o outro?

html  browser  websocket  server-sent-events 
— Mads Mobæk
fonte
2
Não tenho certeza de como você os vê como concorrentes. Um é síncrono e poderia / seria usado para xfer de dados quase em tempo real, enquanto o outro é assíncrono e serviria a um propósito totalmente diferente (efetivamente enviar mensagens semelhantes a brindes de um aplicativo do servidor).
— Brian Driscoll
54
O WebSockets é bidirecional, pode enviar dados para o servidor.
— precisa
13
Uma coisa que eu realmente gosto no SSE é que é fácil solucionar problemas ... basta abrir uma solicitação usando o servidor SSE curl. Como é apenas um formato de texto sobre HTTP, é fácil ver o que está acontecendo.
— 21712 Sam
7
@BrianDriscoll - assíncrono / síncrono - qual é qual? Tanto quanto eu posso entender, ambos permitem transferências assíncronas?
— Dave Everitt 26/09
5
O SSE não funcionam no IE, websockets faz
— Tyler Gillies

Respostas:

978

Websockets e SSE (Server Sent Events) são capazes de enviar dados para navegadores, no entanto, não são tecnologias concorrentes.

As conexões dos Websockets podem enviar dados para o navegador e receber dados do navegador. Um bom exemplo de um aplicativo que poderia usar websockets é um aplicativo de bate-papo.

As conexões SSE podem enviar dados apenas ao navegador. Cotações de ações on-line ou twitters que atualizam a linha do tempo ou o feed são bons exemplos de aplicativos que podem se beneficiar do SSE.

Na prática, já que tudo o que pode ser feito com o SSE também pode ser feito com Websockets, o Websockets está recebendo muito mais atenção e amor, e muitos mais navegadores suportam Websockets que o SSE.

No entanto, pode ser um exagero para alguns tipos de aplicativos, e o back-end pode ser mais fácil de implementar com um protocolo como o SSE.

Além disso, o SSE pode ser polyfilled em navegadores mais antigos que não o suportam nativamente usando apenas JavaScript. Algumas implementações de polyfills SSE podem ser encontradas na página Modernizr github .

Pegadinhas:

  • O SSE sofre uma limitação ao número máximo de conexões abertas, o que pode ser especialmente doloroso ao abrir várias guias, pois o limite é por navegador e definido como um número muito baixo (6). O problema foi marcado como "Não será corrigido" no Chrome e Firefox . Esse limite é por navegador + domínio, o que significa que você pode abrir 6 conexões SSE em todas as guias www.example1.come outras 6 conexões SSE www.example2.com(obrigado Phate).
  • Somente o WS pode transmitir dados binários e UTF-8, o SSE é limitado a UTF-8. (Obrigado a Chado Nihi).
  • Alguns firewalls corporativos com inspeção de pacotes têm problemas para lidar com WebSockets (Sophos XG Firewall, WatchGuard, McAfee Web Gateway).

O HTML5Rocks tem boas informações sobre SSE. A partir dessa página:

Eventos enviados pelo servidor x WebSockets

Por que você escolheria Eventos enviados pelo servidor em vez de WebSockets? Boa pergunta.

Um motivo pelo qual as SSEs foram mantidas à sombra é que APIs posteriores, como o WebSockets, fornecem um protocolo mais rico para executar a comunicação bidirecional e full-duplex. Ter um canal de mão dupla é mais atraente para coisas como jogos, aplicativos de mensagens e para os casos em que você precisa de atualizações quase em tempo real nas duas direções. No entanto, em alguns cenários, os dados não precisam ser enviados pelo cliente. Você simplesmente precisa de atualizações de alguma ação do servidor. Alguns exemplos seriam atualizações de status de amigos, cotações de ações, feeds de notícias ou outros mecanismos automatizados de envio de dados (por exemplo, atualização de um banco de dados SQL da Web do cliente ou armazenamento de objetos IndexedDB). Se você precisar enviar dados para um servidor, o XMLHttpRequest é sempre um amigo.

SSEs são enviados pelo HTTP tradicional. Isso significa que eles não precisam de um protocolo ou implementação de servidor especial para funcionar. Os WebSockets, por outro lado, exigem conexões full-duplex e novos servidores Web Socket para manipular o protocolo. Além disso, os Eventos enviados pelo servidor têm vários recursos que os WebSockets não possuem por design, como reconexão automática, IDs de eventos e a capacidade de enviar eventos arbitrários.

Resumo do TLDR:

Vantagens do SSE sobre Websockets:

  • Transportado por HTTP simples em vez de por um protocolo personalizado
  • Pode ser preenchido com javascript para "backport" SSE para navegadores que ainda não o suportam.
  • Suporte integrado para re-conexão e identificação de evento
  • Protocolo mais simples
  • Sem problemas com firewalls corporativos que realizam inspeção de pacotes

Vantagens dos Websockets sobre SSE:

  • Em tempo real, duas comunicações direcionais.
  • Suporte nativo em mais navegadores

Casos de uso ideais do SSE:

  • Transmissão de ações
  • atualização do feed do twitter
  • Notificações para o navegador

Dicas do SSE:

  • Sem suporte binário
  • Limite máximo de conexões abertas
— Alex Recarey
fonte
131
O bate-papo é perfeitamente possível com o SSE - você pode usar o POST comum para enviar mensagens ao servidor. Os WebSockets seriam necessários apenas se você estiver implementando o bate-papo no Google Wave.
— Kornel
135
É verdade que o bate-papo e outros aplicativos em tempo real podem ser feitos com o SSE. No entanto, isso requer respostas POST "fora da banda", ou seja, isso não é controlado pelo protocolo SSE e não parece um bom exemplo para uma explicação básica sobre as diferenças entre o SSE e os Websockets. Você pode implementar o bate-papo com HTTP básico pesquisando o servidor a cada segundo e POSTando novas respostas. Isso não significa que é a melhor / mais elegante maneira de fazê-lo.
— precisa saber é o seguinte
14
Eu acho que a solução da pomeL é um grande compromisso para a maioria dos casos, pois o JS sempre pode "enviar" coisas ao servidor com um AJAX POST. De acordo com minha experiência, o principal problema geralmente tem sido a necessidade de JS pesquisar novas informações, mas o SSE cuida disso. : D
— Jacob Pritchett 02/03
12
O @MattDiPasquale Wave enviou todas as chaves individualmente enquanto você digitava, em vez de completar a mensagem de uma só vez. 200 bytes de sobrecarga do POST para 1 pressionamento de tecla seriam um desperdício em comparação com cerca de 6 no WebSocket.
— Kornel
9
Parece um pouco estranho dizer que não são tecnologias concorrentes e, em seguida, descreva que ambas podem ser usadas para obter soluções semelhantes. Eu diria que os faz competir.
— Alex
115

De acordo com caniuse.com:

Você pode usar um polyfill somente para cliente para estender o suporte do SSE a muitos outros navegadores. Isso é menos provável com WebSockets. Alguns polyfills EventSource:

Se você precisar oferecer suporte a todos os navegadores, considere usar uma biblioteca como web-socket-js , SignalR ou socket.io que suporte vários transportes, como WebSockets, SSE, Forever Frame e pesquisa longa AJAX. Isso geralmente exige modificações no lado do servidor também.

Saiba mais sobre o SSE em:

Saiba mais sobre o WebSockets em:

Outras diferenças:

  • WebSockets suporta dados binários arbitrários, o SSE usa apenas UTF-8
— Drew Noakes
fonte
3
Gostaria de salientar em 2016> 95% dos usuários globais suportam nativamente WebSockets. Todos os navegadores e dispositivos têm suporte para WebSockets há mais de 4 anos. O Socket.IO recorrerá à sondagem longa do AJAX e lidará com as complexidades de emular WebSockets para você, se não houver suporte, o que torna o suporte 100%. Se você estiver usando algo que não seja o WebSockets em 2016, está usando uma tecnologia desatualizada.
— 21416 Nick Steele
3
@NickSteele Essa é uma declaração hype besteira. Confiar nos padrões mais antigos é perfeitamente adequado se eles atenderem ao seu caso de uso e não significa que algo está desatualizado. É apenas um padrão diferente. Ex: o XHR ainda pode fazer muitas coisas que a API Fetch não pode, por isso não está desatualizada. É diferente. Eu usei o WS no passado, mas sei por experiência que se pode encontrar dificuldades na forma de firewalls corporativos com ruído que bloqueiam solicitações quando não entendem o WS. O SSE é supereficiente para o que faz, é trivialmente compreensível, implementável e fácil de depurar. Para o nosso fluxo de dados unidirecional, é perfeito.
— Oligofren
@oligofren Não há necessidade de jurar. Se algo foi projetado para substituir a versão anterior, e é aceito pela indústria e melhor em todos os aspectos, por definição, o método antigo está desatualizado. Assim como o iPhone original está desatualizado, o XHR também. O XHR saiu antes do Firefox, Chrome, o primeiro iPhone, antes do YouTube, Netflix, Facebook e até MySpace. Quando o XHR foi lançado, o Windows 98 era o melhor sistema operacional, a AOL era o melhor provedor e o JSON nem existia. Os WebSockets substituíram o XHR quase uma década atrás. Se você encontrar obstáculos usando o WS, a coisa que causou o problema também está desatualizada. Não há desculpa para ficar tão longe.
— 22319 Nick Steele
4
Substitua BS por hipérbole :-) O WS não substitui o XHR / HTTP, assim como os drones não são usados ​​nos carros de entrega. São casos de uso diferentes. O WS não é HTTP e tem diferentes pontos de interesse. Você acabaria reimplementando HTTP (mal) no espaço do usuário, se tentasse. Além disso, você está sugerindo coisas que não recebem fatos: o WS é simplesmente um protocolo bidirecional que suporta o envio de servidor. Eu nunca vi nenhum documento de design mencionar que ele está sendo desenvolvido como substituto de qualquer coisa. Fonte? A idade em si não é um fator. Quando tiver uma escolha, escolha a implementação mais simples, verificando todos os seus requisitos.
— Oligofren
1
Há apenas dois anos (2017) eu estava depurando despejos de heap dos processos Node JS em que o código Socket.io estava causando uma fragmentação maciça de memória no processo IIS, terminando conversando diretamente com a equipe de Nó do Azure. A complexidade total não é de graça. Se você pode se safar com um script simples de 20 linhas como sua dependência do servidor, enquanto ainda é capaz de atender a 100 mil clientes, eu aceitaria. Mas eu amo o WS pelo que ele faz, mas veja o que você precisa antes de escolher uma solução.
— Oligofren
16

Opera, Chrome, Safari suporta SSE, Chrome, Safari suporta SSE dentro do SharedWorker Firefox suporta XMLHttpRequest readyState interativo, para que possamos tornar o polyfil EventSource para Firefox

— Yaffle
fonte
8

Websocket VS SSE

Web Sockets - É um protocolo que fornece um canal de comunicação full-duplex através de uma única conexão TCP. Por exemplo, uma comunicação bidirecional entre o servidor e o navegador Como o protocolo é mais complicado, o servidor e o navegador precisam confiar na biblioteca de websocket, que ésocket.io

Example - Online chat application.

SSE (evento enviado pelo servidor) - No caso de um evento enviado pelo servidor, a comunicação é realizada apenas do servidor para o navegador e o navegador não pode enviar nenhum dado ao servidor. Esse tipo de comunicação é usado principalmente quando a necessidade é apenas mostrar os dados atualizados; o servidor envia a mensagem sempre que os dados são atualizados. Por exemplo, uma comunicação unidirecional entre o servidor e o navegador. Esse protocolo é menos complicado, portanto, não há necessidade de confiar na biblioteca externa JAVASCRIPT, que fornece a EventSourceinterface para receber as mensagens enviadas pelo servidor.

Example - Online stock quotes or cricket score website.
— Gaurav Tiwari
fonte
4

Uma coisa a observar:
tive problemas com websockets e firewalls corporativos. (O uso de HTTPS ajuda, mas nem sempre.)

Consulte https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software https://github.com/sockjs/sockjs-client/issues/94

I supor que não há tantos problemas com Eventos enviados pelo servidor. Mas eu não sei.

Dito isto, os WebSockets são muito divertidos. Eu tenho um pequeno jogo na web que usa websockets (via Socket.IO) ( http://minibman.com )

— Drew LeSueur
fonte
1
Eu também tive problemas com firewalls corporativos.
— Oligofren
1
Um problema que vimos com os Eventos enviados pelo servidor são de que alguns proxies / firewalls pode bloqueá-lo, porque ele não tem um cabeçalho Content-Length
— de Drew LeSueur
2

Aqui está uma palestra sobre as diferenças entre os soquetes da web e os eventos enviados pelo servidor. Desde o Java EE 7, uma API WebSocket já faz parte da especificação e parece que os eventos enviados pelo servidor serão lançados na próxima versão da edição corporativa.

— Patrick Leitermann
fonte
-3

O limite máximo de conexão não é um problema com o http2 + sse.

Foi um problema no http 1

— user1948585
fonte
O HTTP2 permite que várias solicitações no mesmo domínio sejam tratadas como fluxos. Essa técnica é chamada de multiplexação. Isso economiza os limites de conexão do navegador por domínio, razão pela qual as pessoas fazem sharding de domínio com o HTTP1.
— User1948585
1
Os fluxos HTTP / 2 também são limitados em número, o que protege os servidores de serem bombardeados por um único navegador e força os navegadores a limitar sua multiplexação a um número limitado de fluxos - que, no nosso caso, é o mesmo que conexões HTTP / 1.1. que leva você de volta ao limite de conexão SSE.
— Myst
Presumo que a conexão do websocket também consuma recursos do servidor. samsaffron.com/archive/2015/12/29/websockets-caution-required . É sempre bom ter a capacidade de configurar o máximo que o seu bolso permitir.
— precisa saber é o seguinte
é provável que o SSE consuma recursos semelhantes na maioria dos servidores (se não mais, devido à pilha HTTP ainda presente e às suas limitações).
— Myst
1
Esta resposta está correta. O limite de 6 conexões HTTP não existe mais ao usar HTTP / 2. Prova: codepen.io/dunglas/pen/yLYxdxK?editors=1010 Com o HTTP / 2, cabe ao servidor e o cliente pode negociar o número máximo de fluxos simultâneos (100 por padrão).
— Kévin Dunglas
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.