Data transport & protocols

PubNub is protocol-agnostic and chooses the best protocol for the user’s network, so your app stays connected.

SDKs deliver real-time messages over a persistent HTTP connection. Each request stays open for up to 280 seconds waiting for new messages, then resumes from a timetoken cursor on the next request, so no message is missed between requests. For the exact request/response cycle and timeout values, see Subscribe connections.

Browser SDKs use fetch, with an XMLHttpRequest fallback. Node SDKs use pooled HTTP/2 connections where the origin supports it.

Delivery guarantees are enforced above the transport layer, not by it. Messages on a channel keep a single order because PubNub assigns each one a monotonically increasing timetoken (see Message ordering). Durability comes from Message Persistence, and recovery from a gap or disconnect comes from replaying messages published after the last known timetoken (see Handle network interruptions). These properties hold regardless of transport.

PubNub does not use WebSocket. Long-polling over pooled, multiplexed HTTP/2 connections (on supported origins) reuses standard HTTP infrastructure, like proxies, CDNs, load balancers, and corporate firewalls without the connection-upgrade failures and fallback paths WebSocket deployments must handle.

HTTP/2

PubNub supports HTTP/2 on select origins. Clients connecting to supported origins negotiate HTTP/2 automatically. HTTP/1.1 remains fully supported for all clients and endpoints. The goal is the same: to work in any network, use minimal bandwidth, and save power, especially on mobile.

Contact support

To request HTTP/2 support for a custom origin, contact PubNub Support.