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: Link retries can spare TCP a loss response but add variable delay: retries, backoff, and rate adaptation create jitter that may surface as uneven HTTP response time or WebSocket message latency.
Explain: Over the air, the 802.11 MAC acknowledges and retries unicast data frames at the link layer, so some RF losses are recovered before TCP notices.
Explain: A good test measures not only throughput but message age, jitter, reconnect time, and the number of bytes sent while the device is idle.
Explain: Both need clear data shapes, error replies, identity checks, and limits on input.

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

Communication Evidence Record

On the HTTP side, keep the status, headers, data, timeout, and retry result for a full request.

On the WebSocket side, keep the link, message, keepalive, order, and close result for the session.
A TCP link or upgrade reply alone does not prove that either app path worked.

Wi-Fi HTTP and WebSocket evidence record

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

Over Wi-Fi, an IoT device can use two common application patterns.

HTTP is request/response: the device opens or reuses a connection, sends a request, gets a reply, and can let the exchange finish.
WebSocket provides a persistent, full-duplex channel so either side can send while the connection is open.
Phase 2 removes repeated HTTP requests for messages and can carry PING/PONG keepalive in both directions.

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

Major section

Request/Response Versus a Persistent Channel (continued)

Phase 3 shows a normal close with code 1000; abnormal loss may have no close frame.

This HTTP/1.1 WebSocket path uses TCP; HTTP/2 and HTTP/3 WebSockets use Extended CONNECT, and HTTP/3 runs over QUIC.
Wi-Fi retries, contention, roaming, and power-save delay can still affect application latency.
Association and IP reachability do not prove that a command endpoint or persistent session is authorized or handles stale data safely.

Major section

Request/Response Versus a Persistent Channel (continued)

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.
If the requirement is telemetry fan-out, queueing, or gateway translation, HTTP and WebSocket may only be part of the path.
The release record should say which pattern is being accepted and what evidence would force the decision to change.

Major section

Keep-Alive and the WebSocket Upgrade

In both patterns, logs should correlate the exchange without printing tokens, passwords, or personal data.

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/2 and HTTP/3 use Extended CONNECT instead.
Worked example: A thermostat reports every 5 seconds and must receive setpoint changes promptly.

Wi-Fi HTTP and WebSocket communication review route

Major section

How 802.11 Retries and Aggregation Shape TCP

TCP treats visible packet loss as a possible congestion signal and may slow down.

Over the air, the 802.11 MAC acknowledges and retries unicast data frames at the link layer, so some RF losses are recovered before TCP notices.
Broadcast and multicast frames do not receive the same per-recipient acknowledgment.
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)

Link retries can spare TCP a loss response but add variable delay: retries, backoff, and rate adaptation create jitter that may surface as uneven HTTP response time or WebSocket message latency.

A device sending one tiny JSON frame at a time gains little from aggregation and still pays contention and wakeup costs.
TLS record sizing, Nagle behavior, delayed ACKs, proxy buffering, and firmware socket buffers can all turn a "small message" design into delayed delivery.
A good test measures not only throughput but message age, jitter, reconnect time, and the number of bytes sent while the device is idle.

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.
On the HTTP side, keep the status, headers, data, timeout, and retry result for a full request.
Both need clear data shapes, error replies, identity checks, and limits on input.
A lasting two-way channel fits frequent live changes.

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 needs auth, keepalive, disconnect and reconnect tests.

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 because frequent requests give the active control path timely updates.

BTrial WebSocket with disconnect and stale-state checks.

CApprove WebSocket solely on header savings, without session proof.

DRely only on Wi-Fi association, without application state.

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.

CThe endpoint returns JSON for each response because the API uses JSON as its standard representation.

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.

Q4What 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 5 of 6

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

Q5Why 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 sees them.

CIt converts TCP into UDP automatically.

DIt guarantees zero latency for TCP.

Show answer

Answer: B Link-layer retries recover some transient RF losses before TCP notices, which can avoid an unnecessary congestion response; retries also add latency variation (jitter).

Retrieval practice

Recall check 6 of 6

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

Q6A device joins Wi-Fi, but its control request gets no reply. What should the review test next?

ACheck the access point name instead of the request path.

BAssume command success merely from Wi-Fi association.

CTest endpoint, request/reply, auth and failure path

DRetest only the radio join event again.

Show answer

Answer: C Network join does not prove that the device service works.

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.
C · After the 101 Switching Protocols response, the connection carries lightweight frames both ways without per-message HTTP headers.

Print reference

Answers 2 of 2

Answer key.

B · Link-layer retries recover some transient RF losses before TCP notices, which can avoid an unnecessary congestion response; retries also add latency variation (jitter).
C · Network join does not prove that the device service works.