HTTP vs Websockets with respect to overhead

Question

I am building a file synchronization program (not unlike Dropbox) using node.js on both ends. I need to have potentially thousands of clients requesting data at the same time.

Here is my current system:

• Server pushes notifications to client over a websocket (file has been updated)
• Client queues downloads and makes an HTTP request when idle

I will be serving data in compressed chunks of, say, 50 MB each, so the HTTP request overhead (headers) is negligible.

If I were to use websockets for requests and push notifications, would there be:

• Noticeable overall speed improvements? (reduced latency, authentication, etc.)
• Additional overhead on the server to keep connections open?
• Issues with pushing binary data?

I think I need to have notifications sent over a dedicated websocket because I don't want them to be queued on the server while a download is taking place (lots of overhead).

Note: These websockets will be open long-term, as long as the client's system is on.

EDIT: I will be using the websockets on a different http server on different ports in order to move them to different CPU cores. I could potentially have thousands (if not hundreds of thousands) of concurrent websockets open...

Answer 1

If you intend to use node.js for both client and server then you should use native net module with pure sockets rather than WebSockets. Pure sockets are much better optimized for data transfer, especially binary. As far as I know browser WebSockets do not even support binary transfer yet.

Answer 2

I was searching around for something else and I found this post that explains websockets pretty well:

http://blog.new-bamboo.co.uk/2009/12/7/real-time-online-activity-monitor-example-with-node-js-and-websocket

Here are some pretty interesting parts from the article:

Websocket enables you to have continuos communication in significantly less network overhead compared to existing solution.

And:

During making connection with WebSocket, client and server exchange data per frame which is 2 bytes each, compared to 8 kilo bytes of http header when you do continuous polling.

For my use case (no browser), this seems like the optimal solution! Now I just need to decide whether I want to have a single websocket or multiple websockets per client (I'm leaning towards a single one at this point).

I really hope this is useful to someone. I'll leave this open for the time being. I'll be attending a JS conference later this week, and if I learn anything more I'll add to this post.

For those of you who care about browser support, see this. It looks like WebKit is the only reliable engine that supports it (Chrome and Safari).