5 Modern HTTP: HTTP/2, HTTP/3, and Selection

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 5.1: HTTP/1.1, HTTP/2, and HTTP/3 preserve HTTP application semantics while changing framing, transport, and loss boundaries underneath.

5.1 Overview

This first route compares HTTP/2 and HTTP/3 mechanics, calculates their consequences, and turns the evidence into a protocol selection.

This is part 1 of 2. Continue with Modern HTTP: Implementation and Deployment for the second focused route.

In 60 Seconds

Match the Web Link to the Device Job

A protocol is a set of rules for exchanging data. Telemetry is a time-linked record from a device. Hypertext Transfer Protocol (HTTP) is a request-and-response method. Transmission Control Protocol (TCP) is a delivery method that keeps an ordered byte stream. User Datagram Protocol (UDP) sends separate units without that built-in stream. Latency is the time data takes to arrive.

Constrained Application Protocol (CoAP) is a compact web-style method for small devices. Message Queuing Telemetry Transport (MQTT) is a lightweight publish-and-subscribe method. A gateway is a device or service that joins different system parts.

Picture fifty sensors reporting through one powered building computer. Test old and new web methods on the real link. Measure setup time, memory, bytes, loss recovery, and energy during a weak mobile signal. Restart both ends and check what repeats.

A newer version is not always a better fit. Small endpoints may lack memory or library support, while a powered bridge may gain from shared links. The deeper sections compare the versions and alternatives so each choice has a measured path, clear limit, and fallback.

Start with one real flow. Send the same useful data over each candidate. Keep the network, device, load, and test time the same. This makes the trade clear before the team adds more features. 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, 100 ms 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.

5.2 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

5.3 Prerequisites

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

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

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:

Read these points as one connected sequence: start with Video Library: Watch tutorials on HTTP/2 and QUIC protocol implementations; then Interactive Simulations: Try the Protocol Comparison Tool and Latency Calculator; then Knowledge Gaps: Learn about common protocol selection mistakes; and finish with Self-Assessment Quizzes: Test your understanding of application protocols.

Video Library: Watch tutorials on HTTP/2 and QUIC protocol implementations
Interactive Simulations: Try the Protocol Comparison Tool and Latency Calculator
Knowledge Gaps: Learn about common protocol selection mistakes
Self-Assessment Quizzes: Test your understanding of application protocols

Cross-Reference with Other Topics:

Read these points as one connected sequence: start with See CoAP Overview for constrained device alternatives; then Review MQTT Fundamentals for pub-sub messaging patterns; and finish with Explore Cellular IoT Fundamentals for mobile IoT connectivity.

See CoAP Overview for constrained device alternatives
Review MQTT Fundamentals for pub-sub messaging patterns
Explore Cellular IoT Fundamentals for mobile IoT connectivity

Concurrent Data Transfers with HTTP/2 and HTTP/3

Meet the Sensor Squad! Temperature Terry 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!”

Light Lucy 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

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

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

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

For 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

5.5 HTTP/2: Multiplexing and Header Compression

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

5.5.1 Key Improvements Over HTTP/1.1

To understand why HTTP/2 changes gateway behavior, inspect Figure 5.2 after the feature table. Look first at the number of transport connections, then at how application streams share them, and finally at what TCP ordering still means.

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

Side-by-side comparison. HTTP/1.1 uses three TCP and TLS connection rails with repeated setup. HTTP/2 interleaves telemetry, configuration, and firmware frames as independent streams within one TCP and TLS connection. A note preserves the fact that TCP still carries each direction in byte order. — Figure 5.2: HTTP/2 multiplexes independent application streams over one secure transport connection, while HTTP/1.1 often uses several connections or serial exchanges.

Read Figure 5.2 from left to right. The HTTP/1.1 side either serializes work or opens several TCP and TLS connections, repeating setup and consuming sockets. The HTTP/2 side assigns telemetry, configuration, and firmware to separate logical streams whose frames share one secure connection. That removes application-level queueing between requests, but the final note preserves an important limit: all frames still travel through one ordered TCP byte stream. This distinction prepares the later comparison with QUIC.

5.5.2 Header Compression with HPACK

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

The repeated authorization and representation fields below can outweigh a tiny sensor value. Inspect Figure 5.3 to see when HPACK pays the initial metadata cost and when later requests can reuse it.

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

Three-stage HTTP header comparison. HTTP/1.1 repeats about 350 bytes, the first HTTP/2 request sends about 350 bytes while populating a shared HPACK dynamic table, and a later request sends about 15 to 30 bytes of index references. A common zero-to-350-byte scale shows the example reduction honestly. — Figure 5.3: HPACK sends full repeated fields on the first request, populates a shared header table, and then replaces repeated fields with compact index references.

Read Figure 5.3 by comparing the first two bars before the small third bar. HTTP/1.1 repeats the example fields on every request; the first HTTP/2 request still sends them because both endpoints must establish matching table state. A later request can name indexed fields instead, reducing the example to roughly 15–30 bytes. The saving therefore depends on connection reuse and repeated headers, linking HPACK’s benefit to the session choices in this chapter rather than to every isolated request.

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

5.5.3 Multiplexing Benefits for IoT Gateways

Hold the 50-sensor workload constant while comparing the connection strategy. In the HTTP/1.1 branch, notice the choice between 50 sequential requests and six to eight parallel connections, with TCP and TLS setup repeated across those connections. The HTTP/2 branch instead amortises one TCP-plus-TLS setup and carries 50 independent streams over it. The illustrative times below depend on the stated RTT and setup assumptions; the architectural conclusion is that connection reuse and multiplexing remove serial waiting, not that every gateway is exactly 50 times faster.

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.

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

5.6 HTTP/3: QUIC Transport for Unreliable Networks

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

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

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

Latency Impact on Cellular IoT

On a typical LTE network with 100 ms RTT:

Read these points as one connected sequence: start with HTTP/1.1 + TLS 1.2: ~350-400 ms before first data (radio active for 400 ms); then HTTP/2 + TLS 1.3: ~250-300 ms before first data (25% improvement); and finish with HTTP/3 + QUIC 0-RTT: ~100 ms for resumed connections (70% improvement).

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

For a device waking 96 times per day (every 15 minutes), this translates to: Read these points as one connected sequence: start with HTTP/1.1: 33.6 seconds of radio time/day (96 × 3.5 RTTs × 100 ms); then HTTP/3: 9.6 seconds of radio time/day (96 × 1.0 RTT × 100 ms); and finish with Battery savings: ~71% reduction in connection overhead.

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

Putting Numbers to It

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.

Phoebe’s Field Notes: Where the Battery-Life Number Behind the Calculator Comes From

The mathematical gist. A 2000 mAh, 3.7 V battery carries 7.40 Wh by nameplate. Its 300 mA burst sags 24.0 mV through 80 milliohms, while internal heat is $I^2R_{int}t$ : 0.242 J/day for HTTP/1.1’s 33.6 active seconds and 0.0691 J/day for HTTP/3’s 9.6 seconds. Separately, 2% monthly self-discharge leaves about 1570 mAh after a year.

5.6.3 Handling Packet Loss Gracefully

Compare the two cases at the moment the firmware packet is lost. Under HTTP/2, both telemetry and firmware share TCP’s ordered byte stream, so the missing bytes hold later data until retransmission repairs the gap. Under HTTP/3, QUIC keeps those application streams independent, allowing telemetry to progress while the firmware stream waits. This matters when urgent state and bulk transfer share a gateway connection; it does not eliminate congestion, radio loss, or the need to measure recovery on the deployed network.

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

Checkpoint: 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, 100 ms 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.

5.7 Protocol Selection Guide

Broker Bex places a constrained device and its one-way or two-way exchange at the root of a branching path. — CP-0049 decision strip: The following decision flowchart helps you select the appropriate HTTP version (or alternative protocol) based on the learner's IoT device constraints and network environment.

Bex closes branches that fail concurrency, mobility, or network-support cards. — CP-0049 decision strip: The following decision flowchart helps you select the appropriate HTTP version (or alternative protocol) based on the learner's IoT device constraints and network environment.

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

Inspect Figure 5.4 to eliminate unsuitable paths before comparing headline performance. Begin with device constraint and interaction pattern, then test concurrency, mobility, and network support.

Decision tree for HTTP protocol selection: severely constrained device leads to CoAP, need for real-time two-way traffic leads to WebSocket, many parallel uploads leads to HTTP/2, switching networks in flight leads to HTTP/3, otherwise HTTP/1.1 with keep-alive. — Figure 5.4: HTTP Protocol Selection Decision Tree for IoT Applications

Follow Figure 5.4 from the root. A severely constrained endpoint exits toward CoAP before advanced HTTP features matter, while bidirectional realtime traffic points to WebSocket. For an HTTP workload, many parallel exchanges favor HTTP/2 multiplexing; a client that changes networks in flight creates a specific case for HTTP/3 connection migration. The remaining stable, simple path can use HTTP/1.1 with keep-alive. The tree frames the detailed recommendations below as consequences of workload evidence.

5.7.1 When to Use HTTP/2

Choose HTTP/2 when:

Read these points as one connected sequence: start with IoT gateway aggregating many device messages to cloud; then Existing HTTP/REST infrastructure must be preserved; then Devices have sufficient memory (32KB+ RAM for TLS+HTTP/2 stack); then Connection reuse is possible (persistent connection to backend); and finish with Example: Smart building gateway sending HVAC data to cloud API.

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

5.7.2 When to Use HTTP/3

Choose HTTP/3 when:

Read these points as one connected sequence: start with Cellular IoT with frequent sleep/wake cycles; then Mobile assets changing networks (vehicles, drones, wearables); then Lossy wireless links (satellite, rural cellular); then Mixing real-time telemetry with bulk transfers; and finish with Example: Fleet tracking devices on LTE/5G.

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

5.7.3 When to Avoid HTTP/2/3

Avoid HTTP/2/3 when:

Read these points as one connected sequence: start with Extremely constrained devices (<16KB RAM); then Simple request-response suffices (use CoAP instead); then UDP is blocked by network (enterprise firewalls); and finish with Battery sensors with infrequent transmissions (MQTT over TCP simpler).

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 5.4) guides you through selecting the appropriate HTTP version based on:

Read these points as one connected sequence: start with Device RAM constraints - Determines if HTTP is feasible; then Infrastructure requirements - Whether existing HTTP/REST APIs must be used; then Network stability - Stable vs. cellular/mobile networks; and finish with UDP availability - Some networks block UDP (required for HTTP/3).

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

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

5.8 Continue to Part 2

Continue with Modern HTTP: Implementation and Deployment.