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.

Flow

1. Client publishes
2. Broker routes
3. Subscribers receive.

Key Features

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

Deep Dive: Long‑Polling

Long‑polling simulates PUSH over repeated held HTTP requests.

Flow

1. Client opens request.
2. Server holds connection until event.
3. Client reconnects.

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)

Flow

1. Register Service Worker.
2. Subscribe via `PushManager.subscribe()`.
3. Browser obtains endpoint.
4. Service Worker receives notifications.

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

• App server sends (encrypted) message to a push service over HTTP/2.
• Push service stores and forwards to the user agent when reachable.
• Browser wakes the Service Worker `onpush` handler to process the message.

References

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