848  Wi-Fi Implementation: HTTP and WebSocket

848.1 Learning Objectives

By the end of this chapter, you will be able to:

• Build HTTP REST APIs: Implement ESP32 web servers with RESTful endpoints for sensor data and device control
• Create HTTP Clients: Send HTTP GET/POST requests to cloud services and local servers
• Implement WebSocket Communication: Establish real-time bidirectional data streaming
• Understand Protocol Trade-offs: Choose between HTTP, WebSocket, and MQTT for different IoT scenarios
• Analyze Network Capacity: Evaluate Wi-Fi throughput and latency for IoT deployments

TipFor Beginners: HTTP vs WebSocket for IoT

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

848.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• Wi-Fi Implementation: ESP32 Basics: Basic Wi-Fi connection and configuration
• HTTP Protocol Basics: Understanding of HTTP request/response patterns

848.3 HTTP REST API on ESP32

TipInteractive Simulator: ESP32 Web Server (HTTP REST API)

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 configuration

How to Use: 1. Click Start Simulation 2. Wait for “HTTP server started” message 3. Note the IP address (simulated: 192.168.1.100) 4. See GET/POST requests being processed 5. Observe JSON responses with sensor data

NoteLearning Points

What You Will Observe:

1. HTTP Methods - GET for reading, POST for actions, PUT for updates
2. JSON Responses - Structured data format for IoT
3. RESTful Design - Resource-based URLs (/api/temperature)
4. Stateless Protocol - Each request independent
5. CORS Headers - Cross-origin resource sharing for web apps

HTTP Request/Response Cycle:

1. Client sends HTTP request
   GET /api/temperature HTTP/1.1
   Host: 192.168.1.100
   Accept: application/json

2. ESP32 processes request
   - Parse URL path
   - Execute handler function
   - Read DHT22 sensor
   - Format JSON response

3. ESP32 sends HTTP response
   HTTP/1.1 200 OK
   Content-Type: application/json
   Content-Length: 25

   {"temperature":23.5}

4. Client receives and parses JSON

REST API Design Principles:

Principle	Example	Why Important
Resource-based URLs	/api/sensors/temp	Clear hierarchy
HTTP methods	GET (read), POST (create)	Standard semantics
Status codes	200 OK, 404 Not Found	Error handling
JSON format	{“temp”:23.5}	Universal parsing
Stateless	Each request complete	Scalability

HTTP Status Codes for IoT:

200 OK              - Request successful
201 Created         - Resource created (POST)
204 No Content      - Success with no response body
400 Bad Request     - Invalid JSON or parameters
404 Not Found       - Endpoint doesn't exist
405 Method Not Allowed - Wrong HTTP method
500 Internal Error  - Sensor read failure
503 Service Unavailable - Device offline

Real-World Applications:

1. Smart Home - Control lights, thermostats via web interface
2. Industrial IoT - Factory machines with HTTP APIs for monitoring
3. Agriculture - Soil sensors providing data to web dashboards
4. Building Management - HVAC systems with RESTful control
5. Energy Monitoring - Smart meters with HTTP data export

Experiments to Try:

1. Add New Endpoints - Implement /api/humidity, /api/pressure
2. Authentication - Add API key validation (Authorization header)
3. Rate Limiting - Limit requests to 10/minute per client
4. WebSocket Upgrade - Add real-time streaming endpoint
5. mDNS Discovery - Enable http://esp32-sensor.local/

HTTP vs MQTT for IoT:

Feature	HTTP REST	MQTT
Pattern	Request/Response	Pub/Sub
Overhead	High (headers)	Low (binary)
Power	Medium-High	Low
Discovery	URLs	Topics
Real-time	Polling required	Push notifications
Complexity	Simple, universal	Requires broker
Best for	On-demand queries	Event streams

Use HTTP when: Direct device access, web integration, infrequent updates

Use MQTT when: Continuous streaming, low power, many-to-many communication

Performance Metrics:

Metric	Typical Value	Optimization
Response Time	10-50 ms	Keep handlers simple
Concurrent Requests	4-10	Use async web server
Memory Usage	8-16 KB	Limit response size
Connection Time	100-200 ms	Persistent connections
Throughput	1-10 req/s	Hardware dependent

848.4 WebSocket Real-Time Communication

TipInteractive Simulator: WebSocket Real-Time Communication

What This Simulates: ESP32 WebSocket server providing real-time bidirectional sensor data streaming

WebSocket vs HTTP:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1', 'nodeBorder': '#2C3E50'}}}%%
sequenceDiagram
    participant Client
    participant Server

    Note over Client,Server: HTTP Polling (Inefficient)
    loop Every second
        Client->>Server: GET /sensor/data
        Server-->>Client: 200 OK (headers: 500B)
    end

    Note over Client,Server: WebSocket (Efficient)
    Client->>Server: HTTP Upgrade Request
    Server-->>Client: 101 Switching Protocols
    Server->>Client: Data frame (6B header)
    Server->>Client: Data frame (6B header)
    Server->>Client: Data frame (6B header)

Figure 848.1: HTTP Polling vs WebSocket Efficiency Comparison for IoT Data Streaming

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: 1. Click Start Simulation 2. WebSocket server starts on ws://192.168.1.100:81 3. Watch real-time sensor data streaming every second 4. See client commands being processed instantly 5. Observe persistent connection (no reconnection overhead)

NoteLearning Points

What You Will Observe:

1. Persistent Connection - Once established, stays open for continuous data
2. Low Latency - No HTTP overhead for each message (~1-5ms vs 50-100ms)
3. Bidirectional - Both client and server can initiate messages
4. Event-Driven - Push model instead of polling
5. Binary/Text Frames - Efficient data encoding

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:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1'}}}%%
graph LR
    subgraph "WebSocket Frame Structure"
        FIN["FIN<br/>1 bit"]
        RSV["RSV<br/>3 bits"]
        OPCODE["Opcode<br/>4 bits"]
        MASK["Mask<br/>1 bit"]
        LEN["Length<br/>7 bits"]
        KEY["Masking Key<br/>4 bytes"]
        DATA["Payload<br/>N bytes"]
    end

    FIN --> RSV --> OPCODE --> MASK --> LEN --> KEY --> DATA

    style FIN fill:#2C3E50,color:#fff
    style OPCODE fill:#16A085,color:#fff
    style DATA fill:#E67E22,color:#fff

Figure 848.2: WebSocket Frame Structure with Header Fields and Payload Components

Bandwidth Comparison:

Scenario: Send temperature every 1 second for 1 hour

HTTP Polling (every 1s):
- Requests: 3,600
- Headers: ~500 bytes/request
- Data: 20 bytes/request
- Total: (500+20) x 3,600 = 1.87 MB
- Overhead: 96%

WebSocket Streaming:
- Connection setup: 500 bytes (once)
- Frame headers: 6 bytes/message
- Data: 20 bytes/message
- Total: 500 + (6+20) x 3,600 = 94 KB
- Overhead: 23%

Savings: 95% bandwidth reduction!

Real-World Applications:

1. Smart Home Dashboards - Real-time sensor graphs without page refresh
2. Industrial Monitoring - Live factory machine data streams
3. Healthcare - Continuous patient vital signs monitoring
4. Robotics - Low-latency remote control commands
5. Energy Management - Live power consumption graphs

Experiments to Try:

1. Multiple Clients - Connect multiple browsers to same ESP32
2. Broadcast Messages - Server sends data to all connected clients
3. Binary Frames - Send sensor data as compact binary (not JSON)
4. Ping/Pong - Implement heartbeat to detect disconnections
5. Compression - Enable per-message deflate extension

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 occurs

Security 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 unauthorized

Performance 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: - Real-time dashboards - Live sensor streaming - Remote control (low latency) - Multi-user collaboration - NOT for: Infrequent updates (use HTTP REST) - NOT for: One-way notifications only (use SSE) - NOT for: Highly constrained devices (use MQTT)

848.5 Wi-Fi Network Capacity Analysis

848.5.1 Throughput and Performance

Figure 848.3: Wi-Fi throughput performance analysis - Scenario 1

Figure 848.4: Wi-Fi throughput performance analysis - Scenario 2

Figure 848.5: Wi-Fi throughput performance analysis - Scenario 3

Figure 848.6: Wi-Fi throughput performance analysis - Scenario 4

848.5.2 CSMA/CA Model Equations

Figure 848.7: Average slot time equation for 802.11 CSMA/CA (Bianchi-style model)

Figure 848.8: 802.11 throughput equation using idle/busy slot time model

NoteText Version of CSMA/CA Model Equations

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): - Airtime utilization and retry rate (from AP/controller if available) - End-to-end latency/jitter and packet loss (ping or application-level probes) - Application-layer throughput (e.g., iperf3 or representative traffic) - Roaming/handoff behavior if devices move

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 supported

Key Concepts Demonstrated: - PHY rate vs usable throughput: overhead, retries, and contention reduce application throughput - Contention effects: more active stations increase backoff and collision probability under load - Capacity planning: design around airtime and worst-case locations, not just headline Mbps - Measurement-first workflow: validate with iperf3, latency probes, and AP stats

848.6 Visual Reference Gallery

Explore these AI-generated figures that illustrate Wi-Fi implementation concepts for IoT devices.

NoteWi-Fi Module Architecture

Wi-Fi Module

Figure 848.9: Wi-Fi module architecture for IoT implementations showing integrated processor and radio.

NoteWi-Fi Roaming and Handoff

Wi-Fi Roaming

Figure 848.10: Wi-Fi roaming enables IoT devices to maintain connectivity while moving between access points.

NoteWi-Fi Mesh Network Topology

Wi-Fi Mesh Network

Figure 848.11: Wi-Fi mesh extends coverage for IoT deployments through multi-hop wireless backhaul connections.

848.7 Summary

This chapter covered HTTP and WebSocket communication for Wi-Fi IoT:

• HTTP REST APIs: Building ESP32 web servers with RESTful endpoints for sensor data and device control, including proper status codes and JSON formatting
• HTTP Client Communication: Sending GET/POST requests to cloud services and local servers with timeout handling
• WebSocket Real-Time Streaming: Persistent bidirectional connections with 95% bandwidth reduction compared to HTTP polling
• Protocol Selection: When to use HTTP (on-demand, infrequent) vs WebSocket (real-time, continuous) vs MQTT (pub/sub, low power)
• Network Capacity Analysis: Understanding throughput, contention, and capacity planning for IoT Wi-Fi deployments

848.8 What’s Next

The next chapter provides a Comprehensive Wi-Fi IoT Lab with a complete production-ready ESP32 implementation demonstrating connection management, RSSI monitoring, power modes, HTTP communication, and mDNS service discovery.