somdow somdow - 4 months ago 37x
Ajax Question

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

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?


WebSockets - is definitely the future. Long polling is dirty workaround of preventing 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. And WebRTC allows peer-to-peer communication.

I recommend learning WebSockets.


of different communication techniques in web

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

  • Long poll - requestwaitresponse. Creates connection to server like AJAX does, but keep-alive connection open for some time (not long though), during connection open client can receive data from server. Client have to reconnect periodically after connection is closed due to timeouts or data eof. On server side it is still treated like HTTP request same as AJAX, except the answer on request will happen now or some time in the future defined by application logic. Supported in all major browsers.

  • WebSockets - clientserver. Create TCP connection to server, and keep it as long as needed. Server or client can easily close it. Client goes through HTTP compatible handshake process, if it succeeds, then server and client can exchange data both directions at any time. It is very efficient if 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)

  • WebRTC - peerpeer. Transport to establish communication between clients and is transport-agnostic so uses UDP, TCP or even more abstract layers. By design it allows to transport data in reliable as well as unreliable ways. This is generally used for high volume data transfer such as video/audio streaming where reliability - is secondary and few frames or reduction in quality progression can be sacrificed in favour of response time and at least delivering something. Both sides (peers) can push data to each other independently. While it can be used totally independent from any centralised servers it still require 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 connection establishing - after connection is established server on aside is not required. support chart (medium)

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


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

Security considerations

People often are concerned regarding security of WebSockets. 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 new TCP connection and 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, that requires more effort to probe data. All modern protocols support both: HTTP and HTTPS (encrypted).


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.