PUSH Technologies - An Overview

PUSH technologies allow servers to deliver updates to clients instantly when data changes, without requiring repeated polling. This article compares the six major PUSH mechanisms—Server-Sent Events, WebSockets, MQTT, Long‑Polling, Web Push API, and the Web Push Protocol (RFC 8030)—explaining how each works, where they fit, and how to choose between them.

What “PUSH” Means

PUSH reverses the traditional HTTP request/response flow by enabling servers to send updates the moment something meaningful happens. This requires:

• a persistent or semi‑persistent channel
• a subscription mechanism
• a delivery engine
• event triggers

Summary Comparison Table

Technology	Directionality	Ideal Use Cases	Complexity
SSE	Server→Client	Notifications, dashboards, workflow updates	Low
WebSockets	Full‑duplex	Chat, collaboration, presence	Medium–High
MQTT	Pub/Sub	IoT, sensors, distributed systems	Medium
Long‑polling	Simulated PUSH	Legacy fallback	Low
Web Push API	Server→Browser (via Service Worker)	User notifications, app background updates	Medium
Web Push Protocol (RFC 8030)	Server→Push Service→Browser	Reliable delivery, offline notifications	Medium

Major PUSH Technologies

Server‑Sent Events (SSE)

Lightweight one‑way PUSH over a long‑lived HTTP connection.

WebSockets

Full‑duplex real‑time communication.

MQTT

Pub/sub protocol designed for IoT and telemetry.

Long‑Polling

Held‑open requests until change.

Web Push API

Browser-side mechanism for receiving push notifications.

Web Push Protocol (RFC 8030)

Server-to-push-service protocol enabling browser push delivery.

Universal PUSH Lifecycle

1. Discovery/Intent
2. Channel Establishment
3. Subscription Registration
4. Delivery

When to Use What

• Use SSE for simple one‑way notifications.
• Use WebSockets for collaborative apps.
• Use MQTT for IoT/distributed messaging.
• Use Long‑polling for legacy compatibility.
• Use Web Push API for browser notifications.
• Use Web Push Protocol when interacting with push services.

Deep Dive: Server‑Sent Events (SSE)

Server‑Sent Events (SSE) is a server → client streaming technology defined in the HTML Living Standard. Clients receive UTF‑8 encoded events over a long‑lived HTTP connection via the JavaScript `EventSource` interface. (Spec: WHATWG HTML — Server‑Sent Events)

How it Works

• Client opens a long‑lived HTTP GET request.
• Server streams events using `text/event-stream`.
• Events support `data:`, `id:` and `event:` fields.
• Browsers auto‑reconnect with `Last-Event-ID`.

Example

id: 583
event: order_update
data: {"order":123,"status":"shipped"}

Deep Dive: WebSockets

WebSockets provide full‑duplex, low‑latency communication over a single TCP connection, standardised by IETF RFC 6455.

How it Works

WebSockets create a persistent, full‑duplex communication channel between a client and a server. The connection begins as a normal HTTP/1.1 request, but then upgrades to the WebSocket protocol as defined in IETF RFC 6455. This upgrade transforms the traditional request–response cycle into a continuous, bidirectional data stream. [1](https://pirho-my.sharepoint.com/personal/dex_pirho_net/Documents/Microsoft%20Copilot%20Chat%20Files/PUSH_Technologies_Deep_Dives_MediaWiki.txt)

1. The Opening Handshake

The WebSocket workflow starts with an HTTP `GET` request sent from the client, containing special headers that request a protocol upgrade:

GET /ws HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: (random base64 string)
Sec-WebSocket-Version: 13

If the server supports WebSockets, it responds with a `101 Switching Protocols` message:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: (derived from Sec-WebSocket-Key)

Once this handshake succeeds, **the connection is no longer HTTP** — it becomes a raw WebSocket channel. [1](https://pirho-my.sharepoint.com/personal/dex_pirho_net/Documents/Microsoft%20Copilot%20Chat%20Files/PUSH_Technologies_Deep_Dives_MediaWiki.txt)

2. Framing and Continuous Communication

After the upgrade, both client and server exchange *WebSocket frames* instead of HTTP messages. RFC 6455 defines several frame types, including:

• **Text frames** — UTF‑8 payloads
• **Binary frames** — arbitrary binary data
• **Continuation frames** — fragmented message parts
• **Ping/Pong frames** — keep‑alive and latency checks
• **Close frames** — graceful shutdown

Each message may be a single frame or span multiple frames, allowing very efficient, low‑latency transfers. [1](https://pirho-my.sharepoint.com/personal/dex_pirho_net/Documents/Microsoft%20Copilot%20Chat%20Files/PUSH_Technologies_Deep_Dives_MediaWiki.txt)

3. Full‑Duplex Operation

Once active, a WebSocket connection allows both endpoints to:

• send data **independently**, without waiting for a request
• send messages at any time
• stream events instantly in either direction

This makes the protocol ideal for scenarios such as live chat, collaboration tools, multiplayer updates, and dashboards — where the server needs to push updates without being polled. [1](https://pirho-my.sharepoint.com/personal/dex_pirho_net/Documents/Microsoft%20Copilot%20Chat%20Files/PUSH_Technologies_Deep_Dives_MediaWiki.txt)

4. Maintaining the Connection

To keep the socket healthy:

• Clients or servers send **ping** frames
• The recipient must reply with **pong** frames
• Missed pings often indicate network failure
• The connection may be closed with a controlled **close** frame

These behaviours are explicitly defined in RFC 6455 as part of WebSocket’s reliability model. [1](https://pirho-my.sharepoint.com/personal/dex_pirho_net/Documents/Microsoft%20Copilot%20Chat%20Files/PUSH_Technologies_Deep_Dives_MediaWiki.txt)

5. Closing the Connection

A WebSocket session ends with a `close` frame containing a close code and optional explanation. After a close handshake, both sides must stop sending frames and release the underlying TCP connection. [1](https://pirho-my.sharepoint.com/personal/dex_pirho_net/Documents/Microsoft%20Copilot%20Chat%20Files/PUSH_Technologies_Deep_Dives_MediaWiki.txt)

Framing

Supports text, binary, continuation, ping/pong and close frames.

Deep Dive: MQTT v5

MQTT v5 is a lightweight publish/subscribe messaging protocol optimised for constrained networks; it is an OASIS Standard.

How it Works

MQTT is a lightweight publish/subscribe messaging protocol designed for efficient communication across unreliable or bandwidth‑constrained networks. Its behaviour and wire format are defined in the OASIS MQTT v5.0 Standard, which specifies the client–server roles, message exchange patterns, quality-of-service levels, session control, and metadata features. [1](https://docs.racket-lang.org/rfc6455/index.html)

1. Client–Broker Architecture

Unlike WebSockets or SSE, MQTT does not create a direct connection between publishers and subscribers. Instead, all communication flows through a central **broker**:

• Clients publish messages to named **topics**
• Subscribers express interest in one or more topics
• The broker routes messages from publishers to all matching subscribers

This architecture decouples senders and receivers in space, time, and execution flow. It is core to MQTT’s suitability for IoT, telemetry, and distributed systems. [1](https://docs.racket-lang.org/rfc6455/index.html)

2. Establishing the Connection

MQTT uses a persistent TCP connection (or any reliable, ordered, bi‑directional transport). A client begins by sending a **CONNECT** packet, which includes:

• protocol version
• client identifier
• optional username/password
• session expiry interval
• authentication data
• Will message (optional message sent on disconnect)

If the broker accepts the session, it responds with a **CONNACK** containing reason codes and connection parameters. These values follow the v5.0 specification. [1](https://docs.racket-lang.org/rfc6455/index.html)

3. Subscribing to Topics

To receive messages, the client sends a **SUBSCRIBE** packet specifying:

• topic filters (e.g., `sensors/temperature`)
• desired QoS level
• optional subscription identifiers
• optional user properties

The broker acknowledges with **SUBACK**, including success/failure reason codes for each subscription. Topic filters may include wildcards, enabling expressive and flexible subscription patterns. [1](https://docs.racket-lang.org/rfc6455/index.html)

4. Publishing Messages

Messages are published with a **PUBLISH** packet, containing:

• topic name
• payload
• QoS level
• retain flag
• user properties
• correlation data (for request/response patterns)

The broker forwards the message to all clients subscribed to the topic.

MQTT v5 supports three QoS modes:

• **QoS 0 – At most once** (fire‑and‑forget)
• **QoS 1 – At least once** (acknowledged delivery)
• **QoS 2 – Exactly once** (two‑phase handshake for guaranteed delivery)

These delivery controls are explicitly defined in the v5.0 standard. [1](https://docs.racket-lang.org/rfc6455/index.html)

5. Session & State Management

MQTT v5 introduces advanced session features, including:

• **Session expiry** (persistent or ephemeral sessions)
• **Reason codes** for all acknowledgements
• **Flow control**
• **Request/response correlation**
• **Topic aliases** to reduce packet size

Clients may reconnect and resume sessions depending on the session expiry interval. If a session is persistent, the broker stores pending messages while the client is offline. [1](https://docs.racket-lang.org/rfc6455/index.html)

6. Heartbeats & Liveness

MQTT maintains connection health through the **Keep Alive** timer:

• Client specifies a heartbeat interval
• Broker expects traffic at least once per interval
• If no packets arrive, the broker closes the connection

Clients also monitor **DISCONNECT** frames, which may include explanatory reason codes as defined in the v5.0 specification. [1](https://docs.racket-lang.org/rfc6455/index.html)

7. Closing the Connection

A client may gracefully end the session by sending **DISCONNECT**, optionally specifying:

• session expiry
• user properties
• reason codes (e.g., normal disconnect, error conditions)

The broker may also send DISCONNECT if protocol violations occur. [1](https://docs.racket-lang.org/rfc6455/index.html)

Key Features

QoS levels, user properties, will messages, shared subscriptions.

Deep Dive: Long‑Polling

Long‑polling simulates PUSH over repeated held HTTP requests.

How it Works

Long‑polling is a technique that simulates server‑initiated updates over traditional HTTP. Instead of opening a persistent connection or upgrading to another protocol, the client sends an HTTP request that the server deliberately holds open until new data becomes available. When the server responds, the client immediately opens a new request, creating the illusion of a continuous stream.

Long‑polling is not a formal protocol; rather, it is a behavioural pattern built on top of standard HTTP and widely used before WebSockets, SSE, and Push APIs became available.

1. Client Sends a Long‑Lived Request

The client sends an HTTP request (typically a `GET` or `POST`) to a dedicated long‑poll endpoint. Unlike normal request/response patterns, the server does **not** respond immediately.

This initial request expresses the client’s intent to “wait for updates.”

2. Server Holds the Connection Open

The server keeps the request open until one of the following happens:

• **New data becomes available**
• **A timeout is reached**
• **The server chooses to return an empty/no‑op response**

While the connection is open, the server does not send partial data (unless using chunked transfer, which becomes a different pattern closer to SSE).

3. Server Responds When an Event Occurs

When something meaningful happens — such as a database update, a new message, or a completed job — the server sends a full HTTP response containing the update.

A typical response might be JSON, XML, or any other application payload.

The request then terminates normally.

4. Client Immediately Reconnects

As soon as the client receives the server’s response, it:

1. processes the data 2. opens a **new** long‑poll request

This cycle continues indefinitely.

The reconnect step is what creates the “pseudo‑realtime” behaviour. Even though the server never initiates a network call, the user experience resembles PUSH.

5. Heartbeats and Timeouts

Most implementations include:

• **server‑side timeouts** to avoid holding dead connections
• **client‑side retry intervals**
• optional **heartbeat messages** if no data is available

Timeouts prevent idle connections from exhausting server resources.

6. Handling Multiple Clients

Because each long‑poll request consumes one connection, servers need to manage concurrency carefully:

• thread‑per‑request models scale poorly
• event‑driven servers (Node.js, NGINX, or Perl event loops) handle long‑polling more efficiently
• horizontal scaling and load balancing are common in production

This is one of the limitations that motivated the creation of WebSockets and SSE.

7. Closing the Connection

Either the client or server may close the connection at any time. If the client closes unexpectedly, the server detects the failure and cleans up resources.

If the server closes due to timeout, a well‑behaved client simply reconnects.

Summary

Long‑polling maintains compatibility with older browsers and servers because it uses plain HTTP, but it is less efficient and less scalable than modern PUSH technologies like SSE, WebSockets, and dedicated push services. It remains a valid fallback technique for legacy environments or systems with restricted networking options.

Deep Dive: Web Push API (W3C)

The Push API enables web apps to receive messages when not active, via Service Workers and a browser push service. (W3C latest published version)

How it Works

The Web Push API enables web applications to receive push messages from a server even when the webpage is not open, using a Service Worker as the delivery endpoint. It is defined by the W3C Push API specification and relies on a browser‑specific push service to route messages from the application server to the user agent. [1](https://archive.org/details/rfc8030)

1. Service Worker Registration

To participate in Web Push, a site must first register a **Service Worker**. Service Workers run independently of webpage lifecycles, allowing notifications to be received when no tab is active. This background execution environment is required before a push subscription can be created. [2](https://www.ns.kogakuin.ac.jp/manabe/pdf/ItoPush.pdf)

2. Creating a Push Subscription

The web application calls `PushManager.subscribe()` from within the Service Worker or client script. This process involves:

• generating an application‑specific key pair
• requesting user permission for notifications
• establishing options such as `userVisibleOnly`
• registering with the browser’s push service

The result is a **PushSubscription** containing:

• a unique endpoint URL
• public encryption keys
• metadata required for the server to send push messages

This endpoint is managed by the push service (e.g., Google, Mozilla, Apple), not the website. [2](https://www.ns.kogakuin.ac.jp/manabe/pdf/ItoPush.pdf)

3. Application Server Sends a Push Message

When the backend needs to notify the user, it sends an encrypted push message to the subscription endpoint. This request always passes through the browser vendor’s **push service**, which:

• validates the request
• stores the message if needed
• forwards it when the user agent is reachable

This routing behaviour is aligned with the specification’s definition of a push service as an intermediary for message delivery. [1](https://archive.org/details/rfc8030)

4. Push Service Delivers the Message

When the user agent becomes reachable, the push service delivers the message. If the user is offline, the push service may temporarily store the message until delivery is possible, allowing the application to receive updates even after downtime. This supports use cases where alerts must be delivered regardless of whether the application is currently open. [3](https://github.com/w3c/push-api)

5. Service Worker Handles the Push Event

Once the browser receives the push message, it launches (or activates) the Service Worker and fires the `push` event. Within this handler, the application can:

• parse the message payload
• update local data
• show a system notification using `ServiceWorkerRegistration.showNotification()`
• trigger background logic

This enables websites to deliver timely messages without maintaining persistent connections. [2](https://www.ns.kogakuin.ac.jp/manabe/pdf/ItoPush.pdf)

6. Displaying Notifications

If the push message requires user-visible activity, the Service Worker displays a notification. This is mandated by some browser quotas: silent pushes may be limited, whereas notifications reset quotas and improve reliability. [2](https://www.ns.kogakuin.ac.jp/manabe/pdf/ItoPush.pdf)

7. Subscription Lifecycle Management

Subscriptions may expire or be invalidated by:

• user revoking permission
• push service endpoint rotation
• browser data being cleared
• service worker replacement

Applications should periodically verify and refresh subscriptions to maintain long‑term delivery reliability. [1](https://archive.org/details/rfc8030)

Deep Dive: Web Push Protocol (RFC 8030)

RFC 8030 defines the HTTP‑based protocol used by application servers to send push messages to push services, which then deliver them to user agents.

How it Works

The Web Push Protocol, defined in IETF RFC 8030, specifies how an application server sends real‑time push messages to a push service, which then delivers them to the user agent. Rather than sending messages directly to a browser, the application server communicates with an intermediary push service using HTTP/2‑based message delivery semantics. This decouples the application server from the user's network state and allows reliable delivery even when the browser is offline. [1](https://www.hivemq.com/blog/mqtt5-now-an-approved-oasis-standard/)

1. Application Server Sends a Push Request

To initiate a push, the application server contacts the push service endpoint associated with a user's subscription. The server issues an authenticated HTTP request containing:

• encrypted payload
• TTL (time-to-live)
• urgency level
• topic or collapse identifiers (optional)

RFC 8030 defines this as a simple, standardised HTTP‑based event delivery mechanism using HTTP/2 server push semantics. [1](https://www.hivemq.com/blog/mqtt5-now-an-approved-oasis-standard/)

2. Push Service Validates and Stores the Message

Upon receiving the request, the push service:

• validates authentication
• checks request headers
• stores the message if the user agent is unreachable

The push service acts as a reliable message buffer. RFC 8030 explicitly describes this message queuing behaviour and the push service’s responsibility for holding the message until the user agent becomes available. [1](https://www.hivemq.com/blog/mqtt5-now-an-approved-oasis-standard/)

3. User Agent Becomes Reachable

When the browser (user agent) re-establishes connectivity, the push service initiates delivery. The protocol ensures that:

• messages are delivered in a timely manner
• expired messages (based on TTL) are discarded
• urgent messages may be prioritised

The delivery stage is part of RFC 8030’s “receiving push messages for a subscription.” [1](https://www.hivemq.com/blog/mqtt5-now-an-approved-oasis-standard/)

4. Push Service Delivers the Message

The push service sends the message to the user agent using its internal delivery channel. This step corresponds to the protocol’s real-time event delivery flow, where events are pushed from the service to the agent using the mechanisms defined by the browser vendor’s implementation, not HTTP directly. [1](https://www.hivemq.com/blog/mqtt5-now-an-approved-oasis-standard/)

5. Browser Triggers the Service Worker

When the user agent receives the message, it fires a **push event** in the Service Worker. RFC 8030 describes that receiving the push message completes the delivery phase of the protocol. The Service Worker can then:

• inspect the payload
• update local application state
• display a notification
• process background logic

This behaviour underpins the Web Push ecosystem used by modern browsers. [1](https://www.hivemq.com/blog/mqtt5-now-an-approved-oasis-standard/)

6. Delivery Receipts (Optional)

RFC 8030 includes the concept of **push receipts**, allowing the user agent to send acknowledgements back through the push service. This provides a mechanism for application servers to confirm that a message was successfully delivered to the browser. [1](https://www.hivemq.com/blog/mqtt5-now-an-approved-oasis-standard/)

7. Message Expiry and Replacement

The protocol defines:

• TTL headers to expire undelivered messages
• urgency levels to indicate delivery priority
• “push message replacement” mechanisms (overwrite older messages with the same topic)

These controls allow efficient and predictable message routing. [1](https://www.hivemq.com/blog/mqtt5-now-an-approved-oasis-standard/)

Summary

The Web Push Protocol provides a standards-based, reliable mechanism to deliver events from an application server to a browser, using a push service as an intermediary. It enables offline-capable notifications, reduces server complexity, and integrates with the browser’s Push API and Service Worker ecosystem. [1](https://www.hivemq.com/blog/mqtt5-now-an-approved-oasis-standard/)

References

• Server-Sent Events — WHATWG
• WebSockets — IETF RFC 6455
• MQTT v5 — OASIS
• Push API — W3C
• Web Push Protocol — IETF RFC 8030