In what situations would AJAX long/short polling be preferred over HTML5 WebSockets?

Question

I am building a small chat application for friends, but unsure about how to get information in a timely manner that is not as manual or as rudimentary as forcing a page refresh.

Currently, I am implementing this using simple AJAX, but this has the disadvantage of regularly hitting the server when a short timer elapses.

In researching long/short polling, I ran across HTML5 WebSockets. This seems easy to implement, but I'm not sure if there are some hidden disadvantages. For example, I think WebSockets is only supported by certain browsers. Are there other disadvantages to WebSockets that I should be aware of?

Since it seems like both technologies do the same thing, in what sorts of scenarios would one prefer to use one over the other? More specifically, has HTML5 WebSockets made AJAX long/short polling obsolete, or are there compelling reasons to prefer AJAX over WebSockets?

Mcbride

Answer 1

WebSockets is definitely the future now.

Long polling is a dirty workaround to prevent creating connections for each request like AJAX does - but long polling was created when WebSockets didn't exist. Now due to WebSockets, long polling is going away no more.

WebRTC allows for peer-to-peer communication.

I recommend learning WebSockets.

Comparison:

of different communication techniques on the web

• AJAX - request → response. Creates a connection to the server, sends request headers with optional data, gets a response from the server, and closes the connection. Supported in all major browsers.

• Long poll - request → wait → response. Creates a connection to the server like AJAX does, but maintains a keep-alive connection open for some time (not long though). During connection, the open client can receive data from the server. The client has to reconnect periodically after the connection is closed, due to timeouts or data eof. On server side it is still treated like an HTTP request, same as AJAX, except the answer on request will happen now or some time in the future, defined by the application logic. support chart (full) | wikipedia

• WebSockets - client ↔ server. Create a TCP connection to the server, and keep it open as long as needed. The server or client can easily close the connection. The client goes through an HTTP compatible handshake process. If it succeeds, then the server and client can exchange data in both directions at any time. It is efficient if the application requires frequent data exchange in both ways. WebSockets do have data framing that includes masking for each message sent from client to server, so data is simply encrypted. support chart (very good) | wikipedia

• WebRTC - peer ↔ peer. Transport to establish communication between clients and is transport-agnostic, so it can use UDP, TCP or even more abstract layers. This is generally used for high volume data transfer, such as video/audio streaming, where reliability is secondary and a few frames or reduction in quality progression can be sacrificed in favour of response time and, at least, some data transfer. Both sides (peers) can push data to each other independently. While it can be used totally independent from any centralised servers, it still requires some way of exchanging endPoints data, where in most cases developers still use centralised servers to "link" peers. This is required only to exchange essential data for establishing a connection, after which a centralised server is not required. support chart (medium) | wikipedia

• Server-Sent Events - client ← server. Client establishes persistent and long-term connection to server. Only the server can send data to a client. If the client wants to send data to the server, it would require the use of another technology/protocol to do so. This protocol is HTTP compatible and simple to implement in most server-side platforms. This is a preferable protocol to be used instead of Long Polling. support chart (good, except IE) | wikipedia

Advantages:

The main advantage of WebSockets server-side, is that it is not an HTTP request (after handshake), but a proper message based communication protocol. This enables you to achieve huge performance and architecture advantages. For example, in node.js, you can share the same memory for different socket connections, so they can each access shared variables. Therefore, you don't need to use a database as an exchange point in the middle (like with AJAX or Long Polling with a language like PHP). You can store data in RAM, or even republish between sockets straight away.

Security considerations

People are often concerned about the security of WebSockets. The reality is that it makes little difference or even puts WebSockets as better option. First of all, with AJAX, there is a higher chance of MITM, as each request is a new TCP connection that is traversing through internet infrastructure. With WebSockets, once it's connected it is far more challenging to intercept in between, with additionally enforced frame masking when data is streamed from client to server as well as additional compression, which requires more effort to probe data. All modern protocols support both: HTTP and HTTPS (encrypted).

P.S.

Remember that WebSockets generally have a very different approach of logic for networking, more like real-time games had all this time, and not like http.

Underhand

Tell me if I'm wrong but even though WebSocket provides a lot of improvement it does not completely overlap the functionality of long polling. For instance you cannot just swap comet for websocket to poll a REST api. – Luau

It's not about compatibility it self. Most important that it is about to fully rethink the way communication is happening. As RESTful APIs work with Request>Response pattern, bi-directional communication here would be pointless. So trying to use WebSockets to query RESTful API - is a bit weird attempt, and can't see any benefit of it at all. If you need data from RESTful API but in real-time manner, then you create WebSockets api to push data that will work with bidirectional communication like WebSockets. You are trying to compare things in angle that they are not comparable :) – Underhand

Does each connection in the WebSocket create and use a thread on the server? – Buxtehude

Hi @Buxtehude it all depends on server-side software (language/tech) it self. WebSocket is layer over TCP, and there are many ways of doing TCP stream implementations. Modern web servers use event-based architecture, and are very efficient with thread pools. Which tech you are using? Node.js uses events behind the scenes for IO, and event with single thread in execution context, so it is amazingly efficient. Using thread for each connection - is very inefficient in terms of RAM (1mb+ per thread) as well as CPU, as those threads will just idle or worse - infinite loop of checking for data. – Underhand

Long polling isn't a dirty workaround, and it's different from webSocket. These two are meant to used in different scenario. – Orlene

@Orlene Long Polling is a "hacky" use of technology to achieve results that technology didn't allowed by definition and not standard alternative was available. The reason Long Polling exists is exactly the fact that WS didn't, Period. – Underhand

One downside of Websockets is that it's not easy to hide your origin server from the world. It's a bit of a liability. For example, Cloudflare's free-tier will protect your restful endpoints (those ones your AJAX long-poller is consuming). But Cloudlfare only supports Websockets for their enterprise package -- the package where you have to call just to get a quote. cloudflare.com/plans – Heel

@Heel who stops you to make your own proxy+load balancer, same as cloudflare? It is easy to do, and can be done with many things, such as routing rules by regions using AWS Route53, and optionally extra load balancing EC2 instances to spread the traffic with load to other EC2 instances those do logic. – Underhand

@moka: Cloudflare's free-tier will absorb a sustained 400+Gbps attack. Can your wallet absorb the AWS bill? Also AWS and Cloudflare have opposite views when it comes to dealing with complaints against your origin. It's just something to keep in mind as long as we're discussing the tradeoffs. :) – Heel

@Heel those are "good" problems to have, and if you have such traffic, then you surely have resources to deal with such challenges. For majority of "common" cases, this is far out of the "norm" and solution with own load balancer on top of basic AWS services - will do great job for long enough. – Underhand

please add Java Sockets also to compare. – Razorback

@SathishKumarkk Java Sockets, are totally different thing, and has nothing to do with description of web technologies available in browsers. Java Socket class it self is not implementing any particular protocol, but just interface and simplification over different implementations. Please refer to official Java documentation for this information, it is well documented there. – Underhand

You forgot to talk about ComedD (bayeux protocol). – Kentiggerma

CometD is not part of HTML5 and implemented as library, such as SockJS, Socket.IO and many others, and under the hood uses protocols described in this post. This topic discusses default protocols - available out of the box without any extra libraries. – Underhand

@Underhand I have implemented web socket with node js,socket.io.My observation was on 10 client, 15 MB data, cpu 2.60GHz and network speed was 1GBps. when I was transmitting data to every client then CPU uses was 100% and data received in 58 sec. But over on htpp request it was 7 to 13 % CPU and content was served to every client in 5 to 10 sec. I did not find root cause of this behaviour till now. why web socket uses 100% CPU and http only 7 to 13 %. – Lesialesion

Socket.IO is a library with overhead introduced by parsing your messages back and forth, and wrapping different protocols with own stuff, including implementation of eventemitter. In order to track efficiency of websockets, use pure WebSocket on client side, and efficient implementation with streams in nodejs. Although serving files using websockets - is very unrecommended and inefficient way. Use http with static web server application to serve static files. – Underhand

The AJAX information is misleading, requests have not needed to close connections since HTTP 1.1 – Kylynn

@EricGrange feel free to edit response to reflect the way HTTP2 affects AJAX. – Underhand

Long polling is easier to implement, scales automatically across servers and more (IMO) predictable. The only drawbacks with long polling is that you hit the server often when you don't need to, setup overhead and data not being available immediately after creation. – Bosporus

How about signalR? – Fregger

A web socket has many disadvantages like server affinity, utilization of server resources for a long time (1 MB / socket), it introduces a state in opposite to stateless http plus it comes with a periodic polling for the heartbeat check. That's why, in any case where it is anyhow possible: use short polling and avoid web sockets. Besides that, what means real time for an application? Often it is just an illusion and even if we are talking about close-to-realtime, what does it really mean to the application compared to short polling? Your answer totally ignores that. – Milton

... PS: Your answer totally ignores the disadvantages and makes noobs feel like sockets are the future solution that will replace http - which they are definitely not. Please add a section Disadvantages – Milton

@Milton Why you don't add the disadvantages you know yourself? I'm interrested in what you have to say ^^ – Crucifixion

Answer 2

One contending technology you've omitted is Server-Sent Events / Event Source. What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet? has a good discussion of all of these. Keep in mind that some of these are easier than others to integrate with on the server side.

Krahmer

Out of all of these, whick would you suggest to look into? – Mcbride

I've had success with long-polling, the only trick (for it and other technologies) is not tying up a server thread. If you don't use asynchronous server code it won't scale. – Krahmer

@Mcbride Maksims-Mihejevs answered your question nicely in the first two paragraphs of his answer. Use websockets. – Nissy

Answer 3

For chat applications or any other application that is in constant conversation with the server, WebSockets are the best option. However, you can only use WebSockets with a server that supports them, so that may limit your ability to use them if you cannot install the required libraries. In which case, you would need to use Long Polling to obtain similar functionality.

Intermediary

WebSockets are supported by every server... You just need to install node.js or something similar. – Cheremkhovo

Tweaked a bit to explain that yes any server will support WebSockets. However, if you are using hosting service, you may not be able to use them. – Intermediary

I realize this thread is a bit old but... WebSockets may not be the best answer for all bi-directional communication. I recently noticed that the documentation for Spring 4's web socket support suggests that WebSockets are better suited for moving large amounts of data or low latency. If those are not applicable or are not a priority then they I believe they suggest using long polling. I don't know the full justification for this view, I just figured the Spring folks know what they are talking about in general. – Concentration

@Stoney apart from the fact that you would need to setup websocket on the server (handlers, etc.) There is simply no reason to use Long polling over websocket. Websocket is much faster (low latency) and allows the server to "talk" to the client without the client asking it to. Nowadays I use signalr (one of the best implementations of websocket ever made in my opinion - it runs on the client and server and allows the client to call methods on the server and the server on the client as if there is no difference) on every website I make - dynamic content loading, bottomless pages, etc. – Bier

I have an issue to keep hold connection from android mobile to nodejs socket.io server. – Osterman

Answer 4

• XHR polling A Request is answered when the event occurs (could be straight away, or after a delay). Subsequent requests will need to made to receive further events.

  The browser makes an asynchronous request of the server, which may wait for data to be available before responding. The response can contain encoded data (typically XML or JSON) or Javascript to be executed by the client. At the end of the processing of the response, the browser creates and sends another XHR, to await the next event. Thus the browser always keeps a request outstanding with the server, to be answered as each event occurs. Wikipedia

• Server Sent Events Client sends request to server. Server sends new data to webpage at any time.

  Traditionally, a web page has to send a request to the server to receive new data; that is, the page requests data from the server. With server-sent events, it's possible for a server to send new data to a web page at any time, by pushing messages to the web page. These incoming messages can be treated as Events + data inside the web page. Mozilla

• WebSockets After the initial handshake (via HTTP protocol). Communication is done bidirectionally using the WebSocket protocol.

  The handshake starts with an HTTP request/response, allowing servers to handle HTTP connections as well as WebSocket connections on the same port. Once the connection is established, communication switches to a bidirectional binary protocol which does not conform to the HTTP protocol. Wikipedia

Greenaway