1180  HTTP/2 and HTTP/3 for IoT Applications

1180.1 Learning Objectives

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

• Understand HTTP/2 Benefits: Explain multiplexing, header compression, and server push for IoT
• Evaluate HTTP/3 Advantages: Analyze QUIC transport benefits for mobile and cellular IoT
• Select Appropriate Protocol: Choose between HTTP/1.1, HTTP/2, and HTTP/3 based on device constraints
• Implement Modern HTTP: Configure HTTP/2 and HTTP/3 for IoT gateways and cloud backends
• Optimize Performance: Apply best practices for connection reuse and resource management

1180.2 Prerequisites

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

• HTTP Pitfalls and Connection Management: Common HTTP mistakes in IoT
• Application Protocols Overview: Basic understanding of IoT application protocols

---

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

TipFor Beginners: Why Modern HTTP Matters

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

---

1180.4 HTTP/2: Multiplexing and Header Compression

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

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

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1'}}}%%
graph LR
    subgraph HTTP1["HTTP/1.1"]
        C1["Client"] --> |"Request 1"| S1["Server"]
        S1 --> |"Response 1"| C1
        C1 --> |"Request 2"| S1
        S1 --> |"Response 2"| C1
        C1 --> |"Request 3"| S1
        S1 --> |"Response 3"| C1
    end

    subgraph HTTP2["HTTP/2"]
        C2["Client"] --> |"Stream 1, 2, 3<br/>Multiplexed"| S2["Server"]
        S2 --> |"Responses<br/>Interleaved"| C2
    end

    style C1 fill:#E67E22,stroke:#D35400,color:#fff
    style S1 fill:#E67E22,stroke:#D35400,color:#fff
    style C2 fill:#16A085,stroke:#16A085,color:#fff
    style S2 fill:#16A085,stroke:#16A085,color:#fff

Figure 1180.1: HTTP/1.1 sequential requests vs HTTP/2 multiplexed streams

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

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

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1'}}}%%
sequenceDiagram
    participant G as IoT Gateway
    participant C as Cloud Server

    Note over G,C: HTTP/2: Single Connection, 50 Streams

    G->>+C: TCP + TLS Handshake (once)

    rect rgb(200, 255, 200)
        par Stream Multiplexing
            G->>C: Stream 1: Sensor A data
            G->>C: Stream 2: Sensor B data
            G->>C: Stream 3: Sensor C data
            Note right of C: ... Streams 4-50 ...
        end
        par Response Interleaving
            C-->>G: Stream 1 ACK
            C-->>G: Stream 3 ACK
            C-->>G: Stream 2 ACK
        end
    end

    Note over G,C: All 50 sensors in ~200ms

Figure 1180.2: HTTP/2 multiplexing enables parallel sensor data upload over single connection

---

1180.5 HTTP/3: QUIC Transport for Unreliable Networks

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

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

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1'}}}%%
graph TB
    subgraph QUIC["HTTP/3 (QUIC) Advantages"]
        Z["0-RTT Resumption<br/>Instant reconnect"]
        I["Independent Streams<br/>No head-of-line blocking"]
        M["Connection Migration<br/>Survives IP changes"]
        C["Per-Stream Congestion<br/>Priority handling"]
    end

    subgraph IoT["IoT Benefits"]
        B["Battery Savings<br/>30-50% radio time reduction"]
        R["Reliability<br/>Lossy link tolerance"]
        V["Vehicle Telematics<br/>Network handoff"]
        P["Mixed Traffic<br/>Telemetry + firmware"]
    end

    Z --> B
    I --> R
    M --> V
    C --> P

    style Z fill:#16A085,stroke:#16A085,color:#fff
    style I fill:#16A085,stroke:#16A085,color:#fff
    style M fill:#16A085,stroke:#16A085,color:#fff
    style C fill:#16A085,stroke:#16A085,color:#fff

Figure 1180.3: HTTP/3 QUIC features mapped to IoT benefits

1180.5.2 0-RTT Connection Resumption

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

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1'}}}%%
sequenceDiagram
    participant D as IoT Device
    participant S as Server

    Note over D,S: TCP + TLS 1.3 (2 RTT)
    rect rgb(255, 220, 200)
        D->>S: TCP SYN
        S->>D: TCP SYN-ACK
        D->>S: TLS ClientHello
        S->>D: TLS ServerHello + Certificate
        D->>S: Application Data
    end

    Note over D,S: QUIC 0-RTT (Resumed)
    rect rgb(200, 255, 200)
        D->>S: ClientHello + Encrypted Data
        S->>D: Response
        Note over D: 30-50% power savings
    end

Figure 1180.4: QUIC 0-RTT eliminates connection setup latency for cellular IoT

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

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1'}}}%%
graph TB
    subgraph TCP["HTTP/2 (TCP) - Head-of-Line Blocking"]
        direction LR
        T1["Telemetry"] --> Q1["Queue"]
        F1["Firmware"] --> Q1
        Q1 --> |"Blocked by<br/>lost packet"| X1["X"]
    end

    subgraph QUIC["HTTP/3 (QUIC) - Independent Streams"]
        direction LR
        T2["Telemetry"] --> S2["Stream 1"]
        F2["Firmware"] --> S3["Stream 2"]
        S2 --> |"Continues"| OK2["OK"]
        S3 --> |"Waits for<br/>retransmit"| W2["Wait"]
    end

    style X1 fill:#E74C3C,stroke:#C0392B,color:#fff
    style OK2 fill:#27AE60,stroke:#1E8449,color:#fff
    style W2 fill:#F39C12,stroke:#D68910,color:#fff

Figure 1180.5: HTTP/3 eliminates head-of-line blocking between streams

---

1180.6 Protocol Selection Guide

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

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

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

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1'}}}%%
flowchart TD
    Start["IoT Protocol Selection"] --> RAM{"Device RAM?"}

    RAM -->|"< 16KB"| CoAP["Use CoAP/MQTT"]
    RAM -->|"16-32KB"| HTTP1["HTTP/1.1 + Keep-Alive"]
    RAM -->|"32-128KB"| RAM2{"Mobile/Cellular?"}
    RAM -->|"> 128KB"| RAM3{"Network Type?"}

    RAM2 -->|"Yes"| H3["HTTP/3 (QUIC)"]
    RAM2 -->|"No"| H2["HTTP/2"]

    RAM3 -->|"Lossy/Mobile"| H3
    RAM3 -->|"Stable"| H2

    style CoAP fill:#16A085,stroke:#16A085,color:#fff
    style HTTP1 fill:#3498db,stroke:#2980b9,color:#fff
    style H2 fill:#E67E22,stroke:#D35400,color:#fff
    style H3 fill:#2C3E50,stroke:#1a252f,color:#fff

Figure 1180.6: Protocol selection flowchart based on device constraints and network type

---

1180.7 Implementation Considerations

1180.7.1 Library Support (as of 2025)

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

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

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

1180.7.4 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

---

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

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1'}}}%%
quadrantChart
    title Protocol Selection by Overhead vs Capability
    x-axis Low Overhead --> High Overhead
    y-axis Basic Features --> Advanced Features

    quadrant-1 Full-Featured, Heavy
    quadrant-2 Optimal Balance
    quadrant-3 Constrained Devices
    quadrant-4 Limited Capability

    CoAP: [0.2, 0.3]
    MQTT: [0.3, 0.5]
    HTTP/1.1: [0.8, 0.4]
    HTTP/2: [0.6, 0.7]
    HTTP/3: [0.5, 0.85]

Figure 1180.7: Protocol positioning by overhead and feature richness

---

1180.9 Key Takeaways

NoteSummary

HTTP/2 Benefits: - Multiplexing enables 50x faster gateway scenarios - HPACK compression reduces header overhead by 90% - Server push enables efficient firmware distribution - Single TCP connection reduces TLS handshake overhead

HTTP/3 Benefits: - 0-RTT resumption: 30-50% power savings for cellular IoT - Independent streams: No head-of-line blocking on lossy networks - Connection migration: Survives network handoff for mobile assets - Per-stream congestion control: Mixed priority data handling

Protocol Selection: - <32KB RAM: Use CoAP or MQTT - 32-128KB RAM + stable network: HTTP/2 - >128KB RAM + mobile/cellular: HTTP/3 - UDP blocked: Fall back to HTTP/2

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.

---

1180.10 What’s Next?

Continue to IoT API Design Best Practices for guidance on REST API design, topic naming conventions, payload formats, versioning, and security considerations.

Or return to the Application Protocols Overview for the complete module navigation.