Server-Sent Events utilize a regular HTTP octet streams, and therefore are limited to the browser’s connection pool limit of ~6 concurrent HTTP connections per server. But they provide a standard way of pushing data from the server to the clients over HTTP, which load balancers and proxies understand out-of-the-box. The biggest advantage being that, exactly as WebSockets, they utilize only one TCP connection. The biggest disadvantage is that Server-Sent Events don’t provide a mechanism to detect dropped clients until a message is sent.
They are standardized via HTML 5, most HTTP servers support them out-of-the-box, and they are available in most browsers except for Internet Explorer and Edge where they are available through a polyfill.
Rails, Roda and Sinatra support them out-of-the-box. And they have a simple protocol — payloads are just prefixed with one of the following keywords data:, event:, id: and retry:. data: is used to push a payload, event: is optional and indicates the type of data being pushed, id: is also optional and indicates the event’s ID, finally retry: instructs the client to change it’s connection retry timeout — unlike WebSockets, Server-Sent Events have a reconnect mechanism built-in, though this is a feature that most WebSocket libraries add any way.
to send data to other clients a regular HTTP POST request is made to the server. A heartbeat is kept to keep the connections alive (WebSockets also do that) and to detect dropped clients (since dropped connections can only be detected when data is pushed to them).