Polling, SSE & Websockets Flashcards
Purpose of polling, server sent events & websockets
The HTTP standard is widely supported and very functional. But when your application needs to transmit continuous information streams or real-time updates to clients, like a collaborative document editor that shows changes in real time. In cases like this, having to repeatedly make regular HTTP requests will slow things down.
That’s where polling, WebSockets, and SSE come in. These are three protocols that specifically focus on speed and memory efficiency for data streams. Which approach you’d want to use in a system depends on the use case. So, let’s go over how each of these protocols work, and when to use them.
Short polling
Short polling is the original polling protocol for clients to get regular information updates from a server. The steps of short polling are:
Client sends Server an HTTP request for new information.
Server responds with new information, or no information.
Client repeats the request at a set interval (e.g. 2s)
The advantages of Short polling are that it’s very simple and widely supported because it’s part of the HTTP. The downside of short polling is that it has a lot of request overhead from both sides: the client has to constantly make new requests, and the server has to handle them whether or not there’s new information. In practice if you want a polling connection, long polling is preferred to short polling.
Long Polling
Long polling is a more efficient version of short polling. The steps of long polling are:
Client sends Server an HTTP request for new information
Server waits until there’s new information to respond (a “hanging” response)
Client repeats the request as soon as it gets the previous response back
Long polling cuts down the number of HTTP requests necessary to transmit the same amount of data to the client. The server has to be able to “hold” unfulfilled client requests, and handle the case where it gets new information to send, but the client hasn’t sent a new request yet.
The benefits of long polling are that it’s part of the HTTP protocol, so it’s widely supported, and it produces less traffic than short polling because it takes fewer requests. In order to support this, the server-side implementation is slightly more complex than short polling
Drawbacks to long polling
In some implementations holding unfulfilled requests can take more server resources than short polling, and limit the overall number of possible connections. Also if there are multiple open requests from the same client, message ordering can’t be guaranteed, and messages can get lost.
Overall, long polling is a good strategy when you need a simple implementation for regularly updating clients with new information, like updating a dashboard every minute with new data. It won’t handle high volume data streams, and is still slowed down by the overhead of repeatedly reestablishing a connection between server and client.
Server sent events
Server Sent Events provide a one-way connection for a server to push new data to a client, without reestablishing a connection every time. For example a social media app could use SSE to push new posts to a user feed as soon as they’re available. SSE connections follow the EventSource interface, which uses HTTP to make the underlying communications.
At a high level, the steps of SSE are:
Client creates a new EventSource object targeting the server
Server registers SSE connection
Server sends new data to the client
Client receives messages with EventSource handlers
Either side closes the connection
The main benefit of SSEs is it provides an efficient one directional data stream where the client and server don’t need to constantly reestablish the connection. And SSE is fairly straightforward to implement, unlike websockets - EventSource is supported by all the browsers except IE. Luckly, IE support is a common issue so there are libraries for supporting it with polyfills.
Drawbacks to sever sent events
There are a couple of drawbacks to SSEs. If your service outgrows the one-way connection model you’ll just have to switch to a different protocol like WebSockets. SSEs over HTTP (instead of HTTP/2) are also limited to 6 connections per browser, so if a user opens multiple tabs of your website the SSE won’t work after the first 6 tabs.
Overall, SSEs are great when you need a simple implementation for real-time data streams where the client doesn’t need to communicate much with the server, just receive updates. But if you expect your service to need more robust functionality like bi-directional communication, you should consider investing in an implementation of WebSockets.
Websockets
WebSockets is a two-way message passing protocol based on TCP (the protocol at Layer 4 of the OSI networking model). WebSockets are faster for data transmission than HTTP because it has less protocol overhead and operates at a lower level in the network stack. At a high level, the steps of a websocket connection are:
Client and Server establish a connection over HTTP and then “upgraded” using the WebSockets handshake
WebSockets TCP messages are transmitted in both directions over port 443 (or 80 if it’s not TLS encrypted)
Either side closes the connection
The main advantage of WebSockets is speed: the client and server don’t have to find and reestablish their connection with each other every time a message is sent. Once the WebSockets connection is established, data can flow immediately and securely in either direction. TCP ensures that the messages will always arrive in order.
An example where WebSockets is really useful is multiplayer online gaming, where the high-quality graphics of the world need to be transmitted to distributed users with real-time state updates and tight synchronization.
Overall, WebSockets are a good choice if you know you need a fast, high-quality, bi-directional connection. But it should only be used if Polling or SSE don’t fit because it adds substantial complexity to the system and takes more upfront investment to implement.
Downsides to websockets
The main downside of WebSockets is it takes a good amount of initial developer work to implement. You’ll have to write your own code to support some things like automatically reconnecting. Also, since WebSockets functions over ports it can be blocked by firewalls in big institutions.
