Question

Websockets were designed for fast bi-directional communication in the browser. Assuming you have control over the server and a native client (say an iOS or Mac app), are there any good reasons or situations to communicate over a websocket instead of using an HTTP library?

Answer 1

I’m going to answer a couple of different questions that hopefully ends up answering your question:

• Is there a reason to use WebSockets from a client rather than HTTP? Yes.

  • WebSockets is bi-directional, full-duplex, low-latency and low-overhead compared to HTTP.

  • Part of the lower latency and overhead compared to HTTP/AJAX/COMET is that you don’t have to re-establish the connection for each request.

• Is there a reason to use WebSockets from a client rather than raw sockets? Yes.

  • The initial WebSockets handshake is HTTP server friendly (and has some origin and hash exchange safety mechanisms). It allows web servers to easily be updated to support redirect or proxy for WebSockets connections to the real WebSockets server application.

  • Another benefit of WebSockets is that it is a framed protocol which allows the application to focus on useful functionality without having to deal with its own framing and buffering.

  • Its fairly easy to add WebSockets support to existing TCP socket servers or proxy via something like websockify. Disclaimer: I made websockify.

  • From a server perspective WebSockets is a win because they can be accessed via standalone clients or via browsers. This means there are going to be more and more services that are currently TCP socket based that will be exposed via WebSockets. So adding WebSockets support to a client now will pay off in the future.