When interviewers ask about HTTP/2 or HTTP/3 they want to see that you understand why the protocols exist, how they differ from HTTP/1.1, and what practical impact they have on real‑world services.
One‑Sentence Definitions
- HTTP/2: A revision of HTTP that keeps the same semantics but uses a single TCP connection to multiplex many requests, compress headers, and optionally push resources.
- HTTP/3: The next‑generation HTTP built on QUIC (a UDP‑based transport) that removes the TCP handshake, integrates TLS, and provides built‑in loss recovery and connection migration.
Core Mechanisms
HTTP/2
- Multiplexed Streams – Each request/response pair lives on its own logical stream within a single TCP connection, eliminating head‑of‑line blocking.
- Header Compression (HPACK) – Replaces repetitive header text with indexed references, reducing bandwidth.
- Server Push – Allows the server to send resources the client is likely to need before the client asks for them.
- Binary Framing – All messages are binary frames, making parsing simpler and more efficient.
HTTP/3
- QUIC Transport – Runs over UDP, providing its own congestion control, loss recovery, and stream multiplexing.
- 0‑RTT Handshake – After the first connection, the client can start sending data without waiting for a full TLS handshake.
- Connection Migration – Because QUIC is not bound to a specific IP/port, a moving client (e.g., from Wi‑Fi to cellular) can keep the same connection.
- Integrated TLS 1.3 – Encryption is mandatory and baked into the protocol, simplifying security.
Trade‑offs
| Aspect | HTTP/2 | HTTP/3 |
|---|---|---|
| Transport Layer | TCP (reliable, ordered) | QUIC over UDP (reliable, but with independent streams) |
| Handshake Latency | 1‑RTT TLS over TCP | 0‑RTT possible, fewer round‑trips |
| Head‑of‑Line Blocking | Mitigated by multiplexing, but still suffers from TCP loss recovery | Eliminated across streams; loss of one packet only affects its stream |
| Compatibility | Widely supported in browsers and servers since 2015 | Supported in most modern browsers (Chrome, Edge, Safari) and many CDNs, but older infrastructure may need updates |
| Complexity | Requires HPACK, stream management | Requires QUIC implementation, more moving parts |
| Use Cases | High‑traffic sites that benefit from server push and header compression | Mobile or high‑latency environments where connection migration and fast handshakes matter |
When to Prefer One Over the Other
- HTTP/2 is a safe upgrade for most existing services; it works with existing TCP‑based load balancers and firewalls.
- HTTP/3 shines when users frequently switch networks or when you need the absolute lowest latency for the first request (e.g., video streaming start‑up).
Concrete Example
Imagine you are optimizing the checkout flow of an e‑commerce site.
- Current state (HTTP/1.1) – The browser opens six TCP connections, each request suffers from TLS handshakes and head‑of‑line blocking.
- Switch to HTTP/2 – All assets (HTML, CSS, JS, images) are fetched over a single connection. Header compression reduces the overhead of cookies and auth tokens. The server can push the CSS bundle after the HTML response, shaving ~200 ms off the perceived load time.
- Upgrade to HTTP/3 – The client, moving from a desktop Wi‑Fi to a mobile network, keeps the same QUIC connection. The 0‑RTT handshake means the first request is sent instantly, reducing the time‑to‑first‑byte by another ~100 ms, especially noticeable on high‑latency cellular links.
Typical Interview Questions
| Question | What Interviewers Look For |
|---|---|
| “What problem does HTTP/2 solve?” | Understanding of head‑of‑line blocking and the cost of multiple TCP connections. |
| “How does header compression work?” | Knowledge of HPACK indexing and why it matters for bandwidth. |
| “Why would you enable server push?” | Ability to reason about when push is beneficial vs. wasteful (e.g., cache‑able resources). |
| “What are the risks of adopting HTTP/3?” | Awareness of deployment challenges, middlebox compatibility, and debugging QUIC traffic. |
| “Explain the difference between multiplexing in HTTP/2 and QUIC streams.” | Insight into how TCP vs. UDP affects stream isolation and loss recovery. |
60‑Second Spoken Answer (Template)
"HTTP/2 and HTTP/3 are both evolutions of the original HTTP protocol that aim to make web communication faster and more efficient. HTTP/2 keeps the same request‑response model but introduces a single TCP connection that can carry many streams at once, compresses headers with HPACK, and lets the server push resources the client is likely to need. This removes the head‑of‑line blocking you see with HTTP/1.1 and reduces latency, especially on pages with many small assets.
HTTP/3 goes a step further by replacing TCP with QUIC, which runs over UDP. QUIC integrates TLS 1.3 and provides its own loss recovery, so each stream is independent – a lost packet only stalls that stream, not the whole connection. It also supports 0‑RTT handshakes, letting the client start sending data instantly after the first connection, and it can migrate connections when a device changes networks. The trade‑off is added complexity and the need for newer infrastructure.
In practice, you’d upgrade a site to HTTP/2 for immediate gains with minimal risk, and consider HTTP/3 when you have a mobile‑heavy audience or need the fastest possible first‑byte latency."
How Call Assistant Helps
- Practice aloud: Use Call Assistant to rehearse the 60‑second answer and get instant feedback on pacing and clarity.
- Stay on topic: If the interview drifts into related areas (e.g., TLS, CDN caching), Call Assistant can surface the next relevant talking point, keeping your narrative grounded in the resume bullet that mentions your work on performance.
How to Practice This
- Write a concise answer – Draft a 45‑90 second version using the template above, then replace generic phrasing with specifics from your own projects.
- Record yourself – Play back the recording to check for filler words and timing; aim for a natural cadence.
- Simulate follow‑ups – Have a colleague ask one of the typical questions from the table and answer on the spot, using the mechanisms you just described.
FAQ
- What is the main advantage of HTTP/2 over HTTP/1.1? HTTP/2 eliminates head‑of‑line blocking by multiplexing many requests over a single TCP connection and reduces overhead with header compression.
- Does HTTP/3 require a new port? No, HTTP/3 still uses port 443 for HTTPS traffic; it just switches the underlying transport from TCP to UDP.
- Can a server push the same resource twice? Yes, but browsers will ignore duplicate pushes if they already have the resource cached, so push should be used judiciously.
- Is QUIC only for browsers? While browsers were the first major adopters, many CDNs, APIs, and even some VPNs now support QUIC because of its latency benefits.
Frequently asked questions
What is the main advantage of HTTP/2 over HTTP/1.1?
HTTP/2 eliminates head‑of‑line blocking by multiplexing many requests over a single TCP connection and reduces overhead with header compression.
Does HTTP/3 require a new port?
No, HTTP/3 still uses port 443 for HTTPS traffic; it just switches the underlying transport from TCP to UDP.
Can a server push the same resource twice?
Yes, but browsers will ignore duplicate pushes if they already have the resource cached, so push should be used judiciously.
Is QUIC only for browsers?
While browsers were the first major adopters, many CDNs, APIs, and even some VPNs now support QUIC because of its latency benefits.
#concept#HTTP/2#HTTP/3#networking#performance#HTTP/2 and HTTP/3