Application Protocols · Study deck
HTTP Pitfalls: Connections, Payloads, and Chunking
HTTP is the web's way to ask for data and get a reply.
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
In 60 Seconds (continued)
The deeper sections compare polling, kept-open links, backoff, size limits, and failure handling so the chosen pattern has a measured budget and a safe stop rule.
- A short reading can need far more work to wake, connect, prove identity, send, receive a reply, and close.
- HTTP in IoT creates five common pitfalls: needless polling, repeated connection setup, WebSocket reconnection bursts, unbounded response bodies, and retries without a stop rule.
- A sensor polling every 10 minutes makes 144 requests/day; whether HTTP reuse, MQTT, or CoAP uses less battery depends on the radio and sleep schedule.
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
Putting Numbers to It: Connection Overhead Energy Cost
With HTTP keep-alive (amortized over N readings): Eper_reading=N25.2+1.4 mAs.
- With keep-alive (N=100): 1.65×144/36003000≈45,455 days (15× longer).
- The calculator below lets the running design replace these examples with measured fleet assumptions.
- 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.
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.
- In the Managed reconnection adds a stable-open state, exponential backoff, random jitter, heartbeat monitoring, and orderly close instead of repeating one fixed retry interval diagram, trace the naive loop first: every client waits the same fixed interval, so a shared outage produces synchronized TLS and authentication spikes.
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.
- The deeper sections compare polling, kept-open links, backoff, size limits, and failure handling so the chosen pattern has a measured budget and a safe stop rule.
- "Why don't we just use HTTP for everything?" asked Temperature Terry. "That's what websites use!".
- With HTTP keep-alive (amortized over N readings): Eper_reading=N25.2+1.4 mAs.
Retrieval practice
Recall check 1 of 2
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: D HTTP 401 Unauthorized is the correct code for any authentication failure, including expired credentials.
Retrieval practice
Recall check 2 of 2
Broker Bex says: answer from memory, then check your reasoning.
Q2A gateway has 24 MB free after baseline use, reserves half for other work, allows three concurrent uploads, and targets at most 80% of the remaining upload budget. What expanded-payload cap per upload follows?
Show answer
Answer: D Half of 24 MB leaves a 12 MB upload budget.
Print reference
Answers
Answer key.
- D · HTTP 401 Unauthorized is the correct code for any authentication failure, including expired credentials.
- D · Half of 24 MB leaves a 12 MB upload budget.