18

Recently I've found out of Server-Sent events as a much simpler alternative to WebSockets for doing push from the server. Most places that compare them (like here, here and here) say that if you don't need full duplex communications between client and server, then WebSockets is overkill and SSE are good enough.

My question is what would be the downside of using SSE when you do need bidirectional communications (like a chat for example), using regular ajax requests for sending messages from the client and the server stream for receiving them? Considering that I have to do little to no configuration on the server side to use SSE, it seems to be a much more appealing option.

Community
  • 1
  • 1
Facundo Olano
  • 2,212
  • 2
  • 24
  • 31

2 Answers2

26

SSE Advantages over WebSockets:

  • No special web server or web proxy changes required.
  • Define custom events (otherwise, client API is basically the same)
  • Easier integration of existing authentication mechanisms (OAuth, OpenID, etc)

SSE Disadvantages compared to WebSockets:

  • Unidirectional communication channel (server to client). Client to server requires a separate channel.
  • Browser support is more limited (no native IE support whereas WebSockets is supported in IE 10): WebSockets, SSE
  • Relies on client to verify origin (possibly more vulnerable to XSS attacks than WebSockets)
  • No native support for binary types (WebSockets supports raw frames using ArrayBuffers and Blobs).
  • Requires a full fledged web server even if the SSE endpoint is not serving static web content (a standalone WebSocket server can be fairly simple)
  • SSE with AJAX for bi-directional communication will have MUCH higher round-trip latency and higher client->server bandwidth than using a WebSocket connection. This is due to the overhead of connection setup for every client->server AJAX request. Also, server->client latency can have spikes with SSE since in many configurations the long-held connection will eventually be closed (often every 30 seconds) and need to be re-opened causing a temporary spike in server->client latency as well.

References:

kanaka
  • 63,553
  • 21
  • 138
  • 135
  • 2
    Good points, but I don't quite agree on complexity of a standalone server. SSE protocol is dead simple — much simpler than WebSockets (no handshake, framing, masking, binary). In both cases you need to parse HTTP(-like) headers. You can implement SSE server in a bash script :) – Kornel Jan 09 '13 at 01:06
  • @porneL, you are right, a basic SSE server could be fairly simple to implement (although I'd like to see your bash version), but so is a basic WebSocket server. But regardless, my point was not that WebSocket servers are simpler, but that SSE usually assumes a webserver whereas WebSockets does not (although it's certainly designed to integrate easily with existing web infrastructure). – kanaka Jan 09 '13 at 05:41
  • @kanaka For education purposes here you go: `while true; do { echo -e 'HTTP/1.1 200 OK\r\nContent-Type: text/event-stream\r\n\r\ndata: connection established and already closed :)'; } | netcat -l 55668; done` Be aware of the cors policy at sse level. You have to proxy this upstream at the same domain the frontend runs. There is no exception at sse – user3655829 Mar 23 '19 at 13:50
  • 1
    I'll add from my personal experience: Main SSE advantage over WebSockets is that SSE supports cookie header (token-based authorization can be taken care of before data connection to your API is established). It also means faster 1st data packet delivery (putting token in URL is not secure, so websokets need to send token to the server after the connection is established). Websockets are much more vulnerable to DDOS, because all anti-DDOS measures should be undertaken by nodejs, which isn't really good at this. With SSE you can rely on nginx. – Sergei Sep 08 '20 at 16:16
3

Ajax requests are huge compared to small WebSocket messages. Standard HTTP requests (Ajax) include a lot of headers including cookies with every request while WebSocket messages is just a few bytes.

The good thing with HTTP (Ajax) request is that they are easier to cache if that is a benefit for your problem.

Jonas
  • 97,987
  • 90
  • 271
  • 355
  • For bi-directional communication, being able to cache AJAX requests is not going to be helpful. If you are using AJAX to asynchronously load images or other static data then caching would be beneficial but that is for server->client communication and doesn't help with client->server which is what AJAX is being used for in this scenario. – kanaka Nov 08 '12 at 14:49