4  Modern HTTP for IoT

app-protocols
http
modern

Start with the story: Modern HTTP is the web stack learning to move many IoT conversations without reopening the road for every request. HTTP/2 keeps several streams moving through one connection, while HTTP/3 uses QUIC so one lost packet does not freeze every stream behind it.

In 60 Seconds

HTTP/2 and HTTP/3 transform HTTP from a heavyweight protocol into a viable IoT option for gateways and mobile scenarios. HTTP/2’s multiplexing reduces per-request handshake overhead and can make gateway connections 50x faster, while HTTP/3’s QUIC transport over UDP eliminates TCP head-of-line blocking and provides 0-RTT connection resumption that reduces cellular IoT power consumption by 30-50%. These are not replacements for MQTT or CoAP on constrained devices – they require 32KB+ RAM – but they efficiently leverage existing HTTP infrastructure where resources allow.

Chapter Roadmap

First, separate the gateway case for HTTP/2 from the mobile-cellular case for HTTP/3. Then, use the calculators to connect 50 sensor uploads, 100ms cellular RTT, 96 wake cycles, and 0-RTT resumption to latency and energy choices. Next, choose among HTTP/2, HTTP/3, MQTT, and CoAP with the memory and network decision guide. Finally, translate the choice into library support, keep-alive settings, and production pitfalls. Checkpoints summarize each cluster; deep-dive material and experiments are optional.

4.1 Learning Objectives

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

  • Explain HTTP/2 Multiplexing: Describe how binary framing, stream multiplexing, and HPACK header compression reduce IoT gateway overhead by up to 76%
  • Evaluate HTTP/3 vs HTTP/2: Compare QUIC transport benefits against TCP-based HTTP/2 for mobile and cellular IoT deployments, justifying the choice based on network conditions
  • Select the Appropriate Protocol: Distinguish between HTTP/1.1, HTTP/2, and HTTP/3 based on device RAM constraints, network stability, and firewall policies
  • Configure Modern HTTP: Implement HTTP/2 and HTTP/3 settings for IoT gateways and cloud backends, including keep-alive tuning and QUIC server configuration
  • Calculate Protocol Overhead: Assess bandwidth and latency costs for each HTTP version and apply the correct formula to estimate cellular radio active time and battery impact
  • Diagnose Head-of-Line Blocking: Analyze why HTTP/2 over TCP suffers transport-layer HOL blocking under packet loss, and demonstrate how HTTP/3 QUIC streams solve this

4.2 Prerequisites

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

MVU: Most Valuable Understanding

HTTP/2 and HTTP/3 transform HTTP from a heavyweight protocol into a viable IoT option for gateway and mobile scenarios. The key insight is that modern HTTP isn’t about replacing MQTT or CoAP for constrained devices - it’s about leveraging existing HTTP infrastructure efficiently when you have sufficient resources (32KB+ RAM). HTTP/2’s multiplexing can make gateway scenarios 50x faster, while HTTP/3’s QUIC transport with 0-RTT resumption can reduce cellular IoT power consumption by 30-50%.

Cross-Hub Connections

Explore Related Learning Resources:

Cross-Reference with Other Topics:

Meet the Sensor Squad! Sammy the Temperature Sensor needs to send LOTS of messages to the Cloud Castle, but the old road is SO SLOW!

The Problem: Sammy and 49 other sensors all want to send their readings to the Cloud Castle using HTTP/1.1. But the old road only has ONE lane!

“We have to wait in line FOREVER!” complains Sammy. “By the time my message arrives, the temperature has already changed!”

Lila the Light Sensor has an idea: “What if we could all travel on the SAME road at the SAME time? That’s what HTTP/2 does - it’s like a multi-lane highway!”

Max the Motion Sensor explains HTTP/2:

HTTP/1.1 (Old Single-Lane Road):
Sammy -> [Wait] -> [Wait] -> [Wait] -> Cloud Castle
Lila  -> [Wait] -> [Wait] -> [Wait] -> Cloud Castle
Max   -> [Wait] -> [Wait] -> [Wait] -> Cloud Castle
Time: 10 seconds for everyone!

HTTP/2 (Multi-Lane Highway):
Sammy -> Cloud Castle
Lila  -> Cloud Castle     ALL AT ONCE!
Max   -> Cloud Castle
Time: Just 200 milliseconds!

Bella the Button is amazed: “Wow, 50 times faster! But what about when the road has potholes?”

Max explains HTTP/3: “HTTP/3 uses magic flying cars (QUIC)! If one car hits a pothole, the others just fly over it. Nobody has to wait!”

Sammy’s Rules for Choosing Roads:

Situation Best Road Why
Tiny sensors with small batteries Use the bicycle path (CoAP/MQTT) Less energy needed!
Gateway sending many messages Use the multi-lane highway (HTTP/2) All messages travel together!
Car tracker on bumpy cellular Use the flying cars (HTTP/3) Doesn’t get stuck in potholes!

The Happy Ending: Sammy and all 50 sensors now use HTTP/2 to send their readings through the gateway. What used to take 10 seconds now takes only 200 milliseconds! And when Sammy’s friend Carla the Car Tracker travels on bumpy cellular networks, she uses HTTP/3’s flying cars to never get stuck.

The Lesson: Modern HTTP is like upgrading from a single-lane country road to a superhighway - perfect for when you have lots of data to move quickly!

Key Concepts

  • Core Concept: Fundamental principle underlying Modern HTTP for IoT — understanding this enables all downstream design decisions
  • Key Metric: Primary quantitative measure for evaluating Modern HTTP for IoT performance in real deployments
  • Trade-off: Central tension in Modern HTTP for IoT design — optimizing one parameter typically degrades another
  • Protocol/Algorithm: Standard approach or algorithm most commonly used in Modern HTTP for IoT implementations
  • Deployment Consideration: Practical factor that must be addressed when deploying Modern HTTP for IoT in production
  • Common Pattern: Recurring design pattern in Modern HTTP for IoT that solves the most frequent implementation challenges
  • Performance Benchmark: Reference values for Modern HTTP for IoT performance metrics that indicate healthy vs. problematic operation

4.3 Introduction: Beyond HTTP/1.1

While HTTP/1.1 is often dismissed as too heavyweight for IoT, the newer HTTP/2 and HTTP/3 protocols offer significant improvements that make HTTP more viable for certain IoT applications.

Layered diagram comparing protocol stacks for HTTP/1.1, HTTP/2, and HTTP/3. All use TLS for security but HTTP/3 replaces TCP with QUIC over UDP, providing integrated transport and security in a single layer.

HTTP Protocol Stack Comparison: HTTP/1.1 vs HTTP/2 vs HTTP/3
Figure 4.1: HTTP Protocol Stack Comparison: HTTP/1.1 vs HTTP/2 vs HTTP/3

Think of HTTP/1.1 like a single-lane road where cars (requests) must wait for each other. HTTP/2 is like a multi-lane highway where many cars travel simultaneously. HTTP/3 goes further - it’s like having flying cars that don’t get stuck in traffic jams caused by road damage (packet loss).

For IoT devices that need to send lots of small messages or work over unreliable cellular networks, these improvements can mean: - Faster data delivery - Less battery drain - More reliable connections

4.4 HTTP/2: Multiplexing and Header Compression

HTTP/2 addresses many HTTP/1.1 limitations with binary framing, multiplexed streams, and header compression.

4.4.1 Key Improvements Over HTTP/1.1

Feature HTTP/1.1 HTTP/2 IoT Benefit
Connections Multiple TCP connections needed Single connection, multiplexed streams Reduced handshake overhead
Headers Repeated in full each request HPACK compression (90%+ reduction) Smaller packet sizes
Server Push Not supported Server can proactively send resources Efficient firmware distribution
Binary Protocol Text-based (verbose) Binary framing Faster parsing on MCUs
Stream Priority None Priority hints for streams Critical data first

Sequence diagram comparing HTTP/1.1 sequential request-response pattern with HTTP/2 multiplexed streams. HTTP/1.1 shows blocking behavior where each request waits for response, while HTTP/2 shows parallel streams over single connection.

HTTP/1.1 Sequential Requests vs HTTP/2 Multiplexed Streams
Figure 4.2: HTTP/1.1 Sequential Requests vs HTTP/2 Multiplexed Streams

4.4.2 Header Compression with HPACK

One of HTTP/2’s most impactful features for IoT is HPACK header compression:

HTTP/1.1 headers (repeated every request):
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
User-Agent: IoT-Sensor/1.0
Accept: application/json
Host: api.example.com
(~350 bytes per request)

HTTP/2 with HPACK:
First request: ~350 bytes (headers indexed)
Subsequent requests: ~15-30 bytes (index references only)
Savings: 90%+ for repeated headers

Broker BexCheckpoint: header compression

You now know:

  • HPACK sends full repeated headers once, then reuses index references around 15-30 bytes instead of retransmitting about 350 bytes.
  • The 90%+ header reduction matters most when a gateway posts the same Host, Authorization, and Content-Type fields over and over.
  • Header compression only pays off when the connection stays alive long enough for the shared table to be reused.

With header cost under control, the next question is what happens when the gateway has many readings ready at the same time.

4.4.3 Multiplexing Benefits for IoT Gateways

Scenario: Gateway aggregating 50 sensors, sending to cloud

HTTP/1.1 approach:
- 50 sequential requests OR 6-8 parallel connections
- Each connection: TCP handshake (1.5 RTT) + TLS (2 RTT)
- Total overhead: 50 x 200ms = 10 seconds

HTTP/2 approach:
- Single TCP+TLS connection (1 RTT handshake, amortized)
- 50 multiplexed streams in parallel
- Total time: ~200ms (1 RTT + minimal framing)
- 50x faster for gateway scenarios
Interactive Calculator: HTTP/2 Multiplexing Savings

Calculate time and bandwidth savings when using HTTP/2 multiplexing for IoT gateway scenarios.

Architecture diagram showing IoT gateway aggregating data from 50 sensors and uploading to cloud API via single HTTP/2 connection with multiplexed streams, demonstrating 50x performance improvement over HTTP/1.1.

HTTP/2 Gateway Scenario: Parallel Sensor Data Upload
Figure 4.3: HTTP/2 Gateway Scenario: Parallel Sensor Data Upload

Broker BexCheckpoint: multiplexed gateways

You now know:

  • HTTP/1.1 can force 50 sequential requests or multiple connection waves; HTTP/2 sends the same gateway batch over one multiplexed connection.
  • The chapter’s gateway example compresses the delay from about 10 seconds to about 200ms when the cloud API can keep one HTTP/2 session open.
  • HTTP/2 is a gateway and cloud-integration tool, not a replacement for MQTT or CoAP on the smallest sensors.

HTTP/2 removes the gateway queue at the HTTP layer. The next section asks what still goes wrong when the transport underneath that queue is lossy or mobile.

4.5 HTTP/3: QUIC Transport for Unreliable Networks

HTTP/3 replaces TCP with QUIC (UDP-based), offering advantages for IoT deployments with unstable connectivity.

4.5.1 Key Features for IoT

Feature HTTP/2 (TCP) HTTP/3 (QUIC) IoT Use Case
Connection establishment 3-way handshake + TLS 0-RTT or 1-RTT Mobile/cellular IoT
Head-of-line blocking Stream blocked by packet loss Independent streams Lossy wireless links
Connection migration Breaks on IP change Survives network switch Vehicle telematics
Congestion control Per-connection Per-stream Mixed priority data

Mind map showing QUIC protocol features and their corresponding IoT benefits: 0-RTT connection for fast wake-up, connection migration for mobile IoT, independent streams for mixed priority data, and built-in encryption for security.

HTTP/3 QUIC Features Mapped to IoT Benefits
Figure 4.4: HTTP/3 QUIC Features Mapped to IoT Benefits

4.5.2 0-RTT Connection Resumption

The following comparison shows the dramatic difference in connection establishment time:

Scenario: Cellular IoT device waking from sleep

TCP + TLS 1.3:
1. TCP SYN                           (1 RTT)
2. TCP SYN-ACK + TLS ClientHello
3. TLS ServerHello + Application data (1 RTT)
Total: 2 RTT before sending data (~200-400ms on cellular)

QUIC (HTTP/3) with 0-RTT:
1. ClientHello + Encrypted data       (0 RTT!)
2. Server response
Total: 0 RTT for resumed connections
Power savings: 30-50% reduction in radio active time

Gantt chart comparing connection establishment timelines. HTTP/1.1 and HTTP/2 over TCP require TCP handshake (1 RTT) plus TLS handshake (1-2 RTT) before data transfer. HTTP/3 with QUIC 0-RTT sends data in first packet, showing 70% latency reduction on cellular networks.

Connection Latency Comparison: TCP+TLS vs QUIC
Figure 4.5: Connection Latency Comparison: TCP+TLS vs QUIC
Latency Impact on Cellular IoT

On a typical LTE network with 100ms RTT:

  • HTTP/1.1 + TLS 1.2: ~350-400ms before first data (radio active for 400ms)
  • HTTP/2 + TLS 1.3: ~250-300ms before first data (25% improvement)
  • HTTP/3 + QUIC 0-RTT: ~100ms for resumed connections (70% improvement)

For a device waking 96 times per day (every 15 minutes), this translates to: - HTTP/1.1: 33.6 seconds of radio time/day (96 × 3.5 RTTs × 100 ms) - HTTP/3: 9.6 seconds of radio time/day (96 × 1.0 RTT × 100 ms) - Battery savings: ~71% reduction in connection overhead

Connection latency directly translates to radio active time. For \(n\) wake cycles per day with RTT \(t\) milliseconds:

\[T_{\text{active}} = n \cdot k \cdot t\]

where \(k\) is the RTT multiplier: \(k_{\text{HTTP/1.1}} = 3.5\), \(k_{\text{HTTP/2}} = 2.5\), \(k_{\text{HTTP/3,0-RTT}} = 1\).

For this cellular device with \(n = 96\) wakes/day and \(t = 100\text{ms}\) RTT: - HTTP/1.1: \(T = 96 \times 3.5 \times 0.1 = 33.6\text{s/day}\) - HTTP/2: \(T = 96 \times 2.5 \times 0.1 = 24\text{s/day}\) - HTTP/3 (0-RTT): \(T = 96 \times 1 \times 0.1 = 9.6\text{s/day}\)

At 300mA radio draw and 3.7V supply: Daily energy \(= T_{\text{active}} \times 0.3\text{A} \times 3.7\text{V}\). - HTTP/1.1: \(33.6\text{s} \times 1.11\text{W} = 37.3\text{J/day}\) - HTTP/3: \(9.6\text{s} \times 1.11\text{W} = 10.7\text{J/day}\)

Savings: \((37.3 - 10.7)/37.3 = 71\%\) energy reduction from eliminating handshake overhead alone.

Interactive Calculator: QUIC 0-RTT Battery Savings

Calculate cellular IoT power savings from HTTP/3’s 0-RTT connection resumption.

Sequence diagram comparing TCP+TLS connection setup requiring 2-3 RTTs versus QUIC 0-RTT resumption sending encrypted data immediately in first packet, showing significant latency reduction for cellular IoT devices.

QUIC 0-RTT Eliminates Connection Setup Latency
Figure 4.6: QUIC 0-RTT Eliminates Connection Setup Latency

Phoebe the physics guide

Phoebe’s Why

The calculator above turns radio-active seconds into joules, but the battery underneath is not a perfect voltage source: it is a real cell with an internal resistance, so its terminal voltage sags a little every time the radio draws current, and it self-discharges a little every month even while the radio sleeps. A milliamp-hour rating is charge, not energy – multiply by the cell voltage to get watt-hours – and neither the charge nor the voltage stays fixed over a year of shelf life and use. HTTP/3’s 0-RTT savings shrink the time the radio spends at 300 mA, but the depth of the sag on any single burst is set by the current and the cell’s internal resistance, not by which HTTP version triggered it.

The Derivation

Energy from charge and voltage:

\[E = V \times Q\]

Terminal voltage under load, internal resistance \(R_{int}\):

\[V_{term} = V_{oc} - I R_{int}\]

Heat dissipated inside the cell’s own resistance during an active burst of duration \(t\):

\[E_{R_{int}} = I^2 R_{int}\, t\]

Remaining charge after \(m\) months of self-discharge at monthly rate \(r\):

\[Q(m) = Q_0(1-r)^m\]

Worked Numbers: This Calculator’s Default Battery

  • Charge vs. energy, at the calculator’s defaults (\(V=3.7\) V, \(Q_0=2000\) mAh): \(E = 3.7\times2.000 = 7.40\) Wh – the mAh rating alone does not say this; the voltage has to be multiplied in.
  • Voltage sag during a 300 mA burst: with a catalog-typical fresh Li-ion internal resistance \(R_{int}\approx80\ \mathrm{m}\Omega\), \(\Delta V = 0.300\times0.080 = 24.0\) mV, terminal \(\approx3.68\) V – small for a fresh cell, but this sag (not the J/day figure above, which assumes a constant supply voltage) is what actually shortens run time as the cell ages and \(R_{int}\) climbs.
  • Where the sag heat sits inside this chapter’s own numbers: HTTP/1.1’s 33.6 s/day of 300 mA active time dissipates \(I^2R_{int}t = 0.3^2\times0.080\times33.6 = 0.242\) J/day inside the cell itself; HTTP/3’s 9.6 s/day dissipates \(0.3^2\times0.080\times9.6 = 0.0691\) J/day. The \(0.173\) J/day difference is internal-resistance heat saved on top of (not double-counting) the \(37.3-10.7=26.6\) J/day the calculator already reports.
  • Self-discharge and derating: at a catalog-typical Li-ion rate \(r\approx2\%\)/month, a year of shelf and field time leaves \(2000\times0.98^{12}=1570\) mAh from self-discharge alone – a 431 mAh (21.5%) loss before the radio has sent a single request, which is why a multi-year deployment budget should plan against a derated capacity, not the full 2000 mAh nameplate the slider shows.

4.5.3 Handling Packet Loss Gracefully

HTTP/2 (TCP): Sensor telemetry + firmware chunk in same connection
- Firmware packet lost -> ALL streams blocked waiting for retransmit
- Telemetry delayed by firmware recovery (100-500ms)

HTTP/3 (QUIC): Independent stream handling
- Firmware packet lost -> only firmware stream waits
- Telemetry continues unaffected
- Critical for real-time + bulk data mixing

Comparison diagram showing HTTP/2 TCP head-of-line blocking where all streams wait when one packet is lost, versus HTTP/3 QUIC where independent streams continue unaffected by losses in other streams.

HTTP/3 Eliminates Head-of-Line Blocking
Figure 4.7: HTTP/3 Eliminates Head-of-Line Blocking

Broker BexCheckpoint: mobile HTTP/3

You now know:

  • QUIC 0-RTT lets resumed HTTP/3 sessions send encrypted data immediately instead of waiting through the TCP and TLS setup path.
  • With 96 wakes per day, 100ms RTT, 300mA radio draw, and 3.7V supply, the chapter’s arithmetic reduces connection overhead from 37.3J/day to 10.7J/day.
  • Independent QUIC streams keep telemetry moving when a firmware stream waits for retransmission.

Those savings are compelling only when the device, network, and firewall can actually support HTTP/3, so selection comes before implementation.

4.6 Protocol Selection Guide

The following decision flowchart helps you select the appropriate HTTP version (or alternative protocol) based on your IoT device constraints and network environment.

Flowchart showing protocol selection process: Start with RAM check - if less than 32KB use CoAP/MQTT, if 32KB+ check if HTTP infrastructure exists. If yes, check network stability - stable networks use HTTP/2, unstable/cellular use HTTP/3. If UDP blocked, fall back to HTTP/2.

HTTP Protocol Selection Decision Tree for IoT Applications
Figure 4.8: HTTP Protocol Selection Decision Tree for IoT Applications

4.6.1 When to Use HTTP/2

Choose HTTP/2 when:

  • IoT gateway aggregating many device messages to cloud
  • Existing HTTP/REST infrastructure must be preserved
  • Devices have sufficient memory (32KB+ RAM for TLS+HTTP/2 stack)
  • Connection reuse is possible (persistent connection to backend)
  • Example: Smart building gateway sending HVAC data to cloud API

4.6.2 When to Use HTTP/3

Choose HTTP/3 when:

  • Cellular IoT with frequent sleep/wake cycles
  • Mobile assets changing networks (vehicles, drones, wearables)
  • Lossy wireless links (satellite, rural cellular)
  • Mixing real-time telemetry with bulk transfers
  • Example: Fleet tracking devices on LTE/5G

4.6.3 When to Avoid HTTP/2/3

Avoid HTTP/2/3 when:

  • Extremely constrained devices (<16KB RAM)
  • Simple request-response suffices (use CoAP instead)
  • UDP is blocked by network (enterprise firewalls)
  • Battery sensors with infrequent transmissions (MQTT over TCP simpler)
Interactive Tool: Protocol Selection Advisor

Answer a few questions about your IoT deployment to get a protocol recommendation.

Protocol Selection Summary

The flowchart above (Figure 4.8) guides you through selecting the appropriate HTTP version based on:

  1. Device RAM constraints - Determines if HTTP is feasible
  2. Infrastructure requirements - Whether existing HTTP/REST APIs must be used
  3. Network stability - Stable vs. cellular/mobile networks
  4. UDP availability - Some networks block UDP (required for HTTP/3)

Broker BexCheckpoint: selection constraints

You now know:

  • Under 32KB RAM, the practical answer is usually CoAP or MQTT rather than modern HTTP.
  • 32-128KB RAM fits HTTP/2 gateway scenarios; over 128KB opens room for HTTP/3 when mobile or lossy links justify it.
  • UDP blocking turns an otherwise attractive HTTP/3 design back into an HTTP/2-over-TCP deployment.

Once the protocol choice is defensible, implementation work shifts from diagrams to libraries, server limits, and connection reuse.

4.7 Implementation Considerations

4.7.1 Library Support (as of 2026)

Platform HTTP/2 HTTP/3 Notes
ESP32 (ESP-IDF) Partial (nghttp2) Limited Memory-constrained
Linux/Raspberry Pi Full (libcurl, nghttp2) Full (quiche, ngtcp2) Recommended platform
Azure IoT SDK Yes Preview Cloud-native support
AWS IoT Yes (MQTT over WebSocket/HTTP/2) Roadmap Prefer MQTT
Nordic nRF9160 Limited No Focus on LwM2M/CoAP

4.7.2 Memory Requirements

HTTP/1.1 minimal: ~8KB RAM (no TLS)
HTTP/2 minimal: ~32KB RAM (HPACK tables + stream state)
HTTP/3 minimal: ~64KB RAM (QUIC connection + crypto state)

Recommendation:
- <32KB RAM: Use CoAP or MQTT over TCP
- 32-128KB: HTTP/2 feasible for gateway scenarios
- >128KB: HTTP/3 viable for advanced applications

4.7.3 Server Configuration

# nginx HTTP/2 config for IoT backend
http2_max_concurrent_streams 128;  # Many IoT clients
http2_recv_buffer_size 256k;       # Handle burst uploads
keepalive_timeout 3600s;           # Long-lived IoT connections
ssl_protocols TLSv1.3;             # Require TLS 1.3 for IoT security

# QUIC/HTTP/3 (nginx 1.25+)
listen 443 quic reuseport;
http3 on;
quic_retry on;                     # Mitigate amplification attacks

4.7.4 Real-World Case Study: Fleet Tracking System

The following diagram illustrates a real-world fleet tracking architecture using HTTP/3 for mobile assets:

Architecture diagram showing fleet vehicles using HTTP/3 over cellular network to connect to cloud backend. HTTP/3 features highlighted include connection migration when switching cell towers, 0-RTT for fast wake-up, and independent streams for telemetry and commands.

Real-World Case Study: Fleet Tracking with HTTP/3
Figure 4.9: Real-World Case Study: Fleet Tracking with HTTP/3

Key Benefits Demonstrated:

  • Connection Migration: Trucks seamlessly switch between cell towers without dropping connection
  • 0-RTT Resumption: Vehicles waking from sleep send GPS data immediately
  • Independent Streams: Real-time telemetry and firmware updates don’t interfere with each other

4.7.5 Python HTTP/2 Gateway Example

# Python example: HTTP/2 with connection reuse for gateway
import httpx
import asyncio

# Create reusable HTTP/2 client
client = httpx.Client(
    http2=True,
    timeout=30.0,
    limits=httpx.Limits(
        max_keepalive_connections=5,
        max_connections=10,
        keepalive_expiry=3600  # 1 hour for IoT
    )
)

# Batch sensor readings efficiently
async def upload_sensor_batch(readings: list[dict]):
    """Upload multiple sensor readings in parallel over single HTTP/2 connection"""
    async with httpx.AsyncClient(http2=True) as client:
        tasks = [
            client.post(f"/api/v1/sensors/{r['device_id']}/data", json=r)
            for r in readings
        ]
        responses = await asyncio.gather(*tasks)
        # All 50 requests share single connection, multiplexed
        return responses

Broker BexCheckpoint: implementation contract

You now know:

  • A production HTTP/2 gateway needs a reusable client session, bounded connection pools, and long-lived keep-alive rather than one request per connection.
  • Server settings such as http2_max_concurrent_streams 128, http2_recv_buffer_size 256k, and keepalive_timeout 3600s make the gateway pattern explicit.
  • Fleet tracking is the case where HTTP/3 features such as connection migration, 0-RTT resumption, and independent streams are easiest to justify.

With implementation knobs named, the comparison tables below put modern HTTP back into the wider IoT protocol landscape.

4.8 Protocol Comparison Summary

Protocol Best For Overhead Latency Reliability
CoAP Constrained devices, 6LoWPAN Very Low Lowest Application-managed
MQTT Event streams, pub-sub Low Low QoS 0/1/2
HTTP/1.1 Simple prototyping, debugging High Medium TCP
HTTP/2 Gateways, cloud APIs, bulk uploads Medium Medium TCP + multiplexing
HTTP/3 Mobile IoT, unreliable networks Medium Lowest QUIC streams

4.8.1 Protocol Positioning in the IoT Landscape

The following diagram shows how HTTP/2 and HTTP/3 fit into the broader IoT protocol ecosystem:

Diagram showing IoT protocol positioning across device capability spectrum. Left side shows constrained devices using CoAP and MQTT-SN, middle shows gateway devices using MQTT and HTTP/2, right side shows mobile and cloud devices using HTTP/2 and HTTP/3. Arrows show typical data flow from sensors through gateways to cloud.

HTTP/2 and HTTP/3 in the IoT Protocol Landscape
Figure 4.10: HTTP/2 and HTTP/3 in the IoT Protocol Landscape

The following timeline shows how HTTP has evolved to address IoT requirements:

Timeline diagram showing HTTP evolution from HTTP/1.1 (1997) with text-based protocol and sequential requests, to HTTP/2 (2015) with binary framing and multiplexing, to HTTP/3 (2022) with QUIC transport and 0-RTT resumption. Each version shows improved IoT suitability.

Evolution of HTTP Protocols and IoT Suitability
Figure 4.11: Evolution of HTTP Protocols and IoT Suitability

Quadrant chart positioning IoT protocols by overhead (low to high) and feature richness (basic to advanced). CoAP in low overhead basic quadrant, MQTT in low overhead advanced, HTTP/1.1 in high overhead basic, HTTP/2 and HTTP/3 in high overhead advanced quadrant.

Protocol Positioning by Overhead and Feature Richness
Figure 4.12: Protocol Positioning by Overhead and Feature Richness

4.9 Real-World Tradeoffs

When selecting between HTTP versions in production IoT deployments, consider these practical tradeoffs:

Radar chart comparison showing HTTP/2 and HTTP/3 tradeoffs across six dimensions: Library Support, Memory Efficiency, Firewall Compatibility, Mobile Performance, Latency Reduction, and Deployment Complexity. HTTP/2 scores higher on support and compatibility, HTTP/3 scores higher on mobile and latency.

HTTP/2 vs HTTP/3 Tradeoff Analysis for IoT
Figure 4.13: HTTP/2 vs HTTP/3 Tradeoff Analysis for IoT

4.9.1 Quantitative Comparison

Metric HTTP/2 HTTP/3 Winner For
Connection Setup 2-3 RTT (TCP+TLS) 0-1 RTT (QUIC) HTTP/3: Mobile IoT
Memory Footprint ~32KB ~64KB HTTP/2: Constrained gateways
Packet Loss Impact All streams blocked Independent streams HTTP/3: Lossy networks
Network Handoff Connection drops Survives IP change HTTP/3: Vehicle tracking
Firewall Traversal ~99% success ~85% success HTTP/2: Enterprise
Library Maturity Excellent Good (improving) HTTP/2: Production systems
Debug Tooling Mature (Chrome, curl) Developing HTTP/2: Development phase
Deployment Strategy

Start with HTTP/2 for initial deployments - it offers significant improvements over HTTP/1.1 with excellent tooling and support. Upgrade to HTTP/3 when you have proven the value proposition and your mobile/cellular use cases justify the added complexity.

Broker BexCheckpoint: deployment tradeoffs

You now know:

  • HTTP/2 wins when tooling, firewall traversal, and the roughly 32KB memory footprint matter more than mobile handoff.
  • HTTP/3 wins when 0-1 RTT setup, independent streams, and connection migration offset its roughly 64KB memory cost.
  • A staged deployment starts with HTTP/2, then upgrades the mobile or lossy slice after measurements prove the complexity is worthwhile.

The final pitfalls section turns those tradeoffs into the mistakes to avoid during design review.

4.10 Common Pitfalls

Avoid These Mistakes

1. Assuming HTTP/3 is Always Better

HTTP/3’s QUIC transport offers significant advantages for mobile and lossy networks, but it’s not universally better:

  • UDP may be blocked by enterprise firewalls
  • HTTP/3 requires more RAM (~64KB vs ~32KB for HTTP/2)
  • Library support is still maturing on embedded platforms
  • For stable networks, HTTP/2 provides similar benefits with wider support

2. Ignoring Memory Constraints

Modern HTTP protocols have significant memory overhead:

  • HTTP/2 HPACK tables need ~16-32KB RAM
  • HTTP/3 QUIC state needs ~64KB RAM
  • Don’t assume gateway-level protocols work on constrained sensors
  • Always verify RAM budget before selecting protocol

3. Opening Multiple HTTP/2 Connections

The whole point of HTTP/2 multiplexing is to use a SINGLE connection:

# WRONG: Creating new connection per request
for sensor in sensors:
    response = httpx.post(url, json=sensor.data)  # New connection each time!

# RIGHT: Reusing single multiplexed connection
async with httpx.AsyncClient(http2=True) as client:
    tasks = [client.post(url, json=s.data) for s in sensors]
    responses = await asyncio.gather(*tasks)  # All share one connection

4. Not Configuring Keep-Alive for IoT

Default HTTP timeouts are too short for IoT:

# nginx - extend for IoT workloads
keepalive_timeout 3600s;  # 1 hour, not default 75s
http2_idle_timeout 600s;  # 10 minutes idle before close

5. Forgetting 0-RTT Replay Attacks

HTTP/3’s 0-RTT is vulnerable to replay attacks. For idempotent operations (GET, sensor readings) this is fine, but for non-idempotent operations (commands, actuator triggers), use 1-RTT or implement replay protection.

4.11 Knowledge Check

Test your understanding of Modern HTTP for IoT applications:

Matching Quiz: HTTP/2 and HTTP/3 Concepts

Match each HTTP/2 or HTTP/3 concept to its correct definition or IoT benefit.

🧠 Knowledge Check
🏷️ Label the Diagram

📝 Order the Steps

4.12 Deep Dive: One Connection, Many Streams, No Head-of-Line Block

The calculators above quantify the savings. This layered walkthrough names the single mechanism those numbers come from: each HTTP version is another round in the fight against head-of-line blocking, and HTTP/2’s HPACK and HTTP/3’s QUIC are the specific tools that win it.

HTTP/1.1, HTTP/2, and HTTP/3 can be read as three attempts to reduce head-of-line blocking. HTTP/1.1 keep-alive reuses the TCP connection, but a connection still serves one request at a time, so a slow response blocks requests queued behind it. HTTP/2 fixes that HTTP-layer queue by multiplexing many streams over one TCP connection and shrinking repeated headers with HPACK. The remaining problem is underneath HTTP/2: TCP delivers bytes in strict order, so one lost segment stalls every HTTP/2 stream until retransmission. HTTP/3 moves to QUIC over UDP, where streams are independent and a lost packet stalls only the affected stream.

Version What improves Remaining constraint
HTTP/1.1 Keep-alive avoids repeated connection setup One active request per connection creates HTTP-layer queueing
HTTP/2 Multiplexed streams and HPACK reduce connection and header overhead TCP packet loss blocks all streams on the connection
HTTP/3 QUIC streams, 0-RTT resumption, and connection migration help lossy mobile links Higher memory cost, UDP blocking, and newer tooling

HPACK is the HTTP/2 header-compression mechanism behind much of the gateway benefit. A gateway posting readings sends almost identical headers every request: host, authorization, user-agent, and content-type. HPACK uses a static table for common fields and a per-connection dynamic table for repeated values. The first request sends literal values and inserts them into the dynamic table; later requests reference those fields by index, often shrinking hundreds of header bytes to a few bytes. Short idle timeouts erase that dynamic table, so session reuse and header compression must be tuned together.

HTTP/3 uses QPACK rather than HPACK because QUIC streams can arrive out of order. QPACK keeps the same goal, compact repeated header fields, but avoids letting one blocked header reference stall unrelated streams. That distinction matters when telemetry, commands, and firmware chunks share one connection on a lossy link.

4.12.1 QUIC Streams and Connection Migration

QUIC folds reliable delivery, independent streams, TLS 1.3 encryption, and a connection identity into one transport. The connection identity is a QUIC Connection ID, not the client’s current IP address and port. That is why an HTTP/3 vehicle tracker can move from Wi-Fi to LTE without forcing application work to restart, while HTTP/2 over TCP normally loses the connection when the IP/port tuple changes.

graph LR
  C["HTTP/3 client"] --> Q["Single QUIC connection<br/>(one Connection ID)"]
  Q --> S1["Stream 1: telemetry"]
  Q --> S2["Stream 2: firmware chunk"]
  Q --> S3["Stream 3: commands"]
  S1 --> D["Delivered independently"]
  S3 --> D
  S2 --> L["Lost packet: only Stream 2 waits"]

Be honest about the cost. QUIC does per-packet crypto in user space, uses more memory than HTTP/2, and depends on UDP being allowed end to end. On a stable managed Ethernet or Wi-Fi link, HTTP/2 can be the pragmatic choice. On a moving cellular asset where packet loss and address changes are normal, HTTP/3 earns its complexity if the device and network can support it.

Test the claim before standardizing on HTTP/3: start an upload on Wi-Fi, roam to cellular mid-stream, and verify that the same logical request survives under one QUIC Connection ID without restarting application work.

4.13 Summary and Key Takeaways

What You Learned

This chapter covered the evolution of HTTP protocols and their applicability to IoT scenarios:

HTTP/2 Benefits:

  • Multiplexing enables 50x faster gateway scenarios by sending all requests over a single TCP connection
  • HPACK compression reduces header overhead by 90%, critical for chatty IoT applications
  • Server push enables efficient firmware distribution without client polling
  • Single TCP connection reduces TLS handshake overhead for persistent connections

HTTP/3 Benefits:

  • 0-RTT resumption: 30-50% power savings for cellular IoT devices waking from sleep
  • Independent streams: No head-of-line blocking - packet loss in one stream doesn’t affect others
  • Connection migration: Survives network handoff (cell tower switches) for mobile assets
  • Per-stream congestion control: Enables mixed priority data handling (telemetry + firmware)

Protocol Selection Decision Tree:

Device RAM Network Type Recommended Protocol
< 32KB Any CoAP or MQTT
32-128KB Stable (Wi-Fi/Ethernet) HTTP/2
32-128KB Mobile/Cellular HTTP/2 (due to RAM)
> 128KB Stable HTTP/2
> 128KB Mobile/Cellular HTTP/3
Any UDP Blocked HTTP/2 (fallback)

Key Insight: HTTP/2 and HTTP/3 don’t replace MQTT or CoAP for constrained IoT devices, but they significantly improve HTTP performance for gateways, cloud integration, and mobile IoT scenarios where HTTP infrastructure already exists.

Summary diagram showing three IoT scenarios and recommended HTTP versions. Left: Smart building gateway with HTTP/2 for stable connection multiplexing. Center: Fleet tracking with HTTP/3 for mobile connectivity. Right: Constrained sensor using CoAP/MQTT instead of HTTP.

Summary: When to Use Modern HTTP Protocols
Figure 4.14: Summary: When to Use Modern HTTP Protocols

Lab Exercise Ideas:

  1. HTTP/2 Multiplexing Demo: Use curl --http2 with timing to compare 10 sequential vs. parallel requests
  2. Header Compression Measurement: Capture HTTP/1.1 vs HTTP/2 traffic with Wireshark to measure header size reduction
  3. 0-RTT Latency Test: Configure a QUIC server and measure first-request latency for new vs. resumed connections

Discussion Questions:

  • Why might an enterprise prefer HTTP/2 over HTTP/3 even when UDP is available?
  • How does QUIC’s connection migration feature change the design of mobile IoT applications?
  • What are the security implications of 0-RTT early data?

Common Student Misconceptions:

  • “HTTP/3 is always faster” - Not true; on stable networks with low loss, HTTP/2 performs similarly
  • “HTTP/2 needs multiple connections” - The whole point is single connection with multiplexing
  • “Modern HTTP works on any device” - Memory constraints often make it impractical for constrained sensors

Concept Relationships

Understanding HTTP/2 and HTTP/3 connects to several other protocol and networking concepts:

Foundation Concepts:

Alternative Protocols:

  • MQTT Fundamentals - Compare pub-sub vs HTTP request-response
  • CoAP Overview - Lightweight alternative for constrained devices
  • WebSocket Fundamentals - Bidirectional alternative to HTTP

Related Technologies:

  • TLS/SSL Security - Encryption layer for HTTPS
  • CDN Architecture - HTTP/3 benefits for edge delivery
  • Mobile IoT - HTTP/3’s 0-RTT for cellular devices

Prerequisites You Should Know:

  • TCP three-way handshake and why it adds latency
  • TLS handshake process (2-3 RTT overhead)
  • Difference between connection-oriented (TCP) and connectionless (UDP) protocols

What This Enables:

  • Gateway design with multiplexed connections reducing connection count from 500 to 1
  • Mobile IoT optimization with 30-50% battery savings via 0-RTT connection resumption
  • Protocol selection for different deployment scenarios (stable vs mobile networks)

See Also

Core HTTP Concepts:

Alternative Protocols:

Implementation Guides:

  • Protocol Selection Guide - When to use each protocol
  • Gateway Design Patterns - HTTP/2 for gateway scenarios
  • Mobile IoT Optimization - HTTP/3 battery benefits

Specifications:

Try It Yourself

Experiment 1: HTTP/2 Multiplexing Benchmark

Compare HTTP/1.1 sequential requests versus HTTP/2 parallel streams:

# Install httpx: pip install httpx
import httpx
import time

# HTTP/1.1 sequential
start = time.time()
with httpx.Client() as client:
    for i in range(50):
        client.get("https://httpbin.org/delay/0.1")
http1_time = time.time() - start

# HTTP/2 parallel
start = time.time()
with httpx.Client(http2=True) as client:
    import asyncio
    async def fetch_all():
        async with httpx.AsyncClient(http2=True) as async_client:
            tasks = [async_client.get("https://httpbin.org/delay/0.1") for _ in range(50)]
            await asyncio.gather(*tasks)
    asyncio.run(fetch_all())
http2_time = time.time() - start

print(f"HTTP/1.1: {http1_time:.2f}s")
print(f"HTTP/2: {http2_time:.2f}s")
print(f"Speedup: {http1_time/http2_time:.1f}x")

What to Observe:

  • HTTP/2 should be 10-50x faster for 50 parallel requests
  • Single TCP connection vs 6-8 parallel connections in HTTP/1.1
  • Lower latency variance with HTTP/2 multiplexing

Experiment 2: HPACK Header Compression

Measure header compression savings:

import httpx

# Capture traffic with Wireshark filtering "http2"
client = httpx.Client(http2=True)

# First request - headers sent in full
r1 = client.get("https://httpbin.org/headers",
                headers={"User-Agent": "IoTDevice/1.0",
                         "Authorization": "Bearer token123..."})

# Subsequent requests - headers compressed via HPACK
for i in range(10):
    r = client.get("https://httpbin.org/headers",
                   headers={"User-Agent": "IoTDevice/1.0",
                            "Authorization": "Bearer token123..."})

What to Observe:

  • First request: full headers (~350 bytes)
  • Subsequent requests: compressed to ~15-30 bytes (90%+ reduction)
  • Total bandwidth savings over 100 requests

Experiment 3: HTTP/3 vs HTTP/2 Latency

Compare connection establishment latency:

# HTTP/2 over TCP
time curl -I --http2 https://cloudflare-quic.com

# HTTP/3 over QUIC (requires curl 7.66+)
time curl -I --http3 https://cloudflare-quic.com

What to Observe:

  • HTTP/2: 2-3 RTT connection setup (TCP + TLS)
  • HTTP/3: 0-1 RTT with QUIC
  • Connection resumption: 0-RTT for HTTP/3

Challenge: Gateway Data Aggregation

Build an IoT gateway that collects from 20 simulated sensors and uploads to a cloud API:

import httpx
import asyncio
import time

async def simulate_sensor(sensor_id):
    """Simulate sensor reading"""
    await asyncio.sleep(0.1)
    return {"sensor_id": sensor_id, "value": 23.5}

async def gateway_http1():
    """HTTP/1.1 approach - sequential uploads"""
    readings = await asyncio.gather(*[simulate_sensor(i) for i in range(20)])
    with httpx.Client() as client:
        for reading in readings:
            client.post("https://httpbin.org/post", json=reading)

async def gateway_http2():
    """HTTP/2 approach - parallel multiplexed uploads"""
    readings = await asyncio.gather(*[simulate_sensor(i) for i in range(20)])
    async with httpx.AsyncClient(http2=True) as client:
        tasks = [client.post("https://httpbin.org/post", json=r) for r in readings]
        await asyncio.gather(*tasks)

# Measure and compare

Expected Results:

  • HTTP/1.1: ~2-3 seconds (sequential uploads)
  • HTTP/2: ~200-300ms (parallel over single connection)
  • 10x throughput improvement for gateway scenario

4.14 What’s Next?

Chapter Focus Why Read It
IoT API Design Best Practices REST API design, payload formats, versioning, security Apply HTTP/2 efficiently with well-structured REST APIs and consistent topic naming
HTTP Connection Pitfalls Common HTTP mistakes in IoT Understand the problems that HTTP/2 and HTTP/3 were designed to solve
CoAP Overview Constrained Application Protocol for low-power devices Compare HTTP/2/3 against CoAP to select the right protocol for constrained sensors
MQTT Fundamentals Pub-sub messaging for IoT Evaluate when MQTT’s lightweight broker model outperforms HTTP-based approaches
Cellular IoT Fundamentals LTE-M, NB-IoT, 5G connectivity Pair HTTP/3’s 0-RTT battery savings with the right cellular radio technology
Application Protocols Overview Complete module navigation and protocol comparison framework Situate HTTP/2 and HTTP/3 within the broader IoT protocol landscape