8 HTTP Pitfalls: Migration and Recovery

app-protocols

http

connection

management

Start with the story: HTTP looks simple until a small device pays for every poll, handshake, retry, oversized payload, and reconnect storm. This page follows those costs from a sensor through the gateway so you can spot when ordinary web habits become IoT failures.

8.1 Start With the Situation

The gateway now bounds connections, payloads, and chunked transfer, but the team still needs to decide whether migration is worth its cost. It must compare MQTT and optimized HTTP paths and record the recovery evidence.

8.2 Overview

This route compares MQTT and optimized HTTP migration paths and turns the result into recovery and operating guidance.

This is part 2 of 2. Review HTTP Pitfalls: Connections, Payloads, and Chunking when you need the first route.

8.3 Learning Objectives

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

compare HTTP optimization and MQTT migration costs
choose a migration path from measured connection and payload costs
design retry and recovery behavior with measurable limits

8.4 Chapter Roadmap

Follow the original sections below in order. They begin at the reviewed split boundary and keep every worked example, figure, check, and supporting banner with the section that owns it.

8.5 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.

8.5.1 Current Architecture: HTTPS Polling

Read these points as one connected sequence: start with Per-update overhead: TCP handshake 180 bytes, TLS 1.2 handshake about 6 kB, HTTP headers about 400 bytes, GPS payload 32 bytes, HTTP response 200 bytes, TCP teardown 160 bytes; then Total per update: about 6,972 bytes for 32 bytes of useful data; then Protocol efficiency: 0.46%; then Daily usage per tracker: 2,880 updates/day x 6,972 bytes = 19.2 MB; then Fleet daily usage: 5,000 x 19.2 MB = 96 GB; and finish with Monthly cellular cost: 96 GB/day x 30 days x $0.50/GB = $1,440/month.

Per-update overhead: TCP handshake 180 bytes, TLS 1.2 handshake about 6 kB, HTTP headers about 400 bytes, GPS payload 32 bytes, HTTP response 200 bytes, TCP teardown 160 bytes.
Total per update: about 6,972 bytes for 32 bytes of useful data.
Protocol efficiency: 0.46%.
Daily usage per tracker: 2,880 updates/day x 6,972 bytes = 19.2 MB.
Fleet daily usage: 5,000 x 19.2 MB = 96 GB.
Monthly cellular cost: 96 GB/day x 30 days x $0.50/GB = $1,440/month.

8.5.2 Option A: MQTT with Persistent Connection

Read these points as one connected sequence: start with Per-update overhead: MQTT PUBLISH header 14 bytes, binary GPS payload 9 bytes, keep-alive 2 bytes every 60 seconds; then Total per update: 23 bytes; then Protocol efficiency: 39% versus 0.46% for HTTPS polling; then Daily usage per tracker: 64.5 kB for updates plus 2.9 kB for keep-alives = 67.4 kB/day; then Fleet daily usage: 5,000 x 67.4 kB = 329 MB; then Monthly cellular cost: 329 MB/day-equivalent x 30 = 9.6 GB/month, or about $4.80/month; and finish with Savings versus HTTPS polling: about $1,435/month, a 99.7% reduction.

Per-update overhead: MQTT PUBLISH header 14 bytes, binary GPS payload 9 bytes, keep-alive 2 bytes every 60 seconds.
Total per update: 23 bytes.
Protocol efficiency: 39% versus 0.46% for HTTPS polling.
Daily usage per tracker: 64.5 kB for updates plus 2.9 kB for keep-alives = 67.4 kB/day.
Fleet daily usage: 5,000 x 67.4 kB = 329 MB.
Monthly cellular cost: 329 MB/day-equivalent x 30 = 9.6 GB/month, or about $4.80/month.
Savings versus HTTPS polling: about $1,435/month, a 99.7% reduction.

8.5.3 Option B: HTTPS with Connection Pooling + Binary Encoding

Read these points as one connected sequence: start with Per-update overhead with reuse: HPACK-compressed HTTP/2 header about 15 bytes plus 9-byte binary payload; then Total per update: about 24 bytes, close to MQTT; then One-time TLS setup: about 6 kB amortized across a long-lived connection; then Daily usage per tracker: 67.3 kB for updates plus 12 kB for two reconnects = 79.3 kB/day; then Fleet daily usage: 5,000 x 79.3 kB = 387 MB; and finish with Monthly cellular cost: 387 MB/day-equivalent x 30 = 11.3 GB/month, or about $5.65/month.

Per-update overhead with reuse: HPACK-compressed HTTP/2 header about 15 bytes plus 9-byte binary payload.
Total per update: about 24 bytes, close to MQTT.
One-time TLS setup: about 6 kB amortized across a long-lived connection.
Daily usage per tracker: 67.3 kB for updates plus 12 kB for two reconnects = 79.3 kB/day.
Fleet daily usage: 5,000 x 79.3 kB = 387 MB.
Monthly cellular cost: 387 MB/day-equivalent x 30 = 11.3 GB/month, or about $5.65/month.

8.5.4 Decision

Monthly data cost: HTTPS polling $1,440, MQTT $4.80, optimized HTTPS/2 $5.65.
Migration effort: HTTPS current state none, MQTT about 3 months, optimized HTTPS/2 about 1 month.
Broker infrastructure: HTTPS none, MQTT about $200/month, optimized HTTPS/2 none.
Server-push capability: HTTPS current state no, MQTT yes, optimized HTTPS/2 yes through SSE.
Annual savings versus current state: MQTT about $17,222, optimized HTTPS/2 about $17,212.

Result: Both MQTT and optimized HTTPS/2 reduce cellular costs by over 99%. The company chose MQTT because server-push enables real-time geofence alerts without polling, and the $200/month broker cost ($2,400/year) is trivial against $17,222 in annual cellular savings — a net gain of over $14,800/year.

Key Insight: The original HTTPS implementation wasted 99.5% of cellular bandwidth on protocol overhead. The fix was not changing protocols — it was understanding that JSON encoding (32 bytes payload) plus full HTTP headers (400 bytes) plus TLS handshake per request (6 kB) turned a 32-byte GPS update into a 7 kB transmission. Binary encoding alone would have saved 50%, but eliminating per-request connection overhead saved 99%.

Interactive: Protocol Migration Cost Analysis

Compare HTTP polling vs MQTT vs optimized HTTP/2 for your IoT fleet:

Code Challenge

8.6 Key Takeaways

Label the Diagram

Order the Steps

Match the Concepts

8.7 Deep Dive: What One HTTPS Request Really Costs

The pitfalls above each waste connections in a different way. This layered walkthrough puts a price on a single HTTPS request, then uses Figure 8.1 to show the three levers — keep-alive, TLS session resumption, and switching to CoAP or MQTT — that each attack a specific part of that price.

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 a 100-300 ms round-trip path, that setup can keep the radio active for seconds before the tiny payload moves. Inspect Figure 8.1 while diagnosing the trace: if every reading shows a new TCP connect, TLS handshake, certificate check, and radio wake, the fleet is spending most of its energy preparing to talk.

Side-by-side client and server sequence diagram. A cold HTTPS request performs the TCP three-way handshake, a TLS 1.3 handshake, and then the HTTP request and response. A warm keep-alive request begins with an established TCP and TLS connection and sends HTTP immediately. Notes explain that TLS versions and resumption change timing, keep-alive is bounded by idle timeout and intermediary policy, and TLS early data can be replayed. — Figure 8.1: A cold HTTPS request pays TCP and TLS setup before HTTP, while a warm keep-alive request can reuse the established secure connection.

Read Figure 8.1 down the cold path first: TCP establishes transport, TLS negotiates protection, and only then does HTTP carry the reading. On the warm path, the established secure connection lets HTTP begin immediately. 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 strategy table now maps each operating pattern to the portion of this sequence it reuses or avoids.

Strategy	What it reuses or avoids	Best when
Fresh HTTPS per message	Nothing; pays full TCP and TLS setup every time	Rare, one-off requests
HTTP keep-alive pool	Reuses one TCP and TLS connection across many requests	Bursts of gateway requests over a stable link
TLS session resumption	Skips most of the full TLS handshake on reconnect	Intermittent clients that must reconnect often
MQTT or CoAP	Amortizes or eliminates per-message setup with smaller message framing	Frequent small telemetry and command paths

Keep-alive is not free, so size it from the real network path. Cellular NATs, reverse proxies, and load balancers may close quiet sockets before the device expects it. 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. If a device reports every few seconds for years, the target design is one long-lived session or a protocol that removes repeated setup rather than a fresh HTTPS connection for every reading.

8.7.1 TLS Handshake and Chunked Framing

The TLS 1.3 handshake is one round trip. The client’s ClientHello offers cipher suites and an ephemeral key share; the server answers with ServerHello, EncryptedExtensions, its Certificate, CertificateVerify, and Finished; the client sends its own Finished and can then send application data. Forward secrecy comes from the ephemeral ECDHE key exchange, and the server’s identity is proven by its certificate chain. TLS 1.2 usually needs another round trip for the extra key-exchange step. 0-RTT resumption can send early data immediately from a prior session, but only safe, idempotent requests belong there because early data can be replayed.

The other framing detail that trips up gateways is chunked transfer encoding. When a sender does not know the body length up front, it sets Transfer-Encoding: chunked and sends size-prefixed chunks: a hex byte count, that many bytes, the next chunk, and finally a zero-length chunk. Each line is terminated by CRLF:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

f
{"temp_c":21.4}
0

Here f is hex for 15, the byte length of {"temp_c":21.4}, and the trailing 0 chunk marks the end of the body. The constrained-gateway pitfall is buffering: a naive parser that reassembles the whole body before processing can be driven out of RAM by a long or malicious chunked stream. Process chunk by chunk and cap the total accepted size instead of trusting the sender to stop.

For a field review, keep one cold-start trace and one warm-session trace. The cold trace should show radio wake, TCP, TLS, request, and response; the warm trace should prove connection reuse, TLS resumption, or a deliberate protocol switch.

8.8 Summary

Battery and Performance:

Read these points as one connected sequence: start with HTTP polling drains batteries rapidly - use MQTT or CoAP for frequent updates; then TLS handshake overhead dominates communication time - use connection pooling; and finish with Calculate energy budgets before selecting polling intervals.

HTTP polling drains batteries rapidly - use MQTT or CoAP for frequent updates
TLS handshake overhead dominates communication time - use connection pooling
Calculate energy budgets before selecting polling intervals

Connection Management:

Read these points as one connected sequence: start with Enable HTTP keep-alive for gateways sending multiple requests; then Configure heartbeats at 50% of shortest proxy timeout; and finish with Implement exponential backoff with jitter for reconnection.

Enable HTTP keep-alive for gateways sending multiple requests
Configure heartbeats at 50% of shortest proxy timeout
Implement exponential backoff with jitter for reconnection

Error Handling and Safety:

Read these points as one connected sequence: start with Use proper HTTP status codes (4xx/5xx) for errors; then Implement payload size limits at multiple layers; and finish with Use bounded chunking for streaming uploads.

Use proper HTTP status codes (4xx/5xx) for errors
Implement payload size limits at multiple layers
Use bounded chunking for streaming uploads

Real-Time Patterns:

Read these points as one connected sequence: start with HTTP polling: <50 clients, >1 min interval; then Server-Sent Events: Unidirectional dashboards; then WebSockets: Bidirectional interactive apps; and finish with MQTT over WebSocket: Large-scale IoT dashboards.

HTTP polling: <50 clients, >1 min interval
Server-Sent Events: Unidirectional dashboards
WebSockets: Bidirectional interactive apps
MQTT over WebSocket: Large-scale IoT dashboards

8.9 Knowledge Check

Quiz: HTTP Connection Pitfalls in IoT

How It Works: HTTP Connection Lifecycle

Understanding HTTP connection management requires understanding the complete lifecycle:

Read these points as one connected sequence: start with Step 1: TCP connection establishment (1.5 RTT). The client sends SYN, the server replies with SYN-ACK, and the client finishes with ACK; then Step 2: TLS 1.2 handshake (2 RTT). 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; then Step 3: HTTP request/response (1 RTT). The client sends GET /sensor/data, then the server returns 200 OK and the payload; and finish with Total before data arrives: typically 4 to 5 RTT.

Step 1: TCP connection establishment (1.5 RTT). The client sends SYN, the server replies with SYN-ACK, and the client finishes with ACK.
Step 2: TLS 1.2 handshake (2 RTT). 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.
Step 3: HTTP request/response (1 RTT). The client sends GET /sensor/data, then the server returns 200 OK and the payload.
Total before data arrives: typically 4 to 5 RTT.

On a 100 ms latency cellular link: Read these points as one connected sequence: start with Connection setup: 150 ms (TCP); then TLS handshake: 200 ms; then HTTP request: 100 ms; and finish with Total: 450 ms for a 5-byte temperature reading.

Connection setup: 150 ms (TCP)
TLS handshake: 200 ms
HTTP request: 100 ms
Total: 450 ms for a 5-byte temperature reading

With HTTP Keep-Alive:

Read these points as one connected sequence: start with First request: 450 ms (one-time cost); then Subsequent requests: 100 ms each (5x faster); and finish with Connection reused for hours with proper timeout configuration.

First request: 450 ms (one-time cost)
Subsequent requests: 100 ms each (5x faster)
Connection reused for hours with proper timeout configuration

With HTTP/2:

Read these points as one connected sequence: start with First request: 250 ms (TCP 1.5 RTT + TLS 1.3 1 RTT at 100 ms RTT); then Subsequent requests: ~100 ms each (1 RTT; multiplexing eliminates head-of-line blocking so concurrent requests don’t queue behind each other); and finish with Single connection handles 50+ parallel streams with HPACK header compression.

First request: 250 ms (TCP 1.5 RTT + TLS 1.3 1 RTT at 100 ms RTT)
Subsequent requests: ~100 ms each (1 RTT; multiplexing eliminates head-of-line blocking so concurrent requests don’t queue behind each other)
Single connection handles 50+ parallel streams with HPACK header compression

Concept Relationships

HTTP pitfalls connect to several protocol and system design concepts:

Root Causes:

Read these points as one connected sequence: start with TCP Connection Management - TCP handshake overhead; then TLS/SSL Protocol - TLS handshake latency; and finish with Request-Response Pattern - Polling vs push.

TCP Connection Management - TCP handshake overhead
TLS/SSL Protocol - TLS handshake latency
Request-Response Pattern - Polling vs push

Solutions:

Read these points as one connected sequence: start with Modern HTTP for IoT - Modern HTTP addresses these issues; then MQTT Fundamentals - Persistent connection alternative; and finish with WebSocket Protocol - Bidirectional upgrade from HTTP.

Modern HTTP for IoT - Modern HTTP addresses these issues
MQTT Fundamentals - Persistent connection alternative
WebSocket Protocol - Bidirectional upgrade from HTTP

Alternative Approaches:

Read these points as one connected sequence: start with CoAP Protocol - Lightweight alternative using UDP; then Server-Sent Events - Unidirectional push over HTTP; and finish with AMQP - Message queue alternative.

CoAP Protocol - Lightweight alternative using UDP
Server-Sent Events - Unidirectional push over HTTP
AMQP - Message queue alternative

System Impact:

Read these points as one connected sequence: start with Power Management - Polling battery drain; then Gateway Design - Connection pooling strategies; and finish with Cloud Cost Optimization - Bandwidth charges.

Power Management - Polling battery drain
Gateway Design - Connection pooling strategies
Cloud Cost Optimization - Bandwidth charges

Prerequisites You Should Know:

Read these points as one connected sequence: start with TCP three-way handshake adds 1.5 RTT; then TLS 1.2 handshake adds 2 RTT (TLS 1.3 adds 1 RTT); and finish with Each HTTP/1.1 connection has overhead ~8KB RAM per connection.

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

What This Enables:

Read these points as one connected sequence: start with Design efficient IoT communication patterns avoiding polling; then Optimize gateway aggregation with connection pooling; and finish with Select appropriate protocols based on resource constraints.

Design efficient IoT communication patterns avoiding polling
Optimize gateway aggregation with connection pooling
Select appropriate protocols based on resource constraints

Try It Yourself

Experiment 1: Measure Polling Energy Cost

Calculate battery drain from HTTP polling:

import time
import requests

# Simulate 100 polls
start = time.time()
session = requests.Session()  # Uses keep-alive
for _ in range(100):
    response = session.get("https://httpbin.org/get", timeout=5)
    response.raise_for_status()
    time.sleep(1)  # 1 second interval
elapsed = time.time() - start

# With keep-alive: ~100 seconds (connections reused)
# Without keep-alive: ~145 seconds (connection overhead)

print(f"Time for 100 polls: {elapsed:1f}s")
print(f"Overhead per poll: {(elapsed - 100) / 100 * 1000:0f}ms")

What to Observe:

Read these points as one connected sequence: start with With keep-alive: minimal overhead (~5 ms per request); then Without keep-alive: ~450 ms overhead per request on cellular; and finish with Battery impact: 9x more radio-on time without keep-alive.

With keep-alive: minimal overhead (~5 ms per request)
Without keep-alive: ~450 ms overhead per request on cellular
Battery impact: 9x more radio-on time without keep-alive

Experiment 2: WebSocket Reconnection Storm

Simulate thundering herd:

// Run in browser console on 10 tabs simultaneously
const ws = new WebSocket('wss://echo.websocket.org/');

// BAD: Fixed retry (all clients reconnect at once)
ws.onclose = () => setTimeout(() => new WebSocket('wss://echo.websocket.org/'), 5000);

// GOOD: Exponential backoff with jitter
ws.onclose = () => {
    const baseDelay = 1000;
    const maxDelay = 60000;
    const jitter = Math.random() * 1000;
    const delay = Math.min(baseDelay * Math.pow(2, attempt), maxDelay) + jitter;
    setTimeout(() => new WebSocket('wss://echo.websocket.org/'), delay);
};

What to Observe:

Read these points as one connected sequence: start with Without jitter: all 10 clients reconnect simultaneously; then With jitter: reconnections spread over 0-1 second window; and finish with Server load: 10x burst vs smooth distribution.

Without jitter: all 10 clients reconnect simultaneously
With jitter: reconnections spread over 0-1 second window
Server load: 10x burst vs smooth distribution

Experiment 3: Chunked Transfer Memory Exhaustion

Test bounded chunk streaming:

import requests

# DANGEROUS: Unbounded chunked response can exhaust memory
def stream_unbounded():
    r = requests.get('https://httpbin.org/stream/10000', stream=True)
    data = r.raw.read()  # Buffers entire 10,000-line response!

# SAFE: Process chunks incrementally
def stream_bounded():
    r = requests.get('https://httpbin.org/stream/10000', stream=True)
    count = 0
    for line in r.iter_lines(chunk_size=1024):
        count += 1
        if count % 1000 == 0:
            print(f"Processed {count} lines")
    return count

What to Observe:

Read these points as one connected sequence: start with Unbounded: memory usage grows to ~5MB; then Bounded: constant ~1KB memory usage; and finish with Gateway with 256MB RAM: bounded supports 256,000 concurrent streams.

Unbounded: memory usage grows to ~5MB
Bounded: constant ~1KB memory usage
Gateway with 256MB RAM: bounded supports 256,000 concurrent streams

Challenge: Cost-Benefit Analysis

Calculate annual cellular cost for a fleet management system:

Read these points as one connected sequence: start with Fleet size: 5,000 GPS trackers; then Current design: HTTP polling every 30 seconds; and finish with Alternative design: MQTT persistent connection.

Fleet size: 5,000 GPS trackers.
Current design: HTTP polling every 30 seconds.
Alternative design: MQTT persistent connection.

HTTP polling inputs

Read these points as one connected sequence: start with Overhead per request: 6.8 kB for TCP, TLS, and HTTP headers; then Payload: 0.085 kB of GPS coordinates; then Total per request: 6.885 kB; then Daily per device: 2,880 requests x 6.885 kB = 19.4 MB; then Fleet daily: 5,000 x 19.4 MB = 97 GB; then Monthly traffic: 97 GB x 30 = 2,910 GB; and finish with Annual cost formula: 2,910 GB/month x 1,000 MB/GB x EUR 0.01/MB x 12.

Overhead per request: 6.8 kB for TCP, TLS, and HTTP headers.
Payload: 0.085 kB of GPS coordinates.
Total per request: 6.885 kB.
Daily per device: 2,880 requests x 6.885 kB = 19.4 MB.
Fleet daily: 5,000 x 19.4 MB = 97 GB.
Monthly traffic: 97 GB x 30 = 2,910 GB.
Annual cost formula: 2,910 GB/month x 1,000 MB/GB x EUR 0.01/MB x 12.

MQTT persistent inputs

Read these points as one connected sequence: start with Connection overhead: 0.12 kB from keep-alives every 60 seconds; then Payload: 0.009 kB with binary GPS encoding; then Daily per device: (2,880 x 0.009) + (1,440 x 0.00012) = 0.026 MB; then Fleet daily: 5,000 x 0.026 MB = 130 MB; then Monthly traffic: 130 MB x 30 = 3.9 GB; and finish with Annual cost formula: 3.9 GB/month x 1,000 MB/GB x EUR 0.01/MB x 12.

Connection overhead: 0.12 kB from keep-alives every 60 seconds.
Payload: 0.009 kB with binary GPS encoding.
Daily per device: (2,880 x 0.009) + (1,440 x 0.00012) = 0.026 MB.
Fleet daily: 5,000 x 0.026 MB = 130 MB.
Monthly traffic: 130 MB x 30 = 3.9 GB.
Annual cost formula: 3.9 GB/month x 1,000 MB/GB x EUR 0.01/MB x 12.

Calculate the savings!

8.10 What’s Next?

Read these points as one connected sequence: start with Modern HTTP for IoT: Focus on multiplexing, header compression, and QUIC transport. Read it to see how modern HTTP directly addresses the overhead and polling pitfalls from this chapter; then MQTT Fundamentals: Focus on persistent pub-sub connections for IoT. Read it to understand the main alternative to HTTP polling and why it removes per-message handshake costs; then CoAP Protocol: Focus on lightweight UDP-based communication for constrained devices. Read it to see how CoAP Observe replaces HTTP polling for sensor workloads; then IoT API Design: Focus on RESTful backend design. Read it to apply correct status codes and interaction patterns in production APIs; then Application Protocols Overview: Focus on MQTT, CoAP, HTTP, AMQP, and WebSockets side by side. Read it to place HTTP trade-offs in the broader protocol landscape; and finish with Transport Protocols for IoT: Focus on TCP/UDP trade-offs and TLS/DTLS security. Read it to deepen the latency and power implications behind the handshake costs covered here.

Modern HTTP for IoT: Focus on multiplexing, header compression, and QUIC transport. Read it to see how modern HTTP directly addresses the overhead and polling pitfalls from this chapter.
MQTT Fundamentals: Focus on persistent pub-sub connections for IoT. Read it to understand the main alternative to HTTP polling and why it removes per-message handshake costs.
CoAP Protocol: Focus on lightweight UDP-based communication for constrained devices. Read it to see how CoAP Observe replaces HTTP polling for sensor workloads.
IoT API Design: Focus on RESTful backend design. Read it to apply correct status codes and interaction patterns in production APIs.
Application Protocols Overview: Focus on MQTT, CoAP, HTTP, AMQP, and WebSockets side by side. Read it to place HTTP trade-offs in the broader protocol landscape.
Transport Protocols for IoT: Focus on TCP/UDP trade-offs and TLS/DTLS security. Read it to deepen the latency and power implications behind the handshake costs covered here.

8.1 Start With the Situation

8.2 Overview

8.3 Learning Objectives

8.4 Chapter Roadmap

8.5 Worked Example: Protocol Migration Cost-Benefit Analysis

8.5.1 Current Architecture: HTTPS Polling

8.5.2 Option A: MQTT with Persistent Connection

8.5.3 Option B: HTTPS with Connection Pooling + Binary Encoding

8.5.4 Decision

8.6 Key Takeaways

8.7 Deep Dive: What One HTTPS Request Really Costs

8.7.1 TLS Handshake and Chunked Framing

8.8 Summary

8.9 Knowledge Check

How It Works: HTTP Connection Lifecycle

Concept Relationships

See Also

Try It Yourself

8.10 What’s Next?