WebSockets vs Long Polling

1. Overview

Sometimes we need information from our servers as soon as it’s available. The usual AJAX request/response we’re all used to doesn’t keep the connection open for this sort of use case. Instead, we need a push-based method like WebSockets, Long Polling, Server-sent events (SSE) and more recently HTTP2 push. In this article, we compare two methods: WebSockets and Long Polling.

2. Long Polling

Long polling is implemented on the back of XMLHttpRequest. Long polling is essentially a more efficient form of the original polling technique. Making repeated requests to a server wastes resources, as each new incoming connection must be established, the HTTP headers must be parsed, a query for new data must be performed, and a response (usually with no new data to offer) must be generated and delivered. The connection must then be closed and any resources cleaned up. Rather than having to repeat this process multiple times for every client until new data for a given client becomes available, long polling is a technique where the server elects to hold a client’s connection open for as long as possible, delivering a response only after data becomes available or a timeout threshold is reached.

In cases where exceptions must be handled though, or where a server can be queried for new data but does not support long polling (let alone other more modern technology standards), basic polling can sometimes still be of limited use, and can be implemented using XMLHttpRequest, or via JSONP through simple HTML script tags.

2.1 Pros

•  Near-universally supported by devices

2.2 Cons

• Long polling is a lot more intensive on the server
• Reliable message ordering can be an issue with long polling because it is possible for multiple HTTP requests from the same client to be in flight simultaneously
  
  • For example, if a client has two browser tabs open consuming the same server resource, and the client-side application is persisting data to a local store such as localStorage or IndexedDb, there is no in-built guarantee that duplicate data won’t be written more than once.
• Depending on the server implementation, confirmation of message receipt by one client instance may also cause another client instance to never receive an expected message at all, as the server could mistakenly believe that the client has already received the data it is expecting.

3. WebSockets

WebSockets are a thin transport layer built on top of a device’s TCP/IP stack. The intent is to provide what is essentially an as-close-to-raw-as-possible TCP communication layer to web application developers while adding a few abstractions to eliminate certain friction that would otherwise exist concerning the way the web works. They also cater to the fact that the web has additional security considerations that must be taken into account to protect both consumers and service providers.

3.1 Pros

• WebSockets keeps a unique connection open while eliminating latency problems that arise with Long Polling.
• WebSockets generally do not use XMLHttpRequest, and as such, headers are not sent every-time we need to get more information from the server. This, in turn, reduces the expensive data loads being sent to the server.

3.2 Cons

• WebSockets don’t automatically recover when connections are terminated – this is something you need to implement yourself, and is part of the reason why there are many client-side libraries in existence.
• Browsers older than 2011 aren’t able to support WebSocket connections - but this is increasingly less relevant.

4. Why the WebSocket protocol is the better choice

Long polling is much more resource-intensive on servers whereas WebSockets have an extremely lightweight footprint on servers.

Long polling also requires many hops between servers and devices. And these gateways often have different ideas of how long a typical connection is allowed to stay open. If it stays open too long something may kill it, maybe even when it was doing something important.

Why you should build with WebSockets:

• Full-duplex asynchronous messaging. In other words, both the client and the server can stream messages to each other independently.
• WebSockets pass through most firewalls without any reconfiguration.
• Good security model (origin-based security model).

5. Comparison Between Long polling and Websocket

• Long/short polling (client pull)
• WebSockets (server push)
• Server-Sent Events (server push)

4. Reference

https://www.ably.io/blog/websockets-vs-long-polling/

https://d2.naver.com/helloworld/1336

https://medium.com/@chullino/http%EC%97%90%EC%84%9C%EB%B6%80%ED%84%B0-websocket%EA%B9%8C%EC%A7%80-94df91988788

https://en.wikipedia.org/wiki/Push_technology#Long_polling

https://en.wikipedia.org/wiki/Comet_(programming)

https://dev.to/moz5691/websocket-vs-long-polling-http-412f

https://www.slideshare.net/jfarcand/websockets-on-the-jvm-atmosphere-to-the-rescue-40639146