Application Protocols · Study deck
Modern HTTP: Implementation and Deployment
Inspect the HTTP/1.1, HTTP/2, and HTTP/3 preserve HTTP application semantics while changing framing, transport, and loss boundaries underneath diagram to find the layer where each HTTP version changes how concurrent work reacts to delay or packet loss.
Broker Bex is your guide for this deck.
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.
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
Single TCP connection reduces TLS handshake overhead for persistent connections.
- HTTP/2 Benefits: A gateway can send many requests on one link.
- Multiplexing lets concurrent gateway requests share a TCP connection; the 50× figure applies only to the chapter’s sequential baseline.
- 0-RTT resumption: eligible resumed requests can avoid setup waiting; total device power savings require measurement.
Major section
What You Learned (continued)
HPACK compression reduces repeated-header overhead in chatty IoT applications; the percentage depends on the header mix.
- Client-requested streaming or normal downloads can deliver firmware; HTTP/2 server push is optional and is not a reliable deployment assumption.
- Independent streams: No cross-stream transport head-of-line blocking; shared congestion can still slow others.
- Connection-level congestion control: QUIC streams share connection capacity; test mixed telemetry and firmware traffic.
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.
Major section
Concept Relationships
Related Technologies: TLS and CDN behavior affect delivery; the mobile case shows when HTTP/3 resumption changes setup waiting.
- Prerequisites You Should Know: Handshake costs motivate connection reuse; compare the TCP and UDP paths before applying them to gateways and mobile devices.
- TCP three-way handshake and why it adds latency.
- Gateway design where a reusable connection carries concurrent requests.
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.
- Single TCP connection reduces TLS handshake overhead for persistent connections.
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 and check specifically for HTTP 201 Created:
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.
Q2A protocol looks fast in a lab. What must the team verify before approving it on a constrained device fleet?
Show answer
Answer: B The selection only works if the actual client and server can support it.
Retrieval practice
Recall check 3 of 6
Broker Bex says: answer from memory, then check your reasoning.
Q3Per this chapter's Common Pitfalls, why is HTTP/3's 0-RTT resumption risky for actuator commands but acceptable for sensor readings?
Show answer
Answer: A see answers page
Retrieval practice
Recall check 4 of 6
Broker Bex says: answer from memory, then check your reasoning.
Q4Per 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?
Show answer
Answer: D see answers page
Retrieval practice
Recall check 5 of 6
Broker Bex says: answer from memory, then check your reasoning.
Q5What organises concurrent HTTP exchanges into binary frames and streams beneath message semantics?
Show answer
Answer: C Binary frames and multiplexed streams organise concurrent exchanges below the semantic message.
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?
Show answer
Answer: A see answers page
Print reference
Answers 1 of 4
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.
- B · The selection only works if the actual client and server can support it.
Print reference
Answers 2 of 4
Answer key.
- 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 3 of 4
Answer key.
- D · 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 · Binary frames and multiplexed streams organise concurrent exchanges below the semantic message.
Print reference
Answers 4 of 4
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.