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 major PUSH mechanisms—Server-Sent Events, WebSockets, MQTT, Long‑Polling, and Web Push—explaining how each works, where they fit, and how to choose between them. It also covers the universal PUSH lifecycle, architectural patterns, and practical considerations.

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	Server→Browser	Notifications outside browser	Medium

Major PUSH Technologies

Server-Sent Events (SSE)

Lightweight one-way PUSH over a long-lived HTTP connection.
Strengths: simple, efficient, REST-friendly.
Limitations: one-way only; PHP-FPM tuning required.

WebSockets

Full-duplex real-time communication.
Strengths: low-latency, binary support.
Limitations: needs event-driven runtime.

MQTT

Pub/sub protocol designed for IoT and telemetry.
Strengths: massive scalability, durable subscriptions.
Limitations: requires broker, not browser-native.

Long-Polling

Held-open requests until change.
Strengths: universal fallback.
Limitations: inefficient at scale.

Web Push API

Notification delivery even when browser is closed.
Strengths: great for user-centric alerts.
Limitations: not for continuous streams.

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 compat.
• Use Web Push for browser notifications.

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 SSE Works

• Client opens a long‑lived HTTP GET request.
• Server replies with `Content-Type: text/event-stream` and streams events.
• Events may include `data:`, optional `id:` (resume), and optional `event:` (named types).
• Browsers auto‑reconnect and send `Last-Event-ID` when resuming. (Spec details)

Example Event

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

Strengths

• Simple implementation; native `EventSource` API.
• Automatic reconnection and event ID tracking.

Limitations

• One‑way only (server → client); UTF‑8 text only.
• Browser connection limits for HTTP/1 (commonly ~6 per domain).

Deep Dive: WebSockets

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

Handshake

WebSockets begin with an HTTP/1.1 Upgrade request and a 101 Switching Protocols response, then switch to WebSocket frames.

Framing

RFC 6455 defines text, binary, continuation, ping/pong (keep‑alive), and close frames.

Strengths

• True two‑way realtime; supports binary payloads.

Limitations

• Requires event‑driven runtimes (e.g., Node.js, Go, Perl EV/Mojo) rather than PHP‑FPM. (Background per protocol/runtime practice)

Deep Dive: MQTT v5

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

Architecture

Clients publish to topics; subscribers receive from topics; a broker (e.g., Mosquitto, HiveMQ, EMQX) routes messages. (Model per spec)

Key v5 Features

• QoS 0/1/2 (at‑most‑once / at‑least‑once / exactly‑once).
• Session expiry, reason codes, user properties, shared subscriptions, Will messages, enhanced flow control.

Strengths

• Efficient over unreliable networks; scales for IoT/telemetry.

Limitations

• Requires a broker; not browser‑native.

Deep Dive: 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)

Architecture

1) Register a Service Worker → 2) `PushManager.subscribe()` to obtain an endpoint and keys → 3) Server sends encrypted messages to that endpoint → 4) Service Worker handles `push` events (e.g., show notifications).

Strengths

• Works when the tab/app is closed; reliable background delivery.

Limitations

• Higher latency; quotas in some browsers; not for continuous streaming.

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.

Key Features

• TTL, urgency, message replacement, and delivery receipts; interoperates with VAPID (RFC 8292) and encryption (RFC 8291).

References

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