Back to the Catalog
http
networking
real-time

Real-Time over HTTP/2 & HTTP/3: Multiplexing, QUIC & WebSocket Bootstrapping

12 questions

How HTTP/2 multiplexing, HTTP/3 over QUIC, and Extended CONNECT (RFC 8441/9220) reshape real-time delivery: application- vs transport-level head-of-line blocking, QUIC's independent streams and connection migration, and running a WebSocket as a multiplexed stream. The HOL-blocking contrast is verified with a Node simulation.

Start

Questions

  1. Not answered. What does HTTP/2 multiplexing improve over HTTP/1.1?
  2. Not answered. HTTP/2 multiplexes streams over one TCP connection. Why can a single lost packet still stall every stream?
  3. Not answered. How does HTTP/3 (over QUIC) eliminate the transport-level head-of-line blocking that HTTP/2 still has?
  4. Not answered. HTTP/3 is built on QUIC. Which lower-layer transport protocol does QUIC itself run over?
  5. Not answered. Which are genuine advantages QUIC brings to real-time connections?
  6. Not answered. RFC 8441 bootstraps WebSockets over HTTP/2 by reusing which HTTP method (carrying a :protocol pseudo-header set to websocket)?
  7. Not answered. What's the practical benefit of running WebSockets over HTTP/2 (RFC 8441) instead of HTTP/1.1?
  8. Not answered. WebSocket over HTTP/3 is standardized by RFC 9220. What does it actually do?
  9. Not answered. Which statements about head-of-line (HOL) blocking across HTTP versions are correct?
  10. Not answered. What became of HTTP/2 Server Push as a delivery mechanism?
  11. Not answered. Which informational HTTP status code is the modern, lightweight replacement for HTTP/2 Server Push (letting the server hint at resources to preload before the final response)?
  12. Not answered. A mobile app needs a real-time connection that survives switching from Wi-Fi to cellular without a reconnect/handshake stall. Which characteristic delivers that?