Application Protocols · Study deck
HTTP Pitfalls: Migration and Recovery
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:
- Explain: Repeated connection setup dominates this example: changing only the 32-byte payload to 9 bytes saves 23 / 6,972 = 0.33% of counted bytes, whereas reusing the secure connection removes repeated setup.
- Explain: The difference identifies setup reuse as the lever, while the notes prevent overclaiming: TLS version and resumption alter the exchange, intermediaries limit keep-alive, and early data has replay constraints.
- Explain: The client sends ClientHello, the server returns ServerHello plus its certificate, the client responds with key exchange plus Finished, and the server completes the handshake with its own Finished.
Major section
Worked Example: Protocol Migration Cost-Benefit Analysis
Scenario: A fleet management company operates 5,000 GPS trackers on delivery vehicles.
- Each tracker sends location updates every 30 seconds via HTTPS POST to a cloud API.
- The CTO notices excessive cellular data costs and asks the engineering team to evaluate alternatives.
- The byte counts below are illustrative assumptions for the listed components.
Major section
Worked Example: Protocol Migration Cost-Benefit Analysis (continued)
They omit per-packet IP/link framing, TLS record overhead, responses to MQTT keepalives, retransmissions, and cellular billing increments.
- The per-update byte count combines setup, headers, and payload; scaling it to the fleet reveals why a fresh HTTPS connection is costly.
- For MQTT, count the publish bytes and keepalive traffic before scaling per-tracker use to fleet cost.
- Neither ratio is a measured cellular-bandwidth saving.
Major section
Worked Example: Protocol Migration Cost-Benefit Analysis (continued)
Per-update overhead: MQTT PUBLISH header 14 bytes, binary GPS payload 9 bytes, keep-alive 2 bytes every 60 seconds.
- Server-initiated updates: current POST-only design no, MQTT subscriptions yes, reused HTTP/2 can carry an SSE response when the client opens one.
- Key Insight: In the listed-byte model, 32 / 6,972 = 0.46% of each fresh-connection update is the useful payload.
- Repeated connection setup dominates this example: changing only the 32-byte payload to 9 bytes saves 23 / 6,972 = 0.33% of counted bytes, whereas reusing the secure connection removes repeated setup.
Major section
Deep Dive: What One HTTPS Request Really Costs
On a battery-powered device over a cellular link, the payload is rarely the expensive part.
- A 20-byte reading can be preceded by radio wake, TCP connection setup, TLS negotiation, certificate validation, and the HTTP request/response round trip.
- On the warm path, the established secure connection lets HTTP begin immediately.
Major section
Deep Dive: What One HTTPS Request Really Costs (continued)
On a 100-300 ms round-trip path, that setup can keep the radio active for seconds before the tiny payload moves.
- The difference identifies setup reuse as the lever, while the notes prevent overclaiming: TLS version and resumption alter the exchange, intermediaries limit keep-alive, and early data has replay constraints.
- The TLS 1.3 handshake is one round trip.
- The other framing detail that trips up gateways is chunked transfer encoding.
Major section
Deep Dive: What One HTTPS Request Really Costs (continued)
Process chunk by chunk and cap the total accepted size instead of trusting the sender to stop.
- A practical rollout records idle timeout, heartbeat interval, reconnect rate, radio-on time, and session-reuse rate, then chooses the cheapest setting that keeps useful sessions alive.
- TLS 1.2 usually needs another round trip for the extra key-exchange step.
- For a field review, keep one cold-start trace and one warm-session trace.
Major section
Summary
HTTP polling drains batteries rapidly - use MQTT or CoAP for frequent updates.
- TLS handshake overhead dominates communication time - use connection pooling.
- Connection Management: After link reuse, limit retries, errors, and payload size.
- One failure should not flood the link.
- Error Handling and Safety: Streaming limits control memory, while client count and update direction help choose polling, server events, or WebSockets.
Major section
How It Works: HTTP Connection Lifecycle
The client sends SYN, the server replies with SYN-ACK, and the client finishes with ACK.
- The client sends ClientHello, the server returns ServerHello plus its certificate, the client responds with key exchange plus Finished, and the server completes the handshake with its own Finished.
- The client sends GET /sensor/data, then the server returns 200 OK and the payload.
- On a 100 ms latency cellular link: The 450 ms first request includes connection setup; reuse removes that setup from later requests.
- With HTTP/2:: HTTP/2 pays its setup once, then sends concurrent requests through one connection with compressed headers.
Major section
Concept Relationships
Solutions: WebSocket allows two-way data; server events push one way.
- CoAP has a lighter link.
- TCP three-way handshake adds 1.5 RTT.
- TLS 1.2 handshake adds 2 RTT (TLS 1.3 adds 1 RTT).
- Each HTTP/1.1 connection has overhead ~8KB RAM per connection.
Deck summary
Key takeaways
Scenario: A fleet management company operates 5,000 GPS trackers on delivery vehicles.
- They omit per-packet IP/link framing, TLS record overhead, responses to MQTT keepalives, retransmissions, and cellular billing increments.
- Per-update overhead: MQTT PUBLISH header 14 bytes, binary GPS payload 9 bytes, keep-alive 2 bytes every 60 seconds.
- On a battery-powered device over a cellular link, the payload is rarely the expensive part.
- On a 100-300 ms round-trip path, that setup can keep the radio active for seconds before the tiny payload moves.
Retrieval practice
Recall check 1 of 4
Broker Bex says: answer from memory, then check your reasoning.
Q1An HTTP telemetry path has high connection cost. When is a move to MQTT justified?
Show answer
Answer: C The chapter asks for a measured comparison and recovery evidence.
Retrieval practice
Recall check 2 of 4
Broker Bex says: answer from memory, then check your reasoning.
Q2Complete the HTTP connection management for IoT polling:
Show answer
Answer: A Using requests.Session() enables HTTP keep-alive connection reuse, reducing TCP handshake overhead for repeated API calls. Always set timeout to prevent hanging on unreachable IoT devices. Session headers persist across all requests.
Q3What adds transport and security round trips before a fresh HTTP connection can carry a request?
Show answer
Answer: C A fresh connection pays transport and security round trips before an HTTP request can carry useful application data.
Retrieval practice
Recall check 3 of 4
Broker Bex says: answer from memory, then check your reasoning.
Q4An IoT gateway sends temperature readings from 50 sensors to a cloud API using HTTP POST requests -- one request per sensor every 10 seconds. Each request creates a new TCP+TLS connection. The gateway's latency is unexpectedly high (800ms per request) despite a fast network. What is the primary cause and best fix?
Show answer
Answer: B see answers page
Retrieval practice
Recall check 4 of 4
Broker Bex says: answer from memory, then check your reasoning.
Q5After a server restart, 500 IoT dashboard WebSocket clients all attempt to reconnect simultaneously, crashing the server. What reconnection strategy prevents this "thundering herd" problem?
Show answer
Answer: A Exponential backoff with random jitter spreads reconnection attempts over time.
Print reference
Answers 1 of 2
Answer key.
- C · The chapter asks for a measured comparison and recovery evidence.
- A · Using requests.Session() enables HTTP keep-alive connection reuse, reducing TCP handshake overhead for repeated API calls. Always set timeout to prevent hanging on unreachable IoT devices. Session headers persist across all requests.
- C · A fresh connection pays transport and security round trips before an HTTP request can carry useful application data.
Print reference
Answers 2 of 2
Answer key.
- B · The chapter's connection lifecycle counts 2 RTT for the TLS 1.2 handshake, or 200 ms at 100 ms RTT, in addition to TCP setup and the HTTP exchange. Fifty sensors reporting every 10 seconds produce five requests per second, or 300 requests per minute. HTTP keep-alive with connection pooling avoids repeating TCP and TLS setup for each POST; the exact latency saving depends on RTT, TLS version and intermediaries.
- A · Exponential backoff with random jitter spreads reconnection attempts over time.