ToppyMicroServices

RFC 9114 Quiz

HTTP/3 on QUIC

πŸ‡ΊπŸ‡Έ πŸ‡―πŸ‡΅
0 / 0

References (URLs)

Q1: HTTP/3 runs over which transport protocol

Multiple Choice
**Explanation:** HTTP/3, QUIC. HTTP/3 is the mapping of HTTP semantics onto QUIC streams. RFC 9114 defines HTTP/3 as running on QUIC. - A (correct): QUIC provides streams, encryption integration, and connection migration. - B (incorrect): TCP is used by HTTP/1.1 and usually HTTP/2, not HTTP/3. - C (incorrect): SCTP is not the basis of HTTP/3. QUIC itself commonly uses UDP as its substrate.

Q2: Which problem is HTTP/3 designed to reduce compared to HTTP/2 over TCP

Multiple Choice
HTTP/2 multiplexes many requests over one TCP byte stream, so one loss can stall every stream. QUIC keeps stream progress more independent.
TCP loss on one packet single ordered byte stream all streams wait HTTP/2 streams stall cross-stream blocking QUIC loss on stream A stream state stays separate stream B still moves HTTP/3 on QUIC less cross-stream stall
**Explanation:** head-of-line blocking, TCP, QUIC streams. TCP loss recovery can stall delivery for all multiplexed streams. QUIC avoids this by handling loss and streams differently. HTTP/3 aims to avoid the cross-stream stall that occurs when HTTP/2 multiplexes over one TCP byte stream. - A (incorrect): DNS is separate from HTTP version. - B (incorrect): HTTP/3 still uses TLS 1.3 semantics integrated with QUIC. - C (correct): This is a primary motivation for moving to QUIC. Application-level head-of-line can still happen due to server-side scheduling, but transport behavior is improved.

Q3: What is the role of QPACK in HTTP/3

Multiple Choice
**Explanation:** header compression, QPACK, QUIC. HTTP uses many header fields, so compression reduces overhead, but it must not reintroduce head-of-line blocking. QPACK is the header compression mechanism used with HTTP/3. - A (incorrect): Authentication is not the role of header compression. - B (correct): It compresses headers while working with QUIC stream delivery characteristics. - C (incorrect): Congestion control is a transport function, primarily in QUIC. HTTP/2 uses HPACK. HTTP/3 uses QPACK to avoid coupling header decoding to ordered delivery.

Q4: How must the peer handle the closed control stream?

Multiple Choice

An HTTP/3 endpoint sends its SETTINGS frame, then cleanly closes its control stream and opens a second control stream to continue sending connection-level frames.

**Explanation:** A: RFC 9114 Section 6.2.1 allows exactly one control stream per peer and forbids closing it. Repeating settings cannot restore the lost connection state. B: SETTINGS, GOAWAY, and other connection-level frames have defined stream locations; moving them to request streams is invalid. C: Section 6.2.1 requires H3_CLOSED_CRITICAL_STREAM when either control stream closes. A second control stream would independently cause H3_STREAM_CREATION_ERROR. D: The control stream governs the HTTP/3 connection, so its loss is not scoped to one request. Decision rule: Critical-stream continuity is a connection invariant; do not design replacement streams as application-level failover.

Q5: May the client reuse this HTTP/3 connection?

Multiple Choice

A client has an HTTP/3 connection to https://a.example. DNS maps b.example to the same IP and UDP port, but the server certificate is acceptable only for a.example. The client wants to send a request for https://b.example on the existing connection.

**Explanation:** A: Network location does not establish HTTP authority for every name hosted at that endpoint. B: RFC 9114 Section 3.3 requires certificate validation for each new origin before connection reuse. Because this certificate is unacceptable for b.example, the connection must not be reused for it. C: QPACK verifies compression state, not origin authority or certificate identity. D: Section 3.3 permits cross-origin connection reuse when the server certificate is acceptable for the additional origin. Decision rule: Coalescing is conditional on authority for each origin, not merely endpoint equality or an already authenticated different origin.

Q6: How should the gateway handle the authority conflict?

Multiple Choice

An HTTP/3 gateway receives an HTTPS request with :authority = agent-a.example and Host: agent-b.example. Its routing and authorization policies would select different tenants for those values. It plans to translate the request to HTTP/1.1.

**Explanation:** A: Choosing Host silently changes the target authority asserted in :authority and can cross a tenant boundary. B: RFC 9114 does not define an override rule for this conflict; Section 4.3.1 requires the two values to be identical when both are present. C: The request violates Section 4.3.1 and is malformed. Section 4.1.2 requires a malformed request to be rejected rather than repaired into a different target. D: Routing and authorization on different authorities creates the very interpretation split that canonical input validation must prevent. Decision rule: Validate the HTTP/3 control data before protocol translation. Canonicalization may normalize equivalent syntax, but it must not invent precedence for contradictory authorities.