6 Modern HTTP: Implementation and Deployment

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.

Figure 6.1: HTTP/1.1, HTTP/2, and HTTP/3 preserve HTTP application semantics while changing framing, transport, and loss boundaries underneath.

6.1 Start With the Situation

The team has selected a protocol from measured constraints, but the choice is only useful when libraries, memory, server settings, staged rollout, and recovery checks implement it faithfully.

6.2 Overview

This route turns a protocol selection into implementation settings, comparison evidence, deployment stages, and pitfall checks.

This is part 2 of 2. Review Modern HTTP: HTTP/2, HTTP/3, and Selection when you need the first route.

6.3 Learning Objectives

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

configure modern HTTP connection and gateway settings
validate library, memory, and server support for the selected protocol
plan a staged deployment with explicit trade-offs and recovery checks

6.4 Chapter Roadmap

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

6.5 Implementation Considerations

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

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

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

6.5.4 Real-World Case Study: Fleet Tracking System

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

Key Benefits Demonstrated:

Read these points as one connected sequence: start with Connection Migration: Trucks seamlessly switch between cell towers without dropping connection; then 0-RTT Resumption: Vehicles waking from sleep send GPS data immediately; and finish with Independent Streams: Real-time telemetry and firmware updates don’t interfere with each other.

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

6.5.5 Python HTTP/2 Gateway Example

Read the example in two passes. The long-lived httpx.Client enables HTTP/2 and caps keep-alive and total connections, establishing the reuse policy. Inside upload_sensor_batch, each client.post(...) becomes a task and asyncio.gather waits for all responses, allowing the requests to be multiplexed rather than sent serially. In production, keep the returned status and error evidence for every reading; concurrency improves transport use but does not prove that each upload was accepted.

# 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

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

6.6 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

6.6.1 Protocol Positioning in the IoT Landscape

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

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

6.7 Real-World Tradeoffs

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

Inspect Figure 6.2 to compare both the architecture and its dominant failure mode before reading the numeric table.

HTTP/2 over TCP versus HTTP/3 over QUIC architecture and failure-mode tradeoff: HTTP/2 is easier to deploy, HTTP/3 wins when roaming or packet loss dominates. — Figure 6.2: HTTP/2 vs HTTP/3 Tradeoff Analysis for IoT

Read Figure 6.2 from the protocol stacks into the network events. HTTP/2 multiplexes streams over one TLS-protected TCP connection and benefits from mature deployment paths, but a lost TCP segment can delay every stream behind that byte gap. HTTP/3 moves HTTP semantics onto QUIC, where streams recover independently and the connection can survive an address change, at the cost of a larger and sometimes less widely permitted stack. Those mechanisms explain the deployment metrics and staged strategy that follow.

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

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

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

6.9 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

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

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

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.

6.11 Summary and Key Takeaways

What You Learned

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

HTTP/2 Benefits:

Read these points as one connected sequence: start with Multiplexing enables 50x faster gateway scenarios by sending all requests over a single TCP connection; then HPACK compression reduces header overhead by 90%, critical for chatty IoT applications; then Server push enables efficient firmware distribution without client polling; and finish with Single TCP connection reduces TLS handshake overhead for persistent connections.

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:

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

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.

For Instructors: Teaching Suggestions

Lab Exercise Ideas:

Read these points as one connected sequence: start with HTTP/2 Multiplexing Demo: Use curl --http2 with timing to compare 10 sequential vs. parallel requests; then Header Compression Measurement: Capture HTTP/1.1 vs HTTP/2 traffic with Wireshark to measure header size reduction; and finish with 0-RTT Latency Test: Configure a QUIC server and measure first-request latency for new vs. resumed connections.

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

Discussion Questions:

Read these points as one connected sequence: start with Why might an enterprise prefer HTTP/2 over HTTP/3 even when UDP is available?; then How does QUIC’s connection migration feature change the design of mobile IoT applications?; and finish with What are the security implications of 0-RTT early data?.

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:

Read these points as one connected sequence: start with “HTTP/3 is always faster” - Not true; on stable networks with low loss, HTTP/2 performs similarly; then “HTTP/2 needs multiple connections” - The whole point is single connection with multiplexing; and finish with “Modern HTTP works on any device” - Memory constraints often make it impractical for constrained sensors.

“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:

Read these points as one connected sequence: start with HTTP Connection Pitfalls - Problems HTTP/2 and HTTP/3 solve; then Application Protocols Overview - Position in the protocol landscape; then TCP Fundamentals - HTTP/2’s transport layer; and finish with UDP Basics - HTTP/3’s QUIC transport.

HTTP Connection Pitfalls - Problems HTTP/2 and HTTP/3 solve
Application Protocols Overview - Position in the protocol landscape
TCP Fundamentals - HTTP/2’s transport layer
UDP Basics - HTTP/3’s QUIC transport

Alternative Protocols:

Read these points as one connected sequence: start with MQTT Fundamentals - Compare pub-sub vs HTTP request-response; then CoAP Overview - Lightweight alternative for constrained devices; and finish with WebSocket Fundamentals - Bidirectional alternative to HTTP.

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

Related Technologies:

Read these points as one connected sequence: start with TLS/SSL Security - Encryption layer for HTTPS; then CDN Architecture - HTTP/3 benefits for edge delivery; and finish with Mobile IoT - HTTP/3’s 0-RTT for cellular devices.

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:

Read these points as one connected sequence: start with TCP three-way handshake and why it adds latency; then TLS handshake process (2-3 RTT overhead); and finish with Difference between connection-oriented (TCP) and connectionless (UDP) protocols.

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:

Read these points as one connected sequence: start with Gateway design with multiplexed connections reducing connection count from 500 to 1; then Mobile IoT optimization with 30-50% battery savings via 0-RTT connection resumption; and finish with Protocol selection for different deployment scenarios (stable vs mobile networks).

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)

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:

Read these points as one connected sequence: start with HTTP/2 should be 10-50x faster for 50 parallel requests; then Single TCP connection vs 6-8 parallel connections in HTTP/1.1; and finish with Lower latency variance with HTTP/2 multiplexing.

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:

Read these points as one connected sequence: start with First request: full headers (~350 bytes); then Subsequent requests: compressed to ~15-30 bytes (90%+ reduction); and finish with Total bandwidth savings over 100 requests.

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:

Read these points as one connected sequence: start with HTTP/2: 2-3 RTT connection setup (TCP + TLS); then HTTP/3: 0-1 RTT with QUIC; and finish with Connection resumption: 0-RTT for HTTP/3.

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:

Read these points as one connected sequence: start with HTTP/1.1: ~2-3 seconds (sequential uploads); then HTTP/2: ~200-300 ms (parallel over single connection); and finish with 10x throughput improvement for gateway scenario.

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

6.12 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

6.1 Start With the Situation

6.2 Overview

6.3 Learning Objectives

6.4 Chapter Roadmap

6.5 Implementation Considerations

6.5.1 Library Support (as of 2026)

6.5.2 Memory Requirements

6.5.3 Server Configuration

6.5.4 Real-World Case Study: Fleet Tracking System

6.5.5 Python HTTP/2 Gateway Example

6.6 Protocol Comparison Summary

6.6.1 Protocol Positioning in the IoT Landscape

6.7 Real-World Tradeoffs

6.7.1 Quantitative Comparison

6.8 Common Pitfalls

6.9 Knowledge Check

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

6.10.1 QUIC Streams and Connection Migration

6.11 Summary and Key Takeaways

Concept Relationships

See Also

Try It Yourself

6.12 What’s Next?