Reference
Use case of Long Polling
Long polling is better for cases where messages are sent infrequently, and not in bursts. (Dropbox is a good example, where file updates are sent over long polling. People would get fairly quick notifications of the update, but you wouldn't expect many updates to arrive in rapid succession, nor are they predictable). But if the client wants frequent updates in real-time, long polling handles it poorly.
Use case of Websocket
Chat app. Burst of messages
Short Polling
Long Polling
Pro:
- Efficient: More efficient than short polling.
- Support: Simple HTTP(S) request. Nearly universal support. So usually little need for fallback support.
Con:
- Latency: Higher latency compared to WebSocket
- One HTTP handshake, one response: With one HTTP handshake, the server can send response only once.
- Duplicate message: 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.
- Missing message: 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.
WebSocket