7  HTTP/2 and HTTP/3 for IoT

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.

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

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

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

7.4 HTTP/2: Multiplexing and Header Compression

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

7.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 7.2: HTTP/1.1 Sequential Requests vs HTTP/2 Multiplexed Streams

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

7.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 7.3: HTTP/2 Gateway Scenario: Parallel Sensor Data Upload

7.5 HTTP/3: QUIC Transport for Unreliable Networks

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

7.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 7.4: HTTP/3 QUIC Features Mapped to IoT Benefits

7.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 7.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 7.6: QUIC 0-RTT Eliminates Connection Setup Latency

7.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 7.7: HTTP/3 Eliminates Head-of-Line Blocking

7.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 7.8: HTTP Protocol Selection Decision Tree for IoT Applications

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

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

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

7.7 Implementation Considerations

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

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

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

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

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

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

7.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 7.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 7.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 7.12: Protocol Positioning by Overhead and Feature Richness

7.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 7.13: HTTP/2 vs HTTP/3 Tradeoff Analysis for IoT

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

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

7.11 Knowledge Check

Test your understanding of HTTP/2 and HTTP/3 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.

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

7.13 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 Pitfalls and Connection Management 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