Wi-Fi & 802.11 · Study deck

HTTP and WebSocket over Wi-Fi

Begin with one room sensor and one screen.

Radio Remi is your guide for this deck.

httpwebsocketservice-contracts

Radio Remi, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: Setting up a connection is expensive over Wi-Fi: a TCP three-way handshake plus, for HTTPS, a TLS handshake, with several round trips that can each be delayed by contention or link-layer retries.
Explain: Over the air, though, the 802.11 MAC acknowledges and retransmits every frame at the link layer, so a single fumbled frame is usually recovered by the radio before TCP ever notices.
Explain: Both patterns still ride on TCP and the 802.11 link, so Wi-Fi retries, contention, roaming, and power-save delay remain visible as application latency.

Major section

In 60 Seconds

Under the Hood explains message framing, connection state, and the pressure that a slow receiver can place on the sender.

The device sends one reply.
Later, the screen needs live notice when a door opens.
That second job needs a lasting conversation.
Both jobs need a shared data contract.

Major section

In 60 Seconds (continued)

Real paths cross middle systems and policy limits.

HTTP is a request-response pattern: a client asks for a resource or sends a command, and the device or service replies.
WebSocket is a persistent bidirectional channel: either side can send messages after the connection is established.
The review question is not "Which protocol is faster?" in the abstract.

Major section

Start With The Service Contract

Both need clear data shapes, error replies, identity checks, and limits on input.

Later, it needs live notice when a door opens.
One is a direct question.
The other stays open for changes in either direction.
A short request and reply fits work that happens on demand.

Major section

Start With The Service Contract (continued)

A lasting two-way channel fits frequent live changes.

The screen may close.
The device may restart.
A middle system may end an idle path.
Under the Hood examines framing, connection state, flow control, and the cases where a simple live channel can hide lost or repeated work.

Major section

Request/Response Versus a Persistent Channel

HTTP is request/response: the device opens or reuses a connection, sends a request, gets a reply, and can let the exchange finish.

WebSocket upgrades a single HTTP connection into a persistent, full-duplex channel so either side can send at any time.

WebSocket connection lifecycle: an HTTP upgrade handshake becomes a persistent full-duplex channel

Major section

Request/Response Versus a Persistent Channel (continued)

Phase 2 removes repeated HTTP round trips and carries typed messages plus PING/PONG keepalive in both directions.

Both patterns still ride on TCP and the 802.11 link, so Wi-Fi retries, contention, roaming, and power-save delay remain visible as application latency.
Association and IP reachability do not prove that a command endpoint or persistent session is authorized or handles stale data safely.
Request/response needs endpoint, method, status, payload, timeout, retry, duplicate handling, and support logs.
A stream/session needs open, authentication, message types, keepalive, disconnect detection, reconnect, stale-state display, backpressure, and close behavior.

Major section

Keep-Alive and the WebSocket Upgrade

For HTTP commands, the practical hazard is not only the timeout; it is what happens when a client retries after the timeout.

Setting up a connection is expensive over Wi-Fi: a TCP three-way handshake plus, for HTTPS, a TLS handshake, with several round trips that can each be delayed by contention or link-layer retries.
HTTP keep-alive (default in HTTP/1.1) reuses one TCP connection for many requests, so a device polling every few seconds pays the handshake once instead of every time.
In both patterns, logs should correlate the exchange without printing tokens, passwords, or personal data.

Major section

How 802.11 Retries and Aggregation Shape TCP

That prevents TCP from needlessly shrinking its congestion window after an ordinary RF glitch.

TCP assumes lost packets may mean congestion and slows down when loss is visible end to end.
Throughput over Wi-Fi also depends on frame aggregation.
The application protocol changes how those radio mechanics are felt.

Major section

How 802.11 Retries and Aggregation Shape TCP (continued)

A good test measures not only throughput but message age, jitter, reconnect time, and the number of bytes sent while the device is idle.

Over the air, though, the 802.11 MAC acknowledges and retransmits every frame at the link layer, so a single fumbled frame is usually recovered by the radio before TCP ever notices.
A device sending one tiny JSON frame at a time gains little from aggregation and still pays contention and wakeup costs.
If it also holds a WebSocket open under Wi-Fi power save, each server push may wait for the device's next scheduled wake.

Deck summary

Key takeaways

Under the Hood explains message framing, connection state, and the pressure that a slow receiver can place on the sender.

Real paths cross middle systems and policy limits.
Both need clear data shapes, error replies, identity checks, and limits on input.
A lasting two-way channel fits frequent live changes.
HTTP is request/response: the device opens or reuses a connection, sends a request, gets a reply, and can let the exchange finish.

Retrieval practice

Recall check 1 of 6

Radio Remi says: answer from memory, then check your reasoning.

Q1A technician needs live state while actively controlling a Wi-Fi device from a dashboard. Which pattern fits, and what must be verified?

AHTTP polling, with a short interval to keep the dashboard current.

BEither one, since HTTP and WebSocket behave identically at runtime

CWebSocket, with no need to handle disconnects or stale data

DWebSocket, with evidence for auth, keepalive, disconnect, reconnect.

Show answer

Answer: D Active bidirectional control fits WebSocket, but auth, keepalive, disconnect, reconnect, and stale-data handling must be evidenced.

Retrieval practice

Recall check 2 of 6

Radio Remi says: answer from memory, then check your reasoning.

Q2A local dashboard needs live state while a technician is actively controlling a Wi-Fi device. The implementation can track session state, detect disconnects, and show stale data. Which review decision is strongest?

AUse short-interval HTTP polling.

BUse WebSocket as a candidate

CApprove WebSocket on header savings.

DAvoid application protocols and rely only on Wi-Fi association status.

Show answer

Answer: B Protocol fit depends on the service contract and evidence for both normal and failed communication behavior.

Retrieval practice

Recall check 3 of 6

Radio Remi says: answer from memory, then check your reasoning.

Q3A device sends configuration changes through an HTTP endpoint. After a network timeout, the client retries the same command. What evidence is most important before accepting the implementation?

AThat the command path defines timeout behavior, retry behavior, duplicate handling.

BOnly that the second request eventually returns a success response.

CThat the endpoint returns JSON for every response, regardless of status.

DThat the device can reconnect to Wi-Fi after the timeout.

Show answer

Answer: A HTTP command review must include the failure and retry semantics that determine the device's final state.

Retrieval practice

Recall check 4 of 6

Radio Remi says: answer from memory, then check your reasoning.

Q4When is WebSocket a better fit than plain HTTP request/response for an IoT device?

AWhen the device only posts rare readings and never needs push.

BWhen either side must send live messages on one connection.

CWhen the design must avoid TCP, IP addressing, and sessions.

DWhen every update should pay a fresh request-response round trip.

Show answer

Answer: B WebSocket keeps one persistent full-duplex connection open, avoiding repeated request/response overhead and enabling server push.

Retrieval practice

Recall check 5 of 6

Radio Remi says: answer from memory, then check your reasoning.

Q5What does the WebSocket 'Upgrade' exchange accomplish?

AIt changes the Wi-Fi radio mode from legacy rates to 802.11ax.

BIt replaces TCP with UDP after the first HTTP request.

CIt switches one HTTP connection into a WebSocket frame channel.

DIt adds encryption by itself without using TLS or certificates.

Show answer

Answer: C After the 101 Switching Protocols response, the connection carries lightweight frames both ways without per-message HTTP headers.

Retrieval practice

Recall check 6 of 6

Radio Remi says: answer from memory, then check your reasoning.

Q6Why does the 802.11 MAC's link-layer retransmission generally help TCP throughput over Wi-Fi?

AIt disables TCP acknowledgments to save airtime.

BIt recovers many frame losses before TCP.

CIt converts TCP into UDP automatically.

DIt guarantees zero latency.

Show answer

Answer: B Link-layer ARQ hides transient RF losses from TCP; the trade is added latency variation (jitter).

Print reference

Answers 1 of 2

Answer key.

D · Active bidirectional control fits WebSocket, but auth, keepalive, disconnect, reconnect, and stale-data handling must be evidenced.
B · Protocol fit depends on the service contract and evidence for both normal and failed communication behavior.
A · HTTP command review must include the failure and retry semantics that determine the device's final state.
B · WebSocket keeps one persistent full-duplex connection open, avoiding repeated request/response overhead and enabling server push.

Print reference

Answers 2 of 2

Answer key.

C · After the 101 Switching Protocols response, the connection carries lightweight frames both ways without per-message HTTP headers.
B · Link-layer ARQ hides transient RF losses from TCP; the trade is added latency variation (jitter).