short polling
The client (consumer) sends a request every N seconds
-
pros
- it's easy to understand
- it's easy to implement
-
cons
- difficult to define a proper value for the interval
- increased number of empty responses (or not new data)
- this ends up, to consume resources on the server (broker side)
-
resources that used for every client (consumer) request
- connection management
- authentication/authorization
- rate limiting
- TLS termination
- request validation
- ...
long polling
if there are messages to the queue server (broker) sends the message to the client immediately.
A connection is kept open for a specified interval (this is specified from the client).
-
pros
- less resources consumption
- reduces the number of empty responses
-
cons
- not good when you client expects immediate response from the server (broker)
web sockets
upgrade header included/required (both client and server)!
-
pros
- bi-directional
- re-uses the initial TCP connection
- fast
server-sent events
You can imagine it as a server job runs periodically that sends messages every time a message is available (similar to long polling).
-
use cases
- live feed
- client progress
- logging
-
pros
- simplicity
- compatible HTTP and HTTP/2 (this is not possible with web sockets)
- lightweight (no extra headers)
- Firewall friendly
-
cons
- proxying is tricky
- one way direction
- open connection for a long time
- stateful, difficult to scale horizontally
(Content-Type: text/event-stream)
("data: " + mydata)
Top comments (0)