3 HTTP and Modern Protocols for IoT

From HTTP/1.1 Pitfalls to HTTP/2 Multiplexing and HTTP/3 QUIC for Constrained Devices

In 60 Seconds

Traditional HTTP/1.1 is costly for IoT due to large headers (200-800 bytes per request), repeated TCP+TLS handshakes, and polling-based patterns that drain batteries 20-40x faster than push protocols. HTTP/2 solves multiplexing with header compression (90% reduction) over a single connection, while HTTP/3 built on QUIC offers 0-RTT resumption, no head-of-line blocking, and seamless connection migration, delivering 30-50% power savings for mobile IoT devices.

Prerequisites: Application Protocols Overview | CoAP vs MQTT Comparison

This enables: IoT API Design Best Practices | Real-Time Protocols

3.1 Learning Objectives

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

Explain HTTP Limitations: Articulate why traditional HTTP/1.1 is problematic for IoT, including header bloat, handshake overhead, and polling battery drain
Diagnose Common Pitfalls: Identify and correct frequent HTTP mistakes in IoT systems, such as missing keep-alive, fixed retry intervals, and unbounded payloads
Compare HTTP/2 and HTTP/3: Analyze and contrast modern HTTP protocols for IoT applications, including multiplexing, compression, and QUIC transport trade-offs
Implement Best Practices: Configure proper connection management, exponential backoff with jitter, and TLS session resumption in IoT HTTP clients
Calculate overhead costs: Quantify HTTP header, TLS handshake, and polling overhead for battery-powered devices using bandwidth and energy formulas
Select the right HTTP version: Justify the choice between HTTP/1.1, HTTP/2, and HTTP/3 based on device constraints, network conditions, and deployment environment

Minimum Viable Understanding

HTTP/1.1 is costly for IoT: Each request-response cycle carries 200-800 bytes of headers, requires a new TCP+TLS handshake (2-4 RTTs: 1 TCP + 1-2 TLS + 1 request), and polling patterns drain batteries 20-40x faster than push-based protocols like MQTT – making it the wrong default choice for constrained devices.
HTTP/2 solves the multiplexing problem: A single TCP connection carries multiple concurrent streams with HPACK header compression (90% reduction), server push, and stream prioritization – enabling gateways to upload 50x faster by sending sensor batches in parallel.
HTTP/3 with QUIC is the IoT game-changer: Built on UDP with 0-RTT resumption (eliminating handshake latency), independent streams (no head-of-line blocking), and connection migration (seamless Wi-Fi-to-cellular handoff) – delivering 30-50% power savings for mobile IoT devices.

Sensor Squad: HTTP – The Chatty Messenger

Sammy the Temperature Sensor was exhausted. Every 10 seconds, he had to ask the cloud server: “Do you have any instructions for me?” And every time, the server replied: “No, nothing new.” Sammy was wasting all his battery just asking questions!

Lila the Light Sensor noticed Sammy’s problem. “Why do you keep asking if there is mail? That is like walking to the post office every minute to check your mailbox! You should just wait for the postman to knock.”

Max the Motion Sensor had a different problem. “When I DO have something to send, I have to introduce myself every single time! I say: ‘Hello, I am Max, I speak English, I am from Building 3, here is my ID card…’ That introduction takes longer than the actual message!”

Bella the Barometric Sensor explained the solution: “There are newer versions of HTTP that fix these problems! HTTP/2 lets you send multiple messages through one door at the same time – like having a revolving door instead of a regular one. And HTTP/3 uses a magic tunnel called QUIC that remembers you, so you never have to re-introduce yourself!”

“But wait,” said Sammy, “if HTTP is so chatty, why do people still use it?”

Bella smiled: “Because everyone speaks HTTP! Every phone, every browser, every cloud service. Sometimes it is better to use a language everyone understands, even if it is a bit wordy. The trick is using the NEWEST version of that language.”

What the Squad learned: HTTP/1.1 is like sending letters with a long formal introduction every time. HTTP/2 is like having multiple conversations through one phone line. HTTP/3 with QUIC is like a video call that keeps working even when you switch from Wi-Fi to cellular – no dropped calls!

For Beginners: Why HTTP Matters for IoT

If you have ever used a web browser, you have already used HTTP – it is the protocol that loads every web page. But IoT devices are NOT web browsers, and using HTTP the wrong way is one of the most common beginner mistakes.

Why developers reach for HTTP first: It is familiar. Every programming language has HTTP libraries. Every cloud service has HTTP APIs. It seems like the easy choice.

Why that can be a trap: HTTP was designed for humans browsing web pages – not for thousands of sensors sending small data packets. Here are the key differences:

What a browser does	What an IoT sensor does
Loads large pages (100 KB+)	Sends tiny readings (10-100 bytes)
Has wall power	Runs on batteries
Needs data NOW	Can tolerate seconds of delay
One device per user	Thousands of devices per gateway
Reliable Wi-Fi/Ethernet	Lossy cellular/LPWAN

The overhead problem: Every HTTP request includes headers (200-800 bytes) describing the request format, encoding, cookies, and more. When your actual data is only 50 bytes (like “temperature=23.5”), the overhead is 4-16x larger than the payload!

The good news: Modern HTTP versions (HTTP/2 and HTTP/3) solve many of these problems. This module teaches you when HTTP makes sense for IoT, which version to use, and how to avoid the most expensive mistakes.

No networking background required – start with the pitfalls chapter and follow the recommended path.

3.2 Module Overview

This module covers HTTP protocols for IoT applications, including common pitfalls to avoid and modern HTTP/2 and HTTP/3 improvements. The content has been organized into focused chapters for easier learning:

3.2.1 Chapter Guide

Chapter	Topics Covered	Estimated Time
HTTP Pitfalls and Connection Management	Polling battery drain, TLS overhead, real-time handling, WebSocket management, payload protection	15-20 min
HTTP/2 and HTTP/3 for IoT	Multiplexing, HPACK compression, QUIC transport, 0-RTT resumption, protocol selection	15-20 min

Total Module Time: ~30-40 minutes

3.3 HTTP Protocol Evolution for IoT

3.4 HTTP Request Overhead Anatomy

Understanding where HTTP overhead comes from is essential for optimizing IoT communications.

3.5 Interactive HTTP Overhead Calculator

Explore how different HTTP configurations affect your IoT system’s bandwidth and latency:

Show code

viewof payloadSize = Inputs.range([10, 1000], {
  value: 50,
  step: 10,
  label: "Payload size (bytes)"
})

viewof requestHeaders = Inputs.range([100, 1000], {
  value: 500,
  step: 50,
  label: "HTTP/1.1 request headers (bytes)"
})

viewof responseHeaders = Inputs.range([100, 800], {
  value: 350,
  step: 50,
  label: "HTTP/1.1 response headers (bytes)"
})

viewof requestsPerMinute = Inputs.range([1, 600], {
  value: 60,
  step: 1,
  label: "Requests per minute"
})

viewof rtt = Inputs.range([10, 500], {
  value: 150,
  step: 10,
  label: "Network RTT (ms)"
})

viewof protocol = Inputs.select(
  ["HTTP/1.1 (no keepalive)", "HTTP/1.1 (keepalive)", "HTTP/2", "HTTP/3"],
  {value: "HTTP/1.1 (keepalive)", label: "Protocol version"}
)

Show code

http1NoKeepalive = {
  const perRequestOverhead = requestHeaders + responseHeaders;
  const totalBytes = requestsPerMinute * (payloadSize + perRequestOverhead);
  const usefulBytes = requestsPerMinute * payloadSize;
  const overheadRatio = (totalBytes / usefulBytes).toFixed(1);
  const latencyPerRequest = rtt * 4; // TCP (1 RTT) + TLS 1.2 (2 RTTs) + req/resp (1 RTT)
  const totalLatency = requestsPerMinute * latencyPerRequest;
  
  return {
    totalBytes,
    usefulBytes,
    overheadBytes: totalBytes - usefulBytes,
    overheadRatio,
    latencyPerRequest,
    totalLatency,
    fitsInMinute: totalLatency < 60000
  };
}

http1Keepalive = {
  const perRequestOverhead = requestHeaders + responseHeaders;
  const totalBytes = requestsPerMinute * (payloadSize + perRequestOverhead);
  const usefulBytes = requestsPerMinute * payloadSize;
  const overheadRatio = (totalBytes / usefulBytes).toFixed(1);
  const setupLatency = rtt * 3; // One-time TCP + TLS
  const latencyPerRequest = rtt; // Single RTT per request
  const totalLatency = setupLatency + (requestsPerMinute * latencyPerRequest);
  
  return {
    totalBytes,
    usefulBytes,
    overheadBytes: totalBytes - usefulBytes,
    overheadRatio,
    latencyPerRequest,
    totalLatency,
    fitsInMinute: totalLatency < 60000
  };
}

http2Stats = {
  const compressedHeaders = 50; // HPACK compression
  const perRequestOverhead = compressedHeaders + 35; // Response headers also compressed
  const totalBytes = requestsPerMinute * (payloadSize + perRequestOverhead);
  const usefulBytes = requestsPerMinute * payloadSize;
  const overheadRatio = (totalBytes / usefulBytes).toFixed(1);
  const setupLatency = rtt * 2; // TCP + TLS 1.3
  const latencyPerRequest = rtt; // Multiplexed, but still 1 RTT
  const totalLatency = setupLatency + latencyPerRequest; // Parallel
  
  return {
    totalBytes,
    usefulBytes,
    overheadBytes: totalBytes - usefulBytes,
    overheadRatio,
    latencyPerRequest,
    totalLatency,
    fitsInMinute: true
  };
}

http3Stats = {
  const compressedHeaders = 45; // QPACK compression
  const perRequestOverhead = compressedHeaders + 30;
  const totalBytes = requestsPerMinute * (payloadSize + perRequestOverhead);
  const usefulBytes = requestsPerMinute * payloadSize;
  const overheadRatio = (totalBytes / usefulBytes).toFixed(1);
  const setupLatency = 0; // 0-RTT resumption
  const latencyPerRequest = rtt;
  const totalLatency = latencyPerRequest; // Parallel + 0-RTT
  
  return {
    totalBytes,
    usefulBytes,
    overheadBytes: totalBytes - usefulBytes,
    overheadRatio,
    latencyPerRequest,
    totalLatency,
    fitsInMinute: true
  };
}

currentStats = protocol === "HTTP/1.1 (no keepalive)" ? http1NoKeepalive :
                protocol === "HTTP/1.1 (keepalive)" ? http1Keepalive :
                protocol === "HTTP/2" ? http2Stats : http3Stats

Show code

html`<div style="background: #f8f9fa; padding: 20px; border-radius: 8px; border-left: 4px solid #2C3E50;">
  <h3 style="margin-top: 0; color: #2C3E50;">📊 ${protocol} Results</h3>
  <div style="display: grid; grid-template-columns: 1fr 1fr; gap: 15px; margin-top: 15px;">
    <div>
      <strong style="color: #16A085;">Total Bandwidth per Minute:</strong><br>
      ${(currentStats.totalBytes / 1024).toFixed(1)} KB
    </div>
    <div>
      <strong style="color: #16A085;">Useful Data:</strong><br>
      ${(currentStats.usefulBytes / 1024).toFixed(1)} KB
    </div>
    <div>
      <strong style="color: #E67E22;">Overhead:</strong><br>
      ${(currentStats.overheadBytes / 1024).toFixed(1)} KB (${((currentStats.overheadBytes / currentStats.totalBytes) * 100).toFixed(1)}%)
    </div>
    <div>
      <strong style="color: #E74C3C;">Overhead Ratio:</strong><br>
      ${currentStats.overheadRatio}:1
    </div>
    <div>
      <strong style="color: #3498DB;">Total Latency:</strong><br>
      ${(currentStats.totalLatency / 1000).toFixed(2)} seconds
    </div>
    <div>
      <strong style="color: ${currentStats.fitsInMinute ? '#16A085' : '#E74C3C'};">Fits in 60s?</strong><br>
      ${currentStats.fitsInMinute ? '✓ Yes' : '✗ No - Cannot complete'}
    </div>
  </div>
</div>`

Show code

comparisonData = [
  {protocol: "HTTP/1.1\n(no keepalive)", bandwidth: http1NoKeepalive.totalBytes / 1024, latency: http1NoKeepalive.totalLatency / 1000},
  {protocol: "HTTP/1.1\n(keepalive)", bandwidth: http1Keepalive.totalBytes / 1024, latency: http1Keepalive.totalLatency / 1000},
  {protocol: "HTTP/2", bandwidth: http2Stats.totalBytes / 1024, latency: http2Stats.totalLatency / 1000},
  {protocol: "HTTP/3", bandwidth: http3Stats.totalBytes / 1024, latency: http3Stats.totalLatency / 1000}
]

Plot.plot({
  marginLeft: 70,
  marginBottom: 60,
  grid: true,
  y: {label: "Bandwidth (KB/min)"},
  x: {label: "Protocol"},
  color: {range: ["#2C3E50", "#16A085", "#E67E22", "#3498DB"]},
  marks: [
    Plot.barY(comparisonData, {
      x: "protocol",
      y: "bandwidth",
      fill: (d, i) => ["#2C3E50", "#16A085", "#E67E22", "#3498DB"][i],
      tip: true
    }),
    Plot.ruleY([0])
  ]
})

Show code

Plot.plot({
  marginLeft: 70,
  marginBottom: 60,
  grid: true,
  y: {label: "Latency (seconds)"},
  x: {label: "Protocol"},
  color: {range: ["#2C3E50", "#16A085", "#E67E22", "#3498DB"]},
  marks: [
    Plot.barY(comparisonData.filter(d => d.latency < 120), {
      x: "protocol",
      y: "latency",
      fill: (d, i) => ["#2C3E50", "#16A085", "#E67E22", "#3498DB"][i],
      tip: true
    }),
    Plot.ruleY([0])
  ]
})

Key Insights:

Overhead ratio shows how many bytes of overhead per byte of useful data
HTTP/2 and HTTP/3 reduce bandwidth by ~85% through header compression
Multiplexing (HTTP/2/3) enables parallel requests, reducing total latency dramatically
0-RTT resumption (HTTP/3) eliminates connection setup time entirely

3.6 Battery Life Estimator

Calculate how long your IoT device battery will last with different HTTP protocols:

Show code

viewof batteryCapacity = Inputs.range([500, 5000], {
  value: 2000,
  step: 100,
  label: "Battery capacity (mAh)"
})

viewof reportInterval = Inputs.range([10, 3600], {
  value: 60,
  step: 10,
  label: "Report interval (seconds)"
})

viewof radioActivePower = Inputs.range([50, 250], {
  value: 120,
  step: 10,
  label: "Radio active power (mA @ 3.7V)"
})

viewof idlePower = Inputs.range([1, 50], {
  value: 5,
  step: 1,
  label: "Idle/sleep power (mA)"
})

Show code

batteryHttp1 = {
  const reportsPerDay = (24 * 3600) / reportInterval;
  const latencyPerRequest = (rtt * 3) / 1000; // TCP + TLS + req/resp in seconds
  const activeTimePerDay = reportsPerDay * latencyPerRequest / 3600; // hours
  const idleTimePerDay = 24 - activeTimePerDay;
  
  const activeEnergyPerDay = activeTimePerDay * radioActivePower;
  const idleEnergyPerDay = idleTimePerDay * idlePower;
  const totalEnergyPerDay = activeEnergyPerDay + idleEnergyPerDay;
  
  const daysOnBattery = batteryCapacity / totalEnergyPerDay;
  
  return {
    activeTimePerDay,
    totalEnergyPerDay,
    daysOnBattery
  };
}

batteryHttp2 = {
  const reportsPerDay = (24 * 3600) / reportInterval;
  const latencyPerRequest = rtt / 1000; // Multiplexed, single RTT in seconds
  const activeTimePerDay = reportsPerDay * latencyPerRequest / 3600;
  const idleTimePerDay = 24 - activeTimePerDay;
  
  const activeEnergyPerDay = activeTimePerDay * radioActivePower;
  const idleEnergyPerDay = idleTimePerDay * idlePower;
  const totalEnergyPerDay = activeEnergyPerDay + idleEnergyPerDay;
  
  const daysOnBattery = batteryCapacity / totalEnergyPerDay;
  
  return {
    activeTimePerDay,
    totalEnergyPerDay,
    daysOnBattery
  };
}

batteryHttp3 = {
  const reportsPerDay = (24 * 3600) / reportInterval;
  const latencyPerRequest = rtt / 1000; // 0-RTT resumption
  const activeTimePerDay = reportsPerDay * latencyPerRequest / 3600;
  const idleTimePerDay = 24 - activeTimePerDay;
  
  const activeEnergyPerDay = activeTimePerDay * radioActivePower;
  const idleEnergyPerDay = idleTimePerDay * idlePower;
  const totalEnergyPerDay = activeEnergyPerDay + idleEnergyPerDay;
  
  const daysOnBattery = batteryCapacity / totalEnergyPerDay;
  
  return {
    activeTimePerDay,
    totalEnergyPerDay,
    daysOnBattery
  };
}

Show code

html`<div style="background: #f8f9fa; padding: 20px; border-radius: 8px; border-left: 4px solid #16A085;">
  <h3 style="margin-top: 0; color: #2C3E50;">🔋 Battery Life Comparison</h3>
  <div style="display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 20px; margin-top: 15px;">
    <div style="text-align: center; padding: 15px; background: white; border-radius: 6px;">
      <div style="font-size: 14px; color: #7F8C8D; margin-bottom: 5px;">HTTP/1.1 (no keepalive)</div>
      <div style="font-size: 32px; font-weight: bold; color: #E74C3C;">${batteryHttp1.daysOnBattery.toFixed(0)}</div>
      <div style="font-size: 14px; color: #7F8C8D;">days</div>
      <div style="font-size: 12px; color: #95a5a6; margin-top: 5px;">${(batteryHttp1.activeTimePerDay * 60).toFixed(1)} min active/day</div>
    </div>
    <div style="text-align: center; padding: 15px; background: white; border-radius: 6px;">
      <div style="font-size: 14px; color: #7F8C8D; margin-bottom: 5px;">HTTP/2</div>
      <div style="font-size: 32px; font-weight: bold; color: #E67E22;">${batteryHttp2.daysOnBattery.toFixed(0)}</div>
      <div style="font-size: 14px; color: #7F8C8D;">days</div>
      <div style="font-size: 12px; color: #95a5a6; margin-top: 5px;">${(batteryHttp2.activeTimePerDay * 60).toFixed(1)} min active/day</div>
    </div>
    <div style="text-align: center; padding: 15px; background: white; border-radius: 6px;">
      <div style="font-size: 14px; color: #7F8C8D; margin-bottom: 5px;">HTTP/3</div>
      <div style="font-size: 32px; font-weight: bold; color: #16A085;">${batteryHttp3.daysOnBattery.toFixed(0)}</div>
      <div style="font-size: 14px; color: #7F8C8D;">days</div>
      <div style="font-size: 12px; color: #95a5a6; margin-top: 5px;">${(batteryHttp3.activeTimePerDay * 60).toFixed(1)} min active/day</div>
    </div>
  </div>
  <div style="margin-top: 20px; padding: 15px; background: #fff3cd; border-radius: 6px; border-left: 4px solid #E67E22;">
    <strong>💡 Savings:</strong> HTTP/3 provides <strong>${((batteryHttp3.daysOnBattery - batteryHttp1.daysOnBattery) / batteryHttp1.daysOnBattery * 100).toFixed(0)}%</strong> longer battery life vs HTTP/1.1
  </div>
</div>`

Interpretation:

Radio active time is the biggest battery drain for IoT devices
Connection setup overhead (TCP + TLS handshakes) keeps the radio active longer
HTTP/2 and HTTP/3 reduce active time by eliminating redundant handshakes
0-RTT resumption in HTTP/3 provides additional power savings

3.7 Start Learning

Recommended path:

Start with HTTP Pitfalls and Connection Management to understand common mistakes
Continue to HTTP/2 and HTTP/3 for IoT for modern solutions

For experienced developers:

Jump directly to HTTP/2 and HTTP/3 for IoT for protocol comparison

3.8 Key Concepts Preview

3.8.1 HTTP Pitfalls to Avoid

Polling Battery Drain: HTTP polling drains batteries 20-40x faster than MQTT
TLS Handshake Overhead: New connections add 400-600ms latency on cellular
Fixed Reconnection Intervals: Causes thundering herd problems
Missing Keep-Alive: 60-80% latency penalty without connection pooling
Unbounded Payloads: Can crash resource-constrained gateways

3.8.2 Modern HTTP Solutions

Protocol	Key Feature	IoT Benefit
HTTP/2	Multiplexing	50x faster gateway uploads
HTTP/2	HPACK compression	90% header reduction
HTTP/3	QUIC 0-RTT	30-50% power savings
HTTP/3	Independent streams	No head-of-line blocking
HTTP/3	Connection migration	Mobile network handoff

3.9 HTTP Protocol Selection Decision Tree

Quick Check: Protocol Selection

Before reading the architecture comparison, test your understanding of the decision tree above.

3.10 HTTP/2 vs HTTP/3 Architecture Comparison

Common Pitfalls with HTTP in IoT

1. Using HTTP polling as a push substitute: Polling every 5 seconds wastes 95%+ of radio time on empty responses. Use MQTT, WebSocket, or HTTP/2 server push instead. A device polling once per second on cellular burns its battery in days, not years.

2. Ignoring TLS session resumption: Every new TLS 1.2 handshake costs 2 RTTs (100-600ms on cellular). Enable TLS session tickets or upgrade to TLS 1.3 (1 RTT) or HTTP/3/QUIC (0-RTT) to avoid reconnection storms after network outages.

3. Fixed retry intervals after failure: When 10,000 devices lose connection simultaneously and all retry at exactly 30-second intervals, the server sees a “thundering herd” that can cause cascading failures. Always use exponential backoff with random jitter: delay = base * 2^attempt + random(0, base).

4. Sending JSON when binary would suffice: A JSON payload {"temperature": 23.5, "humidity": 67} is ~40 bytes. The same data in CBOR or Protocol Buffers is ~8 bytes. On HTTP/1.1 with 500 bytes of headers, this saves little – but on HTTP/2 with compressed headers, payload efficiency matters.

5. Not setting Content-Length or using chunked encoding improperly: Missing Content-Length forces the server to buffer the entire response before processing, which can crash gateways with limited RAM. Always set explicit content lengths for IoT payloads.

6. Assuming HTTP/2 works everywhere: Many IoT gateways, embedded TLS libraries, and LPWAN proxies only support HTTP/1.1. Always verify HTTP/2 support end-to-end before depending on multiplexing.

3.11 Worked Example: Calculating HTTP Overhead for a Smart Building Gateway

Worked Example: HTTP Protocol Overhead Analysis

Scenario: A smart building gateway collects data from 200 temperature/humidity sensors. Each sensor reports a 48-byte JSON payload every 60 seconds. The gateway forwards all readings to a cloud API over cellular (LTE Cat-M1). Calculate the overhead for HTTP/1.1 vs HTTP/2 vs HTTP/3 and determine the best protocol.

Given:

200 sensors, 48-byte payload each, 60-second reporting interval
Cellular RTT: 150ms average
HTTP/1.1 headers: ~500 bytes per request, ~350 bytes per response
HTTP/2 HPACK compressed headers: ~50 bytes (after initial exchange)
HTTP/3 QPACK compressed headers: ~45 bytes
TLS 1.2 handshake: 2 RTTs (300ms)
TLS 1.3 handshake: 1 RTT (150ms)
QUIC 0-RTT resumption: 0 RTTs (0ms)

Step 1: HTTP/1.1 with individual connections (worst case)

Each sensor reading requires a separate request:

Per-request overhead: 500 (req headers) + 350 (resp headers) = 850 bytes
Per-request latency (new connection): 150ms (TCP) + 300ms (TLS 1.2) + 150ms (request/response) = 600ms
Total data per minute: 200 x (850 + 48) = 179,600 bytes (179.6 KB)
Useful data: 200 x 48 = 9,600 bytes (9.6 KB)
Overhead ratio: 18.7:1 (94.7% overhead)
Total serial latency: 200 x 600ms = 120 seconds (cannot complete in 60s window!)

Step 2: HTTP/1.1 with keep-alive (improved)

Reuse a single TCP+TLS connection:

Connection setup (once): 150ms + 300ms = 450ms
Per-request overhead: 500 + 350 = 850 bytes (headers unchanged)
Per-request latency: 150ms (single RTT)
Total data per minute: 200 x (850 + 48) = 179,600 bytes (179.6 KB)
Total serial latency: 450ms + 200 x 150ms = 30,450ms (~30.5 seconds)
Overhead ratio: 18.7:1 (same bytes, but fits in time window)

Step 3: HTTP/2 with multiplexing

Single connection, parallel streams, compressed headers:

Connection setup (once): 150ms + 150ms (TLS 1.3) = 300ms
Per-request overhead: 50 + 35 = 85 bytes (HPACK compressed)
Parallel streams: all 200 requests sent simultaneously
Total data per minute: 200 x (85 + 48) = 26,600 bytes (26.6 KB)
Total latency: 300ms + 150ms (single RTT for all) = 450ms
Overhead ratio: 2.8:1 (85% reduction from HTTP/1.1)

Step 4: HTTP/3 with QUIC (best case)

0-RTT resumption, independent streams:

Connection setup (resumed): 0ms (0-RTT)
Per-request overhead: 45 + 30 = 75 bytes (QPACK compressed)
Independent streams: no head-of-line blocking
Total data per minute: 200 x (75 + 48) = 24,600 bytes (24.6 KB)
Total latency: 150ms (single RTT) = 150ms
Overhead ratio: 2.6:1 (86% reduction from HTTP/1.1)

Conclusion:

Metric	HTTP/1.1 (no keepalive)	HTTP/1.1 (keepalive)	HTTP/2	HTTP/3
Data/min	179.6 KB	179.6 KB	26.6 KB	24.6 KB
Overhead ratio	18.7:1	18.7:1	2.8:1	2.6:1
Latency	120s (fails)	30.5s	450ms	150ms
Fits in 60s?	No	Yes	Yes	Yes

Recommendation: HTTP/2 is the practical choice for this gateway, providing 85% overhead reduction and sub-second latency. HTTP/3 offers marginal additional improvement but requires QUIC support on both gateway and cloud endpoint, which may not be available on all LTE Cat-M1 modems. HTTP/1.1 without keep-alive literally cannot finish within the reporting window.

Putting Numbers to It: HTTP/2 Multiplexing Efficiency

Scenario: Gateway uploads data from 100 sensors simultaneously.

HTTP/1.1 serial processing: \[ \begin{align} \text{Per request latency} &= 150 \text{ ms (1 RTT)} \\ \text{Total time} &= 100 \times 150 = 15{,}000 \text{ ms} = 15 \text{ seconds} \end{align} \]

HTTP/2 parallel multiplexing: \[ \begin{align} \text{All requests in parallel} &= 1 \times 150 = 150 \text{ ms} \\ \text{Speedup} &= \frac{15{,}000}{150} = 100\times \end{align} \]

HPACK compression savings: \[ \begin{align} \text{HTTP/1.1 headers} &= 500 \text{ bytes/request} \\ \text{HTTP/2 first request} &= 500 \text{ bytes (full headers)} \\ \text{HTTP/2 subsequent} &= 50 \text{ bytes (compressed)} \\ \text{Total HTTP/1.1} &= 100 \times 500 = 50{,}000 \text{ bytes} \\ \text{Total HTTP/2} &= 500 + (99 \times 50) = 5{,}450 \text{ bytes} \\ \text{Compression ratio} &= \frac{50{,}000 - 5{,}450}{50{,}000} = 89.1\% \end{align} \]

Battery impact (cellular): \[ \begin{align} \text{Radio active time (HTTP/1.1)} &= 15 \text{ s} \\ \text{Radio active time (HTTP/2)} &= 0.15 \text{ s} \\ \text{Power (120 mA @ 3.7V)} &= 0.444 \text{ W} \\ \text{Energy (HTTP/1.1)} &= 0.444 \times 15 = 6.66 \text{ Ws} \\ \text{Energy (HTTP/2)} &= 0.444 \times 0.15 = 0.067 \text{ Ws} \\ \text{Power savings} &= \frac{6.66 - 0.067}{6.66} = 99\% \end{align} \]

Interactive Concept Exercises

Practice matching key HTTP protocol concepts to their definitions, then sequence the steps of an HTTP/3 connection resumption.

3.12 Knowledge Check: HTTP Protocols for IoT

Test your understanding of HTTP protocol selection and overhead for IoT applications.

***

3.13 Prerequisites

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

Application Protocols Overview: Basic understanding of IoT application protocols
CoAP vs MQTT Comparison: Protocol trade-offs

🏷️ Label the Diagram

💻 Code Challenge

3.14 Summary

HTTP remains ubiquitous in IoT ecosystems because of its universal tooling support, developer familiarity, and compatibility with cloud APIs. However, using the wrong HTTP version or configuration can waste 95% of bandwidth and drain batteries in days instead of years.

Key takeaways from this module:

Concept	Key Insight
HTTP/1.1 overhead	200-800 bytes of headers per request make it unsuitable for small IoT payloads without keep-alive and connection pooling
Polling is expensive	HTTP polling drains batteries 20-40x faster than push-based protocols; use WebSocket, MQTT, or server push instead
HTTP/2 multiplexing	A single TCP connection carries hundreds of parallel streams; HPACK reduces headers by 90%
HTTP/3 QUIC	0-RTT resumption eliminates handshake latency; independent streams solve head-of-line blocking; connection migration supports mobile devices
Protocol selection	Match protocol to constraints: CoAP for tiny devices, HTTP/2 for gateways, HTTP/3 for mobile, MQTT for event-driven
Reconnection strategy	Always use exponential backoff with jitter to prevent thundering herd after network outages

Decision quick reference:

Device < 256 KB RAM – Use CoAP, not HTTP
Gateway aggregating many sensors – HTTP/2 with HPACK
Mobile device switching networks – HTTP/3 with QUIC
Real-time bidirectional – WebSocket or MQTT
Simple cloud API calls – HTTP/1.1 with keep-alive and TLS 1.3

3.15 Concept Relationships

HTTP protocols for IoT connect to:

Foundation Concepts:

Application Protocols Overview - When to use HTTP vs CoAP/MQTT
Transport Layer Fundamentals - TCP vs UDP implications

Modern Alternatives:

HTTP/2 Features - Multiplexing and header compression
HTTP/3 QUIC - 0-RTT resumption and connection migration
WebSockets - Full-duplex bidirectional communication

Design Patterns:

REST API Design - RESTful patterns over HTTP
Polling vs Push - When to use alternatives to HTTP polling

3.16 See Also

Pitfalls and Solutions:

HTTP Pitfalls and Connection Management - Common mistakes and fixes
TLS Optimization - Session resumption and certificate pinning

Protocol Comparisons:

CoAP vs HTTP - RESTful alternatives for constrained devices
QUIC vs TCP - Transport layer comparison

Implementation Resources:

HTTP/2 Server Push Examples - Reducing latency with push
QUIC Implementation Guide - Deploying HTTP/3 in production

Tools:

h2load - HTTP/2 load testing
curl with HTTP/3 - Testing QUIC connections
Wireshark HTTP/2 Analysis - Packet inspection

3.17 What’s Next?

Chapter	Focus	Why Read It
HTTP Pitfalls and Connection Management	Polling battery drain, TLS overhead, WebSocket management	Essential first step — understand the most costly HTTP mistakes before implementing any IoT HTTP client
HTTP/2 and HTTP/3 for IoT	Multiplexing, HPACK, QUIC transport, 0-RTT resumption	Deep-dive into modern HTTP protocol mechanics and implementation patterns
IoT API Design Best Practices	REST API design, versioning, pagination, error handling	Build well-structured HTTP APIs that scale from prototype to production
CoAP vs MQTT Comparison	Protocol trade-offs for constrained devices	Understand when HTTP is the wrong choice and CoAP or MQTT is a better fit
Real-Time Protocols	WebRTC, WebSocket, SSE for bidirectional IoT	Learn push-based alternatives to HTTP polling for real-time sensor dashboards
Transport Layer Fundamentals	TCP vs UDP, congestion control, reliability	Understand the transport foundations that HTTP/2 (TCP) and HTTP/3 (QUIC/UDP) build upon