Websockets and SSE (Server Sent Events) are both capable of pushing data to browsers, however they are not competing technologies.
Websockets connections can both send data to the browser and receive data from the browser. A good example of an application that could use websockets is a chat application.
SSE connections can only push data to the browser. Online stock quotes, or twitters updating timeline or feed are good examples of an application that could benefit from SSE.
In practice since everything that can be done with SSE can also be done with Websockets, Websockets is getting a lot more attention and love, and many more browsers support Websockets than SSE.
However, it can be overkill for some types of application, and the backend could be easier to implement with a protocol such as SSE.
Furthermore SSE can be polyfilled into older browsers that do not support it natively using just JavaScript. Some implementations of SSE polyfills can be found on the Modernizr github page.
Gotchas:
- SSE suffers from a limitation to the maximum number of open connections, which can be specially painful when opening various tabs as the limit is per browser and set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, so that means that you can open 6 SSE connections across all of the tabs to
www.example1.com
and another 6 SSE connections to www.example2.com
(thanks Phate).
- Only WS can transmit both binary data and UTF-8, SSE is limited to UTF-8. (Thanks to Chado Nihi).
- Some enterprise firewalls with packet inspection have trouble dealing with WebSockets (Sophos XG Firewall, WatchGuard, McAfee Web Gateway).
HTML5Rocks has some good information on SSE. From that page:
Server-Sent Events vs. WebSockets
Why would you choose Server-Sent Events over WebSockets? Good question.
One reason SSEs have been kept in the shadow is because later APIs like WebSockets provide a richer protocol to perform bi-directional, full-duplex communication. Having a two-way channel is more attractive for things like games, messaging apps, and for cases where you need near real-time updates in both directions. However, in some scenarios data doesn't need to be sent from the client. You simply need updates from some server action. A few examples would be friends' status updates, stock tickers, news feeds, or other automated data push mechanisms (e.g. updating a client-side Web SQL Database or IndexedDB object store). If you'll need to send data to a server, XMLHttpRequest is always a friend.
SSEs are sent over traditional HTTP. That means they do not require a special protocol or server implementation to get working. WebSockets on the other hand, require full-duplex connections and new Web Socket servers to handle the protocol. In addition, Server-Sent Events have a variety of features that WebSockets lack by design such as automatic reconnection, event IDs, and the ability to send arbitrary events.
TLDR summary:
Advantages of SSE over Websockets:
- Transported over simple HTTP instead of a custom protocol
- Can be poly-filled with javascript to "backport" SSE to browsers that do not support it yet.
- Built in support for re-connection and event-id
- Simpler protocol
- No trouble with corporate firewalls doing packet inspection
Advantages of Websockets over SSE:
- Real time, two directional communication.
- Native support in more browsers
Ideal use cases of SSE:
- Stock ticker streaming
- twitter feed updating
- Notifications to browser
SSE gotchas:
- No binary support
- Maximum open connections limit
Update
Are there scenarios I need RabbitMQ
for web apps where Socket.io doesn't
suffice?
Browser users should be able to communicate with eachother through a node.js server. One
of the user writes a message and all other users will get it.
When you only have these simple requirements then socket.io alone will be enough.. You only need a message queue when you want to process your jobs(heavy) offline and in a controlled manner.
http://en.wikipedia.org/wiki/Message_queue:
Message queues provide an asynchronous
communications protocol, meaning that
the sender and receiver of the message
do not need to interact with the
message queue at the same time.
This sentence needs to sink in. The producer (one process) puts a job into the queue and the consumer consumes by taking the job from the queue. The consumer, most times, are multiple processes that consume multiple jobs concurrently. The consumers are unable to tell from each other, what jobs they are consuming.
This makes the queue a
First-In-First-Out (FIFO) data
structure.
That's I think an important property of the queue. The First-In-First-Out property although with an advanced message queue like beanstalkd you can give jobs priorities.
I hope this makes any sense at all ;)
I'm doing real time live web app
development.
Could you explain a little better so that we can give you a better answer?
I don't quite get how RabbitMQ works.
But from quick reading it seems that
it handles publication/subscription of
messages.
See the quote about message queue below. Let it sink in for a while. You could also read the WIKI about message queues.
A user (in a browser) publishes
something and subscribers (in other
browsers) get that message. Isn't that
what Socket.io is doing with
websockets?
Socket.io supports a lot of different transports(also websockets) and it should because websockets are not supported by the most browsers. But for example Google Chrome does already support websockets. I believe that websockets are the transport of the future(but not yet!). When you look at Socket.io's browser support page you will notice that Socket.io does support all the major browsers(some even ancient). The nice thing is that it wraps this around a nice API.
What are the advantages/disadvantages
for each one of them?
You are comparing apples to oranges so comparing that is kind of strange.
RabbitMQ
http://www.rabbitmq.com/tutorials/tutorial-one-python.html:
RabbitMQ is a message broker. The
principal idea is pretty simple: it
accepts and forwards messages. You can
think about it as a post office: when
you send mail to the post box you're
pretty sure that Mr. Postman will
eventually deliver the mail to your
recipient. Using this metaphor
RabbitMQ is a post box, a post office
and a postman.
Advantages
- It is a pretty good message queue. Personally I would use redis or beanstalkd.
Disadvantages:
- Is not really for "browsers".
Socket.io
http://socket.io/:
Socket.IO aims to make realtime apps
possible in every browser and
mobile device, blurring the
differences between the different
transport mechanisms.
Advantages
Disadvantages
- It is not a message queue.
Can Socket.io replace RabbitMQ?
No you can't because they are two completely different things. You are comparing apples to oranges. You should try to comprehend both descriptions from the sites I quoted.
Best Answer
Misconceptions
There are few common misconceptions regarding WebSocket and Socket.IO:
The first misconception is that using Socket.IO is significantly easier than using WebSocket which doesn't seem to be the case. See examples below.
The second misconception is that WebSocket is not widely supported in the browsers. See below for more info.
The third misconception is that Socket.IO downgrades the connection as a fallback on older browsers. It actually assumes that the browser is old and starts an AJAX connection to the server, that gets later upgraded on browsers supporting WebSocket, after some traffic is exchanged. See below for details.
My experiment
I wrote an npm module to demonstrate the difference between WebSocket and Socket.IO:
It is a simple example of server-side and client-side code - the client connects to the server using either WebSocket or Socket.IO and the server sends three messages in 1s intervals, which are added to the DOM by the client.
Server-side
Compare the server-side example of using WebSocket and Socket.IO to do the same in an Express.js app:
WebSocket Server
WebSocket server example using Express.js:
Source: https://github.com/rsp/node-websocket-vs-socket.io/blob/master/ws.js
Socket.IO Server
Socket.IO server example using Express.js:
Source: https://github.com/rsp/node-websocket-vs-socket.io/blob/master/si.js
Client-side
Compare the client-side example of using WebSocket and Socket.IO to do the same in the browser:
WebSocket Client
WebSocket client example using vanilla JavaScript:
Source: https://github.com/rsp/node-websocket-vs-socket.io/blob/master/ws.html
Socket.IO Client
Socket.IO client example using vanilla JavaScript:
Source: https://github.com/rsp/node-websocket-vs-socket.io/blob/master/si.html
Network traffic
To see the difference in network traffic you can run my test. Here are the results that I got:
WebSocket Results
2 requests, 1.50 KB, 0.05 s
From those 2 requests:
(The connection upgrade request is visible on the developer tools with a 101 Switching Protocols response.)
Socket.IO Results
6 requests, 181.56 KB, 0.25 s
From those 6 requests:
Screenshots
WebSocket results that I got on localhost:
Socket.IO results that I got on localhost:
Test yourself
Quick start:
Open http://localhost:3001/ in your browser, open developer tools with Shift+Ctrl+I, open the Network tab and reload the page with Ctrl+R to see the network traffic for the WebSocket version.
Open http://localhost:3002/ in your browser, open developer tools with Shift+Ctrl+I, open the Network tab and reload the page with Ctrl+R to see the network traffic for the Socket.IO version.
To uninstall:
Browser compatibility
As of June 2016 WebSocket works on everything except Opera Mini, including IE higher than 9.
This is the browser compatibility of WebSocket on Can I Use as of June 2016:
See http://caniuse.com/websockets for up-to-date info.