WebSockets

What are WebSockets?

WebSockets is a communication protocol defined in RFC 6455 (2011) that provides a full-duplex, bidirectional channel over a single, long-lived TCP connection. Unlike HTTP , where the client must initiate every exchange and wait for a response, WebSockets allow either end – client or server – to send messages at any time, independently, with minimal overhead.

The protocol was designed to solve a fundamental limitation of HTTP for interactive applications: the need for the server to push data to clients in real time without polling. Once the WebSocket connection is established, it behaves like a persistent, low-latency pipe. This makes it the natural choice for live RFID tag read streams, real-time inventory dashboards, and reader management consoles where sub-second updates are expected.

How it works

A WebSocket connection begins as a standard HTTP/1.1 request. The client signals its intent to upgrade the connection by including specific headers, and the server responds with a 101 Switching Protocols status code. After this handshake, the TCP connection is no longer HTTP – it becomes a WebSocket channel, and the HTTP framing is discarded entirely.

• HTTP upgrade handshake: The client sends a GET request with the headers Upgrade: websocket, Connection: Upgrade, and a base64-encoded random nonce in Sec-WebSocket-Key. The server responds with 101 Switching Protocols and a derived Sec-WebSocket-Accept value proving it received the key. TLS (wss://) wraps this identically to HTTPS.
• Persistent connection: After the handshake, the TCP connection stays open indefinitely. There is no per-message request/response overhead – no headers are re-sent for each message. A WebSocket frame adds as few as 2 bytes of overhead to a small payload, compared with hundreds of bytes for an equivalent HTTP request.
• Frames: Data is transmitted as binary frames. Each frame has a small header containing an opcode (text, binary, ping, pong, close), a masking bit (client-to-server frames are always masked by the RFC), and a payload length. Text frames carry UTF-8; binary frames carry arbitrary bytes. Applications typically send JSON or MessagePack over text or binary frames.
• Ping/pong keepalive: Either side can send a ping control frame at any time. The recipient must respond with a pong containing the same payload. This mechanism detects broken connections and keeps the TCP session alive through NAT gateways and load balancers that would otherwise close idle connections.
• Graceful close: Either side initiates closure by sending a close frame with an optional status code and reason. The other side echoes the close frame, and both ends then close the TCP connection.

WebSockets in RFID and IoT

RFID systems generate continuous streams of events – tag reads, tag losses, antenna state changes, reader heartbeats – that need to reach operator dashboards and upstream systems with minimal delay. WebSockets are well-suited to this because the server can push every event as it occurs rather than waiting for a client to poll.

• Real-time dashboards: A browser-based RFID inventory dashboard opens a single WebSocket connection to the backend. The server pushes tag read events as they arrive from readers, updating item counts and location data in real time without any polling interval introducing lag.
• Live tag read streams: Reader middleware (such as an LLRP -to-WebSocket bridge) translates raw reader protocol messages into JSON frames and streams them to subscribers. Multiple browser clients can subscribe to the same stream over separate WebSocket connections.
• Reader event feeds: Reader management platforms use WebSockets to surface reader status events (connection, disconnection, antenna fault, temperature alarm) to operators the instant they occur, rather than on the next polling cycle.
• MCP servers: The Model Context Protocol (MCP) uses JSON-RPC 2.0 over WebSockets as one of its transport options, allowing AI agents to communicate with RFID and IoT tool servers with low latency over persistent connections.
• Bidirectional reader control: Unlike SSE, WebSockets allow the dashboard to send commands back to the server over the same connection – for example, starting or stopping a reader, changing antenna power, or acknowledging an alarm – without opening a separate HTTP request channel.

WebSockets vs Server-Sent Events (SSE)

Server-Sent Events (SSE) is a simpler alternative for server-to-client streaming over HTTP/1.1 or HTTP/2. Choosing between them depends on whether bidirectional communication is required.

Advantages

• Real-time bidirectional: Both the client and server can send messages at any time. A single connection carries RFID event pushes from the server and control commands from the client simultaneously.
• Low latency: No connection setup overhead per message. After the initial handshake, frames are transmitted with 2–14 bytes of framing overhead, making WebSockets significantly faster than polling.
• Browser-native: The WebSocket API is built into every modern browser. No libraries or plugins are required for client-side use.
• Works through HTTP proxies: The initial upgrade request is a standard HTTP GET. Proxies that support the Upgrade header (most modern reverse proxies including nginx and Caddy) will tunnel the connection transparently.
• TLS support: The wss:// scheme wraps WebSockets in TLS identically to HTTPS, providing the same transport security.
• Binary and text frames: Applications can choose between UTF-8 text (for JSON) and raw binary (for compact formats like MessagePack or CBOR), making WebSockets flexible for different RFID data payloads.

Limitations

• Stateful connections: Each WebSocket connection is stateful and tied to a specific server instance. This makes horizontal scaling more complex than stateless HTTP – a load balancer must use sticky sessions or a pub/sub broker (such as Redis) to route messages across multiple server nodes.
• Harder to scale horizontally: Thousands of concurrent persistent connections consume server resources (file descriptors, memory) even when idle. Systems expecting very large numbers of simultaneous clients need careful capacity planning.
• No built-in QoS or message queuing: WebSockets provide no delivery guarantees. If a connection drops, messages sent during the outage are lost unless the application implements its own buffering and replay. MQTT is purpose-built for this with its QoS levels and persistent sessions.
• Firewall and corporate proxy issues: Some older firewalls and transparent proxies block or strip the Upgrade header, preventing WebSocket connections from being established. wss:// over port 443 mitigates most cases, but restrictive enterprise networks may still interfere.
• Not HTTP after upgrade: Standard HTTP tooling (caching, CDN edge caching, HTTP/2 multiplexing) does not apply to WebSocket frames. Each connection must be managed at the application layer.
• No built-in topic routing: WebSockets are point-to-point channels. Fan-out to multiple subscribers, topic filtering, and message routing must be implemented at the application layer, unlike MQTT which handles this natively through its broker and topic hierarchy.

Common applications in RFID

• Live RFID inventory dashboards: Browser-based warehouse or retail dashboards that display item counts, zone occupancy, and tag movement in real time. The server pushes each tag read event as it arrives from readers, with no polling delay.
• Real-time tag tracking displays: Visual floor-plan displays showing tagged asset positions updating continuously as UHF RFID readers detect tag movements across zones or dock doors.
• Reader management consoles: Operator interfaces for configuring, monitoring, and controlling RFID readers. WebSockets allow the console to receive reader status events instantly and send configuration commands back over the same connection.
• RFID middleware event buses: Middleware platforms (Impinj Octane, FEIG, Zebra FX) expose WebSocket endpoints that downstream applications subscribe to, receiving a continuous stream of tag reads without polling the middleware API.
• IoT gateway dashboards: Edge gateways aggregating data from multiple readers and sensors expose WebSocket feeds to local operator displays, enabling real-time visibility without cloud round-trips.

WebSockets vs MQTT vs HTTP comparison

Related protocols