Application Protocols · Study deck
HTTP Pitfalls: Connections, Payloads, and Chunking
HTTP looks simple until a small device pays for every poll, handshake, retry, oversized payload, and reconnect storm.
Broker Bex is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Diagnose HTTP Anti-Patterns: Analyze common HTTP mistakes that drain batteries and degrade performance in IoT systems, and distinguish them from well-designed implementations
- Implement Connection Pooling: Configure HTTP clients for efficient connection reuse using keep-alive and session management
- Apply HTTP Status Codes: Select and apply HTTP status codes correctly for IoT API error handling, justifying each choice with protocol semantics
- Construct WebSocket Reconnection Logic: Design reliable WebSocket reconnection with exponential backoff and jitter strategies to prevent thundering herd problems
Major section
In 60 Seconds
Telemetry is a time-linked record from a device.
- Hypertext Transfer Protocol (HTTP) is a request-and-response method.
- An application programming interface is a defined way for software to ask for data or action.
- Transport Layer Security is a method that protects data in transit.
- A payload is the useful data inside a message.
Major section
In 60 Seconds (continued)
Message Queuing Telemetry Transport (MQTT) is a lightweight publish-and-subscribe method.
- Constrained Application Protocol (CoAP) is a compact web-style method for small devices.
- A WebSocket is a long-lived two-way browser link.
- A gateway is a device or service that joins different system parts.
- The smallest lab cannot predict every service or mobile network.
Major section
When HTTP Goes Wrong
"Why don't we just use HTTP for everything?" asked Temperature Terry. "That's what websites use!".
- Someone programmed me to use HTTP, and I had to do a full TCP handshake -- SYN, SYN-ACK, ACK -- just to send a 5-byte temperature reading.
- the microcontroller listed more pitfalls: "HTTP also keeps connections open by default, eating up memory on your tiny microcontroller.
- And if you need real-time updates, HTTP makes you poll -- asking 'any new data? Any new data? Any new data?' every few seconds.
Major section
Common Pitfall: HTTP Polling Battery Drain
The mistake: Using HTTP polling (periodic GET requests) to check for updates from battery-powered IoT devices, assuming it will work "just like a web browser.".
- Even a simple "any updates?" check consumes 3-5 seconds of active radio time and 50-100 mA of current.
- A device polling every 10 minutes with HTTP uses 144 connections/day, consuming approximately 20-40 mAh daily.
- For battery devices, polling intervals longer than 1 hour may be acceptable with HTTP; anything more frequent demands MQTT or CoAP.
Major section
Putting Numbers to It: Connection Overhead Energy Cost
With HTTP keep-alive (amortized over $N$ readings): $$ E_{\text{per\_reading}} = \frac{25.2}{N} + 1.4\text{ mAs} $$.
- With keep-alive ($N=100$): $\frac{3000}{1.65 \times 144 / 3600} \approx 45,455\text{ days}$ (15× longer).
- The calculator below lets the running design replace these examples with measured fleet assumptions.
Major section
Putting Numbers to It: Connection Overhead Energy Cost (continued)
The keep-alive path pays setup once and sends later readings over the established secure connection, reducing the same three-reading sequence to 6.5 RTT.
- The comparison is illustrative, so idle timeout and intermediary policy still decide whether reuse is available.
- Polling every ten minutes creates 144 opportunities to wake the radio and repeat connection work, while the MQTT example keeps one session and spends small keep-alive traffic instead.
- The ranges depend on the hardware and network, but the causal link is stable: repeated session setup can dominate a tiny payload.
Major section
Common Pitfall: TLS Handshake Overhead
On a 100 ms RTT cellular link, this adds 400-600 ms before any application data.
- Prevention: For IoT gateways aggregating data, configure HTTP clients with keep-alive enabled and long timeouts (10-60 minutes).
- If HTTPS is mandatory, use TLS session caching and monitor session reuse rates in production.
- The example reduction from 600 ms to 400 ms is path-specific, but it reveals what to measure—full handshakes, resumed sessions, and reuse rate.
Major section
Pitfall: Treating REST APIs as Real-Time Event Streams
The mistake: Using HTTP long-polling or frequent polling to simulate real-time updates for IoT dashboards, believing REST can replace WebSockets or MQTT for live data.
- Developers try to avoid the complexity of WebSockets or MQTT by polling endpoints every 1-5 seconds, thinking "HTTP is good enough.".
- Rule of thumb: If update frequency is >1/minute or you have >100 concurrent viewers, avoid polling.
- That ordered comparison connects the polling pitfall to an explicit event-delivery architecture.
Major section
Pitfall: WebSocket Connection Storms During Reconnection
The fleet timeline shows the consequence—arrivals spread over time instead of forming a herd.
- Additionally, configure WebSocket server limits: max_connections: 1000, connection_rate_limit: 50/second, and implement connection queuing to smooth out reconnection storms.
Major section
Pitfall: Unbounded Payloads Crashing Constrained Gateways
The mistake: Not implementing payload size limits on REST endpoints, allowing malicious or buggy clients to send massive JSON payloads that exhaust gateway memory.
- But IoT gateways often have 256MB-1GB RAM, and a single 100MB JSON payload can crash the gateway, taking down all connected devices.
- Also protect against "zip bombs" - compressed payloads that expand to gigabytes.
- Decompress with size limits.
Deck summary
Key takeaways
Telemetry is a time-linked record from a device.
- Message Queuing Telemetry Transport (MQTT) is a lightweight publish-and-subscribe method.
- "Why don't we just use HTTP for everything?" asked Temperature Terry. "That's what websites use!".
- The mistake: Using HTTP polling (periodic GET requests) to check for updates from battery-powered IoT devices, assuming it will work "just like a web browser.".
- With HTTP keep-alive (amortized over $N$ readings): $$ E_{\text{per\_reading}} = \frac{25.2}{N} + 1.4\text{ mAs} $$.
Retrieval practice
Recall check
Broker Bex says: answer from memory, then check your reasoning.
Q1An IoT cloud API receives a sensor reading where the device's API key has expired. The server correctly identifies the problem. Which HTTP status code should it return, and why?
Show answer
Answer: B HTTP 401 Unauthorized is the correct code for any authentication failure, including expired credentials.
Print reference
Answers
Answer key.
- B · HTTP 401 Unauthorized is the correct code for any authentication failure, including expired credentials.