Bird
Raised Fist0

HTTP 1.1 vs HTTP 2 vs HTTP 3 - What Changed and Why It Matters

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🎯
HTTP 1.1 vs HTTP 2 vs HTTP 3 - What Changed and Why It Matters
45 min · senior
senior

You are an engineering lead at a startup with 50 million daily active users (DAU) delivering rich web content globally. The system must support encrypted connections, minimize latency with P99 < 200ms, and handle high concurrency with efficient resource utilization. You need to evaluate and design how HTTP/1.1, HTTP/2, and HTTP/3 protocols impact your system's performance, reliability, and scalability.

Constraints
  • All connections must be encrypted (TLS mandatory).
  • P99 latency for page load under 200ms globally.
  • Support 50M DAU with peak concurrency of 5M simultaneous connections.
  • Graceful degradation for clients on older protocols.
  • Minimize head-of-line blocking and improve multiplexing efficiency.
📋
Guided Steps
1/5
Step 1
Connection Management and Multiplexing
How does HTTP/1.1 handle multiple requests compared to HTTP/2 and HTTP/3? What are the implications for connection management?
💡 Hint
Consider TCP connection reuse, pipelining, and multiplexing capabilities.
Key Decision
HTTP/2 uses a single TCP connection with multiplexed streams via framing layer, while HTTP/3 uses QUIC over UDP enabling multiplexing without TCP head-of-line blocking.
Interviewer Expectation
Mid: Describes HTTP/1.1 pipelining limitations and HTTP/2 multiplexing. Senior: Explains TCP head-of-line blocking in HTTP/2 and how QUIC in HTTP/3 solves it by using UDP and independent streams.
⚠️Common Wrong Answer
Assuming HTTP/2 eliminates all head-of-line blocking - ignores TCP-level HOL blocking that persists in HTTP/2.
Step 2
Encryption and Protocol Negotiation
How do HTTP/1.1, HTTP/2, and HTTP/3 differ in their approach to encryption and protocol negotiation?
💡 Hint
Think about TLS versions, ALPN, and mandatory encryption requirements.
Key Decision
HTTP/2 mandates TLS 1.2+ with ALPN for protocol negotiation over TCP, while HTTP/3 integrates TLS 1.3 directly into QUIC over UDP, reducing handshake latency.
Interviewer Expectation
Mid: Knows HTTP/2 requires TLS and ALPN. Senior: Details how HTTP/3’s QUIC combines transport and security handshake, reducing connection setup time and improving 0-RTT resumption.
⚠️Common Wrong Answer
Believing HTTP/3 uses TCP with TLS - actually uses UDP with integrated TLS 1.3 in QUIC.
Step 3
Latency and Head-of-Line Blocking Impact
Explain how head-of-line blocking affects latency in HTTP/1.1 and HTTP/2, and how HTTP/3 addresses this issue.
💡 Hint
Focus on transport layer behavior and packet loss recovery.
Key Decision
HTTP/1.1 suffers from HOL blocking due to sequential request-response per connection; HTTP/2 multiplexes streams but TCP HOL blocking remains; HTTP/3’s QUIC protocol eliminates TCP HOL blocking by handling streams independently over UDP.
Interviewer Expectation
Mid: Identifies HOL blocking in HTTP/1.1 and HTTP/2. Senior: Explains TCP retransmission delays causing HOL blocking in HTTP/2 and how QUIC’s stream-level retransmission avoids this.
⚠️Common Wrong Answer
Claiming HTTP/2 fully solves HOL blocking without acknowledging TCP transport limitations.
Step 4
Handling Packet Loss and Reliability
How do HTTP/2 and HTTP/3 differ in handling packet loss and ensuring reliable delivery?
💡 Hint
Consider transport protocols and retransmission strategies.
Key Decision
HTTP/2 relies on TCP’s reliable byte stream with retransmission causing HOL blocking; HTTP/3 uses QUIC’s multiplexed streams with independent retransmission, reducing latency impact of packet loss.
Interviewer Expectation
Mid: Understands TCP retransmission in HTTP/2. Senior: Explains QUIC’s per-stream retransmission and forward error correction capabilities improving performance on lossy networks.
⚠️Common Wrong Answer
Assuming HTTP/3 retransmission is identical to TCP’s, ignoring QUIC’s stream independence.
Step 5
Backward Compatibility and Deployment Considerations
What challenges arise when deploying HTTP/2 and HTTP/3 alongside HTTP/1.1, and how can these be addressed?
💡 Hint
Think about client support, fallback mechanisms, and infrastructure changes.
Key Decision
Use ALPN for protocol negotiation to fallback gracefully to HTTP/1.1; deploy HTTP/3 with UDP support and QUIC-aware load balancers; monitor client capabilities and network conditions for adaptive protocol selection.
Interviewer Expectation
Mid: Mentions ALPN fallback to HTTP/1.1. Senior: Discusses UDP firewall traversal issues, QUIC connection migration, and impact on CDN and proxy infrastructure.
⚠️Common Wrong Answer
Ignoring UDP firewall issues causing HTTP/3 connection failures in some networks.
🔌
API Design Challenge
Sketch 3 core HTTP endpoints illustrating how clients interact differently under HTTP/1.1, HTTP/2, and HTTP/3 protocols.
Hints
  • How does the client initiate and maintain connections in each protocol?
  • How does multiplexing and stream prioritization affect request handling?
  • How does the client acknowledge or handle packet loss and retransmission?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Explains multiplexing differences and TCP vs UDP transport impact on HOL blocking.
  • Details TLS integration differences and ALPN negotiation.
  • Describes latency improvements and packet loss handling in HTTP/3 QUIC.
  • Includes backward compatibility and deployment challenges with fallback.
  • Names real protocols and technologies: TCP, TLS 1.2/1.3, ALPN, QUIC, UDP.
Good to Have - 30%
  • Discusses 0-RTT connection resumption benefits in HTTP/3.
  • Mentions CDN and proxy infrastructure changes for HTTP/3.
  • Explains stream prioritization and flow control differences.
  • Considers firewall and network traversal issues for UDP.
Bonus - 10%
  • Suggests monitoring and adaptive protocol selection based on client/network.
  • Highlights security improvements in TLS 1.3 integration with QUIC.
Anti-patterns to Avoid
Ignoring TCP head-of-line blocking in HTTP/2 leads to underestimating latency bottlenecks, causing poor performance at scale.
Assuming HTTP/3 uses TCP causes misunderstanding of deployment and firewall issues, resulting in connection failures.
Neglecting ALPN fallback results in poor backward compatibility and client failures, reducing user experience.
Overlooking UDP firewall traversal causes HTTP/3 connection failures in real networks, impacting availability.
Treating multiplexing as purely application-layer without transport implications misses key performance factors, leading to inefficient designs.
✅
Model Answer
▼ Reveal

This design challenge explores the evolution of HTTP protocols from HTTP/1.1 to HTTP/2 and HTTP/3, focusing on how protocol changes improve performance, scalability, and reliability for large-scale web services. HTTP/1.1 uses multiple TCP connections or pipelining with limited multiplexing, causing head-of-line blocking and inefficiencies. HTTP/2 introduces multiplexing over a single TCP connection with framing and stream prioritization but still suffers from TCP-level HOL blocking due to retransmission semantics. HTTP/3 replaces TCP with QUIC over UDP, integrating TLS 1.3 and enabling independent stream retransmission, eliminating HOL blocking and reducing handshake latency with 0-RTT resumption. ALPN enables seamless protocol negotiation and fallback, critical for backward compatibility. Deploying HTTP/3 requires infrastructure updates such as QUIC-aware load balancers and firewall traversal strategies to handle UDP traffic.

Key Decisions
  • Use TLS 1.2+ with ALPN for HTTP/2 to ensure encrypted connections and protocol negotiation.
  • Adopt QUIC over UDP for HTTP/3 to eliminate TCP head-of-line blocking and reduce latency.
  • Implement stream prioritization and multiplexing to improve resource utilization and reduce latency.
  • Deploy QUIC-aware load balancers and update firewall rules to support UDP traffic for HTTP/3.
  • Use ALPN fallback mechanisms to maintain backward compatibility with HTTP/1.1 clients.
  • Leverage QUIC’s 0-RTT resumption to reduce handshake latency critical for global low-latency requirements.
  • Monitor client capabilities and network conditions to adaptively select the optimal HTTP protocol.
  • HTTP/1.1 uses multiple TCP connections or pipelining with limited multiplexing, causing inefficiency at scale.
  • HTTP/2 introduces multiplexing over a single TCP connection using framing and stream prioritization to reduce latency.
  • HTTP/2 still suffers from TCP head-of-line blocking due to transport layer retransmission semantics.
  • HTTP/3 replaces TCP with QUIC over UDP, integrating TLS 1.3 and enabling independent stream retransmission to eliminate HOL blocking.
  • QUIC’s 0-RTT connection resumption reduces handshake latency, critical for global low-latency requirements.
  • ALPN (Application-Layer Protocol Negotiation) enables seamless protocol negotiation and fallback between HTTP versions.
  • UDP-based HTTP/3 requires infrastructure updates including QUIC-aware load balancers and firewall traversal strategies.
  • Multiplexing and stream prioritization in HTTP/2 and HTTP/3 improve resource utilization and reduce head-of-line blocking at scale.

Practice

(1/5)
1. A web application needs a cache that automatically removes entries after a fixed time regardless of access frequency. Which cache eviction policy best fits this requirement?
easy
A. Least Frequently Used (LFU) eviction, which removes items accessed least often
B. Least Recently Used (LRU) eviction, which removes the oldest accessed items first
C. Time-To-Live (TTL) eviction, which expires entries after a set duration
D. Adaptive Replacement Cache (ARC), which balances recency and frequency

Solution

  1. Step 1: Identify eviction based on time expiration

    TTL eviction removes cache entries strictly after a fixed time, independent of access patterns.

  2. Step 2: Eliminate other policies

    LRU and LFU depend on access recency or frequency, not fixed time. ARC adapts between recency and frequency but does not enforce fixed expiration.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    TTL evicts by fixed time, ignoring usage patterns [check]
Hint: TTL evicts by time, not usage frequency or recency [OK]
Common Mistakes:
2. In the Redlock algorithm request flow, at Step 4 the client attempts to acquire locks on all Redis masters. What happens if the client successfully acquires locks on only 3 out of 5 masters within the timeout?
easy
A. The client proceeds with the lock assuming majority success
B. The client releases any acquired locks and retries later
C. The client holds partial locks and waits for the rest to acquire
D. The client escalates to a centralized lock coordinator

Solution

  1. Step 1: Trace client lock acquisition at Step 4

    Redlock requires majority of Redis masters to be locked within timeout to consider lock acquired.

  2. Step 2: Handle partial lock acquisition

    If fewer than majority locks acquired, client must release any partial locks to avoid deadlocks and retry.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Partial lock acquisition -> release all and retry [check]
Hint: Partial locks -> release all, no partial ownership [check]
Common Mistakes:
3. If the authentication service in a client-server system becomes unavailable, what is the exact failure mode experienced by clients attempting to log in?
medium
A. Clients receive a generic server error but can retry immediately without data loss
B. Clients are authenticated locally by the server, so login proceeds without interruption
C. Clients' login requests hang until timeout, then receive authentication failure with no retry
D. Clients are redirected to a backup authentication service automatically

Solution

  1. Step 1: Understand authentication dependency

    The server relies on the authentication service for validating credentials; if unavailable, requests cannot be processed.

  2. Step 2: Trace failure impact

    Without authentication service, login requests hang waiting for response until timeout, then fail with no automatic retry or fallback.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Unavailable auth service causes login hang then failure [check]
Hint: No auth service -> login hangs then fails, no fallback [check]
Common Mistakes:
4. If the global BGP route monitoring system is disabled during a misconfiguration event, what is the most likely failure observed in the network recovery process?
medium
A. Routers automatically revert to default static routes, causing traffic blackholing
B. Network devices silently drop BGP updates, leading to partial route visibility
C. Operators receive delayed alerts, causing prolonged outage and inconsistent routing states
D. Clients experience immediate failover to backup ISPs without disruption

Solution

  1. Step 1: Role of BGP monitoring

    BGP monitoring detects anomalies and route changes; without it, routers may silently drop updates due to misconfigurations.

  2. Step 2: Eliminate other options

    Delayed alerts (A) affect operators but don't cause silent drops; routers don't revert to static routes automatically (B); immediate client failover (D) unlikely without proper routing.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Without monitoring, routers drop BGP updates silently causing partial visibility [check]
Hint: No monitoring -> silent BGP update drops, partial routes [check]
Common Mistakes:
5. At 10x scale, which REST API component is most likely to fail first due to stateful session management, and why?
hard
A. Backend database, because it cannot scale writes linearly
B. Load balancer, because it cannot handle increased TCP connections
C. API Gateway, because it maintains stateful authentication sessions in memory per client
D. Cache layer, because it evicts entries too aggressively under load

Solution

  1. Step 1: Identify stateful components in REST API architecture

    API Gateway maintaining in-memory sessions is stateful and tied to client connections.

  2. Step 2: Understand scaling impact of statefulness

    Stateful session storage prevents easy horizontal scaling; new servers can't share session state, causing bottlenecks.

  3. Step 3: Compare with other components

    Load balancers handle stateless TCP connections; databases and caches can be sharded or scaled differently.

  4. Final Answer:

    Option C -> Option C

  5. Quick Check:

    Stateful API Gateway sessions block horizontal scaling first [check]
Hint: Stateful API Gateway sessions block scaling first [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard