Long Polling vs SSE vs WebSockets vs QUIC
Blog / Long Polling vs SSE vs WebSockets vs QUIC
TL;DR Summary Long Polling
What it is How it works Use CasesAdvantagesDisadvantages Server-Sent Events (SSE)
What it is How it works Use CasesAdvantagesDisadvantages WebSockets
What it is How it works Use CasesAdvantagesDisadvantages QUIC (Quick UDP Internet Connections)
What it is How it works 
Use CasesAdvantagesDisadvantages
- Long Polling is a technique where the client repeatedly requests information from the server, keeping the connection open until new data is available, then immediately re-establishing it after receiving a response.
- Server-Sent Events (SSE) is a unidirectional protocol where the server continuously pushes updates to the client over a single, long-lived HTTP connection.
- WebSockets is a full-duplex communication protocol that enables continuous, bidirectional data exchange between a client and server over a single, persistent connection.
- QUIC (Quick UDP Internet Connections) is a transport protocol built on UDP, designed to provide faster, more reliable connections with lower latency and better performance, especially for web and real-time applications like HTTP/3.
Don't let one question ruin your next technical interview...
- Long Polling is a web communication technique where the client makes an HTTP request to the server, and the server keeps the request open until it has new information to send back to the client or a timeout occurs.
- The client sends an HTTP request to the server.
- The server holds the request open until new data is available or a timeout occurs.
- Once the server has data, it sends a response to the client. This completes the original request-response cycle and the connection is closed.
- The client immediately sends another request after receiving the response, restarting the process.
- Monitoring Systems: Ideal for periodically checking for updates, like server or network monitoring tools.
- Data Synchronization: Suitable for infrequent data updates, such as syncing user status or calendar events.
- Compatibility: Works with existing HTTP infrastructure, making it easy to implement without special protocols or libraries.
- Simplicity: Easier to implement and understand compared to more complex protocols.
- Fallback Option: Can serve as a fallback for real-time communication in environments where WebSockets or SSE are not supported.
- Latency: Higher latency compared to WebSockets and SSE, as a new request must be initiated after each response.
- Overhead: Increased HTTP overhead due to frequent request and response cycles.
- Scalability: Can put significant load on the server, especially with a large number of clients.
- Server-Sent Events (SSE) is a unidirectional communication protocol that allows the server to push updates to the client over an HTTP connection.
- The client establishes an HTTP connection to the server and subscribes to a particular event stream. This can be done by creating an instance of the
EventSourceobject in JavaScript. This object takes the URL of the server's event stream as a parameter. - The server sends updates to the client as events occur, using a text-based format (usually UTF-8 encoded).
- The connection remains open as long as the client is subscribed and the server is sending events.
- Live Feeds: Ideal for applications displaying live updates, such as news tickers or financial data dashboards.
- Progress Updates: Useful for providing real-time updates on long-running server-side processes, such as file uploads or data processing tasks.
- Simplicity: Easy to implement with native browser support through the EventSource API.
- Efficiency: Lower overhead compared to Long Polling, as the connection remains open.
- Automatic Reconnection: The client can automatically reconnect if the connection is dropped.
- Unidirectional: Communication is server-to-client only; for bidirectional communication, another channel must be used.
- Browser Support: While widely supported, some older browsers or specific environments may not support SSE.
- Scalability: SSE uses a single TCP connection per client, which can be limiting in scenarios with a large number of clients.
- WebSockets is a protocol that provides full-duplex communication channels over a single, long-lived TCP connection, allowing real-time, bidirectional communication between a client and a server.
- The client initiates a WebSocket handshake, which is an HTTP request upgraded to a WebSocket connection. This is done by including specific headers.
- Once established, the connection allows both client and server to send and receive messages in real-time without the overhead of HTTP.
- The connection remains open, and either side can close it when communication is no longer needed.
- Real-time Messaging Applications: WebSockets enable real-time, bidirectional communication (e.g. Discord).
- Live Notifications and Updates: They are used for pushing live updates to users' interfaces (e.g. Notion).
- Low Latency: Near real-time communication with minimal latency.
- Bidirectional: Allows for two-way communication, enabling interactive applications.
- Efficiency: Less overhead than HTTP-based solutions, as the connection is maintained with minimal handshaking.
- Complexity: More complex to implement and manage than simpler protocols like SSE or Long Polling.
- Firewall/Proxy Issues: Some firewalls and proxies might block or interfere with WebSocket connections.
- Scalability: Managing many WebSocket connections can be challenging for servers.
- QUIC (Quick UDP Internet Connections) is a transport layer network protocol initially developed by Google, designed to improve the performance of HTTP/2 and HTTP/3 by running over UDP, rather than TCP.
- QUIC combines the features of TCP, TLS, and HTTP/2 into a single protocol. It establishes a secure, reliable connection over UDP.
- It allows multiple streams of data to be multiplexed, reducing latency and improving load times.
- QUIC handles packet loss more efficiently than TCP, avoiding head-of-line blocking and enabling faster recovery.
- Video Streaming: Optimized for delivering high-quality video streams with low latency and reduced buffering, especially over unreliable network conditions.
- Mobile Applications: Ideal for apps requiring fast, reliable connections with minimal delay such as location-based services, especially on mobile networks (e.g. Uber).
- Performance: Improved speed and lower latency compared to TCP, especially in poor network conditions.
- Security: Built-in encryption with TLS 1.3 by default, enhancing security.
- Connection Migration: Supports connection migration, allowing ongoing sessions to continue even if the client's IP address changes (e.g., switching from Wi-Fi to cellular).
- Complexity: More complex to implement than traditional TCP, requiring specialized libraries and support.
- UDP Limitations: As it is built on UDP, some networks that restrict or block UDP traffic may prevent QUIC from functioning properly.
- Adoption: While growing, QUIC is still newer and less widely adopted than traditional protocols like TCP.