Application Protocols · Study deck

Modern HTTP: Implementation and Deployment

Modern HTTP is the web stack learning to move many IoT conversations without reopening the road for every request.

Broker Bex is your guide for this deck.

httpmodern

Broker Bex, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

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

Major section

Real-World Tradeoffs

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.

HTTP/2 vs HTTP/3 Tradeoff Analysis for IoT

Major section

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

HTTP/1.1, HTTP/2, and HTTP/3 can be read as three attempts to reduce head-of-line blocking.

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

Major section

Deep Dive: One Connection, Many Streams, No Head-of-Line Block (continued)

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.
QPACK keeps the same goal, compact repeated header fields, but avoids letting one blocked header reference stall unrelated streams.
HTTP/3 uses QPACK rather than HPACK because QUIC streams can arrive out of order.

Major section

Deep Dive: One Connection, Many Streams, No Head-of-Line Block (continued)

That distinction matters when telemetry, commands, and firmware chunks share one connection on a lossy link.

The connection identity is a QUIC Connection ID, not the client's current IP address and port.
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.

Major section

What You Learned

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.

Major section

For Instructors: Teaching Suggestions

HTTP/2 Multiplexing Demo: Use curl --http2 with timing to compare 10 sequential vs. Parallel requests.

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

Deck summary

Key takeaways

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/1.1, HTTP/2, and HTTP/3 can be read as three attempts to reduce head-of-line blocking.
HPACK uses a static table for common fields and a per-connection dynamic table for repeated values.
That distinction matters when telemetry, commands, and firmware chunks share one connection on a lossy link.
Multiplexing enables 50x faster gateway scenarios by sending all requests over a single TCP connection.

Retrieval practice

Recall check 1 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q1Complete the HTTP POST request to send sensor data:

Aresponse = requests.post('https://api.example.com/sensors', json=sensor_data)

Bresponse = requests.send('https://api.example.com/sensors', data=sensor_data)

Cresponse = http.post('https://api.example.com/sensors', body=sensor_data)

Dresponse = requests.publish('https://api.example.com/sensors', json=sensor_data)

Show answer

Answer: A requests.post() with json= parameter automatically serializes and sets Content-Type. HTTP 201 (Created) is the standard response for successful resource creation, while 200 indicates general success.

Retrieval practice

Recall check 2 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q2Per this chapter's Common Pitfalls, why is HTTP/3's 0-RTT resumption risky for actuator commands but acceptable for sensor readings?

A0-RTT data is vulnerable to replay attacks; idempotent operations like GET/sensor readings tolerate a replay safely, but non-idempotent operations like commands need 1-RTT or explicit replay protection

B0-RTT only works for GET requests, so commands must use HTTP/1.1 instead

C0-RTT data is always encrypted with a weaker cipher than 1-RTT data

DActuator commands are too large to fit in a 0-RTT packet

Show answer

Answer: A see answers page

Retrieval practice

Recall check 3 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q3Per this chapter's Common Pitfalls, what's wrong with opening a new HTTP connection for each sensor's POST request in a loop, even under HTTP/2?

AIt defeats HTTP/2 multiplexing entirely -- multiplexing's whole benefit comes from sharing a SINGLE connection across many streams, not from opening one connection per request

BHTTP/2 doesn't allow more than one connection to the same server under any circumstances

CEach new connection under HTTP/2 must renegotiate TLS 1.3 twice, doubling the handshake cost

DThe mistake only matters for HTTP/3, not HTTP/2, since HTTP/2 has no per-connection overhead

Show answer

Answer: A see answers page

Retrieval practice

Recall check 4 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q4An IoT fleet of 500 battery-powered sensors sends temperature readings every 30 seconds over cellular. Each HTTP/1.1 request requires a new TCP+TLS handshake (3 roundtrips). Which HTTP version change would most reduce power consumption?

ASwitch to HTTP/1.1 with persistent Keep-Alive connections only

BUpgrade to HTTP/2 with multiplexed streams over a single connection

CUpgrade to HTTP/3 with QUIC 0-RTT resumption

DUse HTTP/1.0 without Keep-Alive to keep connections simple

Show answer

Answer: C

Retrieval practice

Recall check 5 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q5Place each modern HTTP responsibility where it lives so you can compare HTTP/2 and HTTP/3 without confusing shared semantics with their different transport machinery.

AHTTP Semantics (Methods, Headers)

BBinary Framing / Stream Multiplexing

CTLS 1.3 (integrated in QUIC for HTTP/3)

DTCP (HTTP/2) or UDP (HTTP/3 QUIC)

Show answer

Answer: A Place each modern HTTP responsibility where it lives so you can compare HTTP/2 and HTTP/3 without confusing shared semantics with their different transport machinery.

Retrieval practice

Recall check 6 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q6Per this chapter's Deep Dive, why does HTTP/3 use QPACK instead of reusing HTTP/2's HPACK for header compression?

AQUIC streams can arrive out of order, and QPACK avoids letting one blocked header reference stall unrelated streams -- HPACK's scheme assumes in-order delivery

BQPACK compresses headers more aggressively than HPACK, achieving over 99% reduction instead of 90%

CHPACK cannot run over UDP at all, so HTTP/3 needed a completely different compression algorithm

DQPACK is used only for firmware chunks, while QUIC streams carrying telemetry still use HPACK

Show answer

Answer: A see answers page

Print reference

Answers 1 of 3

Answer key.

A · requests.post() with json= parameter automatically serializes and sets Content-Type. HTTP 201 (Created) is the standard response for successful resource creation, while 200 indicates general success.
A · The chapter's pitfall #5 warns that 0-RTT early data can be replayed by an attacker; idempotent requests (a GET, a sensor reading) are safe to receive twice, but non-idempotent requests (a command, an actuator trigger) are not, so those should use 1-RTT or add explicit replay protection.

Print reference

Answers 2 of 3

Answer key.

A · The chapter's pitfall #3 contrasts opening a new connection per sensor request (which defeats multiplexing) against reusing a single async client so all requests share one multiplexed HTTP/2 connection -- the whole point of multiplexing is a single shared connection, not one per request.
C
A · Place each modern HTTP responsibility where it lives so you can compare HTTP/2 and HTTP/3 without confusing shared semantics with their different transport machinery.

Print reference

Answers 3 of 3

Answer key.

A · The chapter's Deep Dive explains that QUIC streams can arrive out of order, which would let a single blocked header reference under HPACK stall unrelated streams; QPACK keeps HPACK's compression goal but is designed so that doesn't happen -- a distinction that matters when telemetry, commands, and firmware chunks share one lossy connection.