title: “Wi-Fi HTTP & WebSocket” difficulty: intermediate —
Sammy the Sensor had two ways to share his readings, and each worked differently!
“HTTP REST is like a restaurant menu,” explained Max the Microcontroller. “The customer (browser) asks ‘What is the temperature?’ and I answer ‘23.5 degrees.’ Each question is separate – the customer has to ask again to get an update. I speak in JSON, which is like a universal language every computer understands: {\"temperature\": 23.5}.”
“WebSocket is like a phone call,” said Lila the LED. “Once you dial in, the line stays OPEN. I can push updates to you every second without you asking! The connection starts as HTTP (like dialing the number), then UPGRADES to WebSocket (like picking up the phone). After that, each message is only 6 bytes of overhead instead of 500 bytes!”
Bella the Battery did the math: “In one hour of readings every second, HTTP uses 1.87 MB but WebSocket uses only 94 KB – that is a 95% bandwidth saving! For battery devices, less data means less radio time means longer battery life!”
“Use HTTP when someone occasionally checks on me,” said Sammy. “Use WebSocket when they want a LIVE dashboard watching me in real-time!”
HTTP vs WebSocket bandwidth comparison:
For 1 hour of sensor readings at 1-second intervals (3,600 transmissions):
HTTP polling (request/response each second):
\[\text{HTTP overhead per cycle} = \text{Request headers} + \text{Response headers}\]
{"temp":23.5})Total for 1 hour: \[3600 \times 496 = 1,785,600\ \text{bytes} = 1.7\ \text{MB}\]
WebSocket (persistent connection):
Total for 1 hour: \[500 + (3600 \times 32) = 115,700\ \text{bytes} = 113\ \text{KB}\]
Bandwidth savings: \[\frac{1,785,600 - 115,700}{1,785,600} \times 100\% = 93.5\%\]
Radio-on time (at 1 Mbps Wi-Fi PHY):
Battery life impact (120 mA TX current, 10 mA idle):
WebSocket saves 4% total power in this scenario (modest because idle dominates). Greater savings occur at higher data rates.
By the end of this chapter, you will be able to:
What is this chapter? Web communication protocols for IoT - when to use HTTP REST APIs vs real-time WebSocket streaming.
HTTP REST (Request/Response): - Best for: On-demand queries, infrequent updates, web integration - Pattern: Client requests, server responds - Overhead: High (headers each request)
WebSocket (Persistent Connection): - Best for: Real-time dashboards, live sensor streaming, low-latency control - Pattern: Bidirectional frames - Overhead: Low (2-14 bytes per message)
Quick Decision Guide:
| Scenario | Use HTTP | Use WebSocket |
|---|---|---|
| Read sensor on demand | Yes | No |
| Live sensor dashboard | No | Yes |
| Firmware update check | Yes | No |
| Remote control (<50ms) | No | Yes |
| Mobile app API | Yes | Either |
Before diving into this chapter, you should be familiar with:
Calculate the bandwidth difference between HTTP polling and WebSocket streaming for your IoT application.
What This Simulates: ESP32 hosting a web server with RESTful API for sensor data and device control
HTTP REST API Pattern:
Client (Browser/App) ESP32 Web Server
| |
|--- GET /api/temperature -->|
| | Read sensor
|<-- 200 OK {"temp":23.5} --|
| |
|--- POST /api/led --------->|
| {"state":"on"} | Control actuator
|<-- 200 OK {"status":"on"}-|RESTful Endpoints:
GET /api/temperature - Read temperature value
GET /api/humidity - Read humidity value
POST /api/led - Control LED (on/off)
GET /api/status - Get device status
PUT /api/config - Update device configurationHow to Use:
What This Simulates: ESP32 WebSocket server providing real-time bidirectional sensor data streaming
WebSocket vs HTTP:
WebSocket Handshake:
1. HTTP Upgrade Request:
GET /ws HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
2. Server Upgrade Response:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
3. Bidirectional frames exchange:
Server - {"temp":23.5,"time":1234567890}
Client - {"command":"led_on"}
Server - {"status":"led_on","success":true}How to Use:
What You Will Observe:
WebSocket Message Types:
| Frame Type | Opcode | Use Case |
|---|---|---|
| Text Frame | 0x01 | JSON, XML, plain text |
| Binary Frame | 0x02 | Protobuf, CBOR, raw data |
| Ping Frame | 0x09 | Keep-alive, latency test |
| Pong Frame | 0x0A | Response to ping |
| Close Frame | 0x08 | Graceful connection close |
WebSocket Frame Structure:
Real-World Applications:
Experiments to Try:
WebSocket vs Other Protocols:
| Protocol | Latency | Bandwidth | Bidirectional | Use Case |
|---|---|---|---|---|
| HTTP REST | 50-100ms | High | No | API queries |
| WebSocket | 1-5ms | Low | Yes | Real-time |
| MQTT | 10-20ms | Very Low | Yes (pub/sub) | IoT events |
| Server-Sent | 20-40ms | Medium | No (one-way) | Notifications |
| UDP | <1ms | Lowest | Yes | Raw data |
Connection Lifecycle:
1. Initial HTTP GET with Upgrade header
2. 101 Switching Protocols response
3. Bidirectional frames (text/binary)
4. Periodic ping/pong (keep-alive)
5. Data exchange continues
6. Close frame when done (graceful shutdown)
Connection duration: Seconds to hours (long-lived)
Reconnection: Only if network failure occursSecurity Considerations:
wss:// (WebSocket Secure) = WebSocket over TLS/SSL
- Encrypted data frames
- Certificate validation
- Port 443 (standard HTTPS port)
- Prevents man-in-the-middle attacks
Authentication:
- Send token in initial HTTP headers
- Validate token before upgrade
- Close connection if unauthorizedPerformance Metrics:
| Metric | Value | Notes |
|---|---|---|
| Frame overhead | 2-14 bytes | vs 500+ for HTTP |
| Latency | 1-5 ms | vs 50-100 ms |
| Max connections (ESP32) | 4-8 | Hardware limited |
| Message rate | 100-1000/s | Depends on payload |
| Memory per connection | ~8 KB | Keep connections low |
When to Use WebSocket:
Determine when WebSocket becomes more efficient than HTTP polling based on message frequency.
:::
For accessibility, here is one common Bianchi-style saturated DCF model form. Symbol choices vary across sources, so focus on the structure and assumptions (saturation traffic, fixed frame sizes, and simplified timing).
Definitions:
\[ P_{\text{idle}} = (1 - \tau)^n \qquad P_{\text{tr}} = 1 - P_{\text{idle}} \qquad P_{\text{s}} = n\,\tau\,(1-\tau)^{n-1} \]
Average slot duration:
\[ \mathbb{E}[\text{Slot}] = P_{\text{idle}}\,\sigma + P_{\text{s}}\,T_{\text{s}} + (P_{\text{tr}} - P_{\text{s}})\,T_{\text{c}} \]
Throughput:
\[ S = \frac{P_{\text{s}}\,L}{\mathbb{E}[\text{Slot}]} \]
Where \(n\) is the number of contending stations, \(\tau\) is the per-slot transmission probability per station, \(L\) is payload length (bits), \(\sigma\) is the idle slot duration, \(T_{\text{s}}\) is the time for a successful transmission, and \(T_{\text{c}}\) is the time lost in a collision. Use this as an intuition-building model; validate capacity with real measurements (airtime utilization, retries, throughput, and latency).
What to Measure (recommended):
iperf3 or representative traffic)Example Output Format (illustrative):
=== Wi-Fi Capacity Check ===
Clients: <N>
Observed throughput: <Mbps>
Latency (p50/p95): <ms>
Retry rate: <percent> (if available)
Recommendations:
- If airtime is high: add AP capacity, reduce client count per AP, or use a wider plan (more APs, better placement)
- If retries are high: improve RSSI/SNR (placement/antennas), reduce interference, or change channels/bands
- If roaming is unstable: increase overlap, tune thresholds, and use fast-roaming features where supportedKey Concepts Demonstrated:
iperf3, latency probes, and AP statsEstimate how many IoT devices a single Wi-Fi access point can support based on your traffic pattern.
Explore these AI-generated figures that illustrate Wi-Fi implementation concepts for IoT devices.
Scenario: A manufacturing plant monitors 50 CNC machines with vibration sensors reporting status every second. The operations team needs a live dashboard showing real-time vibration levels with <5 second latency. Compare HTTP polling vs WebSocket implementation.
Given:
Option 1: HTTP Polling (Naive Approach)
Dashboard polls each machine every second via HTTP GET:
// Dashboard JavaScript (runs in browser)
const machines = Array.from({length: 50}, (_, i) => i + 1);
function pollAllMachines() {
machines.forEach(machineId => {
fetch(`http://192.168.1.${100 + machineId}/api/vibration`)
.then(response => response.json())
.then(data => updateChart(machineId, data));
});
}
setInterval(pollAllMachines, 1000); // Poll every 1 secondHTTP Polling Analysis:
Per HTTP request overhead: - HTTP request headers: ~350 bytes (GET /api/vibration HTTP/1.1 + headers) - HTTP response headers: ~200 bytes (status + content-type + cors) - Payload: 80 bytes - Total: 630 bytes per request
Per second (50 machines): - Data: 50 × 630 = 31,500 bytes = 31.5 KB/sec - Per hour: 31.5 × 3,600 = 113 MB/hour - Per 8-hour shift: 113 × 8 = 905 MB/shift
Latency breakdown: - HTTP connection: 20-30 ms (TCP handshake + TLS if HTTPS) - Request/response: 10-20 ms - Total: 30-50 ms per poll
Problems: 1. High bandwidth: 905 MB/shift for 4 KB of actual data 2. Connection overhead: 50 new TCP connections every second 3. Stale data: Up to 1 second latency between updates 4. Server load: 180,000 HTTP requests/hour (50 machines × 3,600 seconds)
Option 2: WebSocket Real-Time Streaming (Optimized)
Each machine opens a WebSocket connection and pushes data:
// ESP32 WebSocket Server (runs on each CNC sensor)
#include <WiFi.h>
#include <WebSocketsServer.h>
WebSocketsServer webSocket(81);
void webSocketEvent(uint8_t num, WStype_t type, uint8_t * payload, size_t length) {
if (type == WStype_CONNECTED) {
Serial.printf("Dashboard connected: client #%u\n", num);
}
}
void setup() {
WiFi.begin(ssid, password);
while (WiFi.status() != WL_CONNECTED) delay(500);
webSocket.begin();
webSocket.onEvent(webSocketEvent);
}
void loop() {
webSocket.loop();
// Read vibration sensor
float vibX = readVibrationX();
float vibY = readVibrationY();
float vibZ = readVibrationZ();
float temp = readTemperature();
// Create JSON payload
char json[128];
snprintf(json, sizeof(json),
"{\"id\":%d,\"x\":%.2f,\"y\":%.2f,\"z\":%.2f,\"temp\":%.1f,\"ts\":%lu}",
MACHINE_ID, vibX, vibY, vibZ, temp, millis());
// Broadcast to all connected dashboards
webSocket.broadcastTXT(json);
delay(1000); // 1-second interval
}// Dashboard JavaScript
const machines = Array.from({length: 50}, (_, i) => i + 1);
const sockets = [];
machines.forEach(machineId => {
const ws = new WebSocket(`ws://192.168.1.${100 + machineId}:81`);
ws.onmessage = (event) => {
const data = JSON.parse(event.data);
updateChart(machineId, data); // Real-time update as data arrives
};
ws.onerror = (error) => {
console.error(`Machine ${machineId} connection error`);
};
sockets.push(ws);
});WebSocket Analysis:
Initial connection overhead (one-time): - HTTP Upgrade handshake: ~500 bytes - 50 machines: 25 KB total (amortized over session duration)
Per WebSocket frame: - Frame header: 6 bytes (FIN, opcode, mask, payload length) - Payload: 80 bytes - Total: 86 bytes per update
Per second (50 machines): - Data: 50 × 86 = 4,300 bytes = 4.3 KB/sec - Per hour: 4.3 × 3,600 = 15.5 MB/hour - Per 8-hour shift: 15.5 × 8 = 124 MB/shift
Latency: - WebSocket frame: 1-5 ms (no connection setup) - Total: 1-5 ms from sensor to dashboard
Comparison Summary:
| Metric | HTTP Polling | WebSocket | Improvement |
|---|---|---|---|
| Bandwidth/shift | 905 MB | 124 MB | 7.3x reduction |
| Latency | 30-50 ms | 1-5 ms | 10x faster |
| Requests/hour | 180,000 | 0 (persistent) | Eliminates server polling |
| Connection overhead | 350+200 bytes | 6 bytes | 92% reduction |
| Update model | Pull (dashboard polls) | Push (sensor streams) | Real-time |
Real-World Deployment Metrics:
After deploying WebSocket solution: - Dashboard latency: <2 seconds from vibration spike to alert - Network utilization: 4.3 KB/sec vs 31.5 KB/sec (86% reduction) - Server CPU: 5% vs 45% (eliminated request parsing overhead) - Connection stability: 99.97% uptime (persistent connections auto-reconnect)
Advanced Optimization: Binary WebSocket Frames
For maximum efficiency, send binary data instead of JSON:
// Binary frame structure (16 bytes fixed)
struct VibrationData {
uint16_t machineId;
uint16_t timestamp; // Seconds since boot
float vibX;
float vibY;
float vibZ;
float temp;
} __attribute__((packed));
void loop() {
VibrationData data = {
.machineId = MACHINE_ID,
.timestamp = (uint16_t)(millis() / 1000),
.vibX = readVibrationX(),
.vibY = readVibrationY(),
.vibZ = readVibrationZ(),
.temp = readTemperature()
};
// Send as binary frame (opcode 0x02)
webSocket.broadcastBIN((uint8_t*)&data, sizeof(data));
delay(1000);
}Binary frames: 16 bytes (payload) + 6 bytes (header) = 22 bytes/update - Per hour: 50 × 22 × 3,600 = 3.96 MB/hour (3.9x smaller than JSON WebSocket) - Per shift: 3.96 × 8 = 31.7 MB/shift (28x smaller than HTTP polling)
Decision Matrix: When to Use Each Protocol
| Use Case | Best Choice | Reason |
|---|---|---|
| Live industrial dashboard | WebSocket | <5 ms latency, 7x bandwidth savings |
| User checks status once/hour | HTTP REST | No connection overhead for infrequent access |
| 50+ sensors streaming 1/sec | WebSocket | Eliminates CSMA/CA contention |
| Mobile app (background refresh) | HTTP REST + push notifications | Mobile OS limits background WebSocket |
| Browser game (real-time) | WebSocket | Sub-10 ms latency critical |
| Firmware download (large file) | HTTP | Built-in resume support, better caching |
| SCADA system (plant-wide) | MQTT | Pub/sub scales better than 1000s of WebSockets |
Key Insight: WebSocket provides 7-30x bandwidth reduction for continuous streaming by eliminating per-request HTTP headers. The break-even point is ~3-5 updates per connection lifetime. For real-time dashboards updating every second, WebSocket pays back the initial handshake overhead within 5 seconds and provides sub-5ms latency thereafter. The pattern is: HTTP for on-demand queries, WebSocket for live streaming, MQTT for pub/sub IoT networks.
Compare power consumption between HTTP polling and WebSocket for battery-powered IoT devices.
Understanding how these concepts relate helps you choose the right protocol for your application:
| Concept | Depends On | Enables | Trade-off |
|---|---|---|---|
| HTTP REST API | TCP/IP stack, web server | Request/response pattern | High overhead vs simplicity |
| WebSocket | HTTP upgrade, TCP/IP | Bidirectional streaming | Connection management vs efficiency |
| IPHC Compression | Shared prefix knowledge | Reduced bandwidth | State overhead vs payload size |
| CSMA/CA | Carrier sensing, backoff | Channel access fairness | Overhead vs collision avoidance |
| OFDMA | Resource unit allocation | Parallel transmission | Scheduling complexity vs efficiency |
For deeper exploration of related topics:
HTTP is request-response only; the server cannot send data to the device without a device-initiated request. For real-time commands or alerts from cloud to device, use WebSocket (persistent bidirectional connection) or MQTT (publish-subscribe with broker). HTTP polling at frequent intervals (every second) wastes 10-100x more power and bandwidth.
WebSocket connections can be silently terminated by NAT firewalls after inactivity periods (typically 60-300 seconds). Without a ping/pong keepalive mechanism and automatic reconnection, devices silently lose bidirectional communication. Implement both application-level pings and automatic reconnection with exponential backoff.
IoT devices that POST sensor data to REST APIs must process the HTTP response to detect server errors (429 Too Many Requests, 503 Service Unavailable). Silently discarding error responses causes data loss when the server is overloaded. Always parse HTTP status codes and implement retry logic for 5xx server errors.
HTTP requests without timeouts block indefinitely if the server is unreachable. A 30-second or 60-second connection timeout prevents the IoT device from hanging and ensures it retries or reports an error. Always configure both connection timeout and response read timeout for HTTP operations.
This chapter covered HTTP and WebSocket communication for Wi-Fi IoT:
| If you want to… | Read this |
|---|---|
| Optimize power for Wi-Fi IoT devices | Wi-Fi Power Optimization |
| Review complete implementation lab | Wi-Fi Comprehensive Lab |
| Secure the Wi-Fi connection | Wi-Fi Security and Provisioning |
| Understand MQTT for IoT | MQTT Fundamentals |
| Compare with all IoT implementations | Wi-Fi for IoT: Implementations |