HTTP/2 and HTTP/3 Interview Questions and Answers (2026)

When interviewers ask about HTTP/2 or HTTP/3, they’re looking for three things: you understand the protocol mechanics, you can measure the real‑world impact, and you can translate that knowledge into better software. Below is a set of questions that span entry‑level to senior‑engineer depth, each paired with a short answer you could deliver in 45‑90 seconds. After each answer, note a typical follow‑up the interviewer might ask. Use the pattern to rehearse – saying the answer out loud helps you gauge timing, and a tool like Call Assistant can keep the conversation anchored to your resume while you practice.

1. Core motivations behind HTTP/2

Question: Why was HTTP/2 created? Answer: HTTP/2 was introduced to fix the inefficiencies of HTTP/1.1, especially the head‑of‑line blocking caused by one request per TCP connection. By adding binary framing, multiplexing, and header compression, it lets a single connection carry many parallel streams, reducing latency and improving bandwidth utilization. Typical follow‑up: Can you give an example of how you measured the performance gain in a real project?

2. Binary framing vs. textual protocol

Question: What does “binary framing” mean, and why is it beneficial? Answer: Instead of sending plain text, HTTP/2 wraps each piece of data in a frame with a type, length, and stream identifier. This makes parsing deterministic, reduces parsing errors, and allows the protocol to interleave control and data frames efficiently. Typical follow‑up: How does this affect debugging tools you’ve used?

3. Header compression with HPACK

Question: Explain HPACK and its role in HTTP/2. Answer: HPACK compresses HTTP headers by maintaining a dynamic table of previously seen header fields. When a header repeats, the client can send an index instead of the full text, cutting down overhead—especially useful for repetitive cookies or auth tokens. Typical follow‑up: What trade‑offs does HPACK introduce regarding security?

4. Multiplexing mechanics

Question: How does multiplexing work in HTTP/2? Answer: Each request gets its own stream ID. Frames from different streams share the same TCP connection, and the receiver reassembles them based on those IDs. This eliminates the need for multiple connections and avoids head‑of‑line blocking. Typical follow‑up: How does HTTP/2 handle priority among streams?

5. Server push fundamentals

Question: What is server push, and when would you use it? Answer: Server push lets the server proactively send resources the client is likely to need (e.g., CSS or JS) before the client asks for them. It can reduce round‑trip time for page loads, but you must avoid over‑pushing to prevent wasted bandwidth. Typical follow‑up: Have you ever disabled push in production? Why?

6. Transition from HTTP/2 to HTTP/3

Question: Why move from HTTP/2 to HTTP/3? Answer: HTTP/3 replaces TCP with QUIC, a UDP‑based transport that integrates TLS handshakes and supports connection migration. This reduces latency on lossy networks, avoids TCP’s slow‑start penalties after a network change, and provides built‑in encryption. Typical follow‑up: What challenges did you face when deploying QUIC‑based services?

7. QUIC’s connection migration

Question: Describe connection migration in QUIC and its benefit. Answer: Because QUIC runs over UDP, it can continue a connection even if the client’s IP address changes (e.g., moving from Wi‑Fi to cellular). The client simply updates the endpoint address, and the server continues the same stream IDs, preserving session state and avoiding a full handshake. Typical follow‑up: How do you test migration scenarios in CI?

8. TLS integration differences

Question: How does encryption differ between HTTP/2 and HTTP/3? Answer: HTTP/2 relies on TLS over TCP, requiring a separate handshake before any HTTP data. HTTP/3 embeds TLS 1.3 within QUIC, so the handshake and encrypted data travel together, cutting one round‑trip for the initial connection. Typical follow‑up: Does this affect how you configure load balancers?

9. Impact on latency and throughput

Question: Quantify the latency improvements you’ve observed with HTTP/2/3. Answer: In a recent refactor of a content‑heavy site, moving from HTTP/1.1 to HTTP/2 cut average page‑load time by roughly 20 % due to reduced TCP connections and header compression. Switching to HTTP/3 on mobile further shaved another 10 % by eliminating TCP retransmission delays during network switches. Typical follow‑up: What metrics did you monitor to confirm these gains?

10. Debugging and observability

Question: What tools do you use to inspect HTTP/2/3 traffic? Answer: For HTTP/2, I rely on Wireshark with the "Decode As" feature and Chrome DevTools’ Network tab, which shows stream IDs and push resources. For HTTP/3, I use nghttp3‑compatible clients and the quicly library’s logging output, plus the newer "Network" panel in browsers that now expose QUIC frames. Typical follow‑up: How do you capture logs in production without impacting performance?

11. Compatibility considerations

Question: How do you handle browsers that don’t support HTTP/3? Answer: I configure the server to negotiate the highest protocol both client and server support via ALPN. If the client only offers HTTP/1.1 or HTTP/2, the server falls back gracefully, ensuring a seamless experience. Typical follow‑up: What fallback strategies have you implemented for legacy mobile apps?

12. Security implications

Question: Are there new attack surfaces introduced by HTTP/3? Answer: QUIC’s reliance on UDP opens it to amplification attacks, but built‑in connection IDs and stateless reset tokens mitigate this. Additionally, because TLS 1.3 is mandatory, many older cipher‑suite vulnerabilities are eliminated. Typical follow‑up: How do you monitor for potential QUIC‑specific DDoS patterns?

13. Server implementation choices

Question: What libraries or frameworks have you used for HTTP/2 and HTTP/3? Answer: For HTTP/2, I’ve worked with nghttp2 (C), Jetty (Java), and the built‑in http2 module in Node.js. For HTTP/3, I’ve experimented with quiche (Rust) and aioquic (Python), both of which expose a simple API for stream handling and connection migration. Typical follow‑up: Which library did you find most production‑ready and why?

14. Performance tuning tips

Question: What are common tuning knobs for HTTP/2/3 servers? Answer: Adjust the maximum concurrent streams per connection to match your CPU and network capacity, fine‑tune the HPACK table size to balance memory usage and compression gains, and for QUIC, set appropriate idle timeout and max UDP payload size to avoid fragmentation. Typical follow‑up: How do you monitor these settings in a live environment?

15. Future outlook

Question: Where do you see HTTP/3 evolving in the next few years? Answer: Adoption will continue to grow as browsers solidify QUIC support and CDNs roll out edge‑based QUIC termination. Expect tighter integration with HTTP semantics (e.g., richer push policies) and more tooling around observability. Typical follow‑up: How are you preparing your codebase for upcoming changes?

---

How to practice this

1. Record yourself: Use a voice recorder or Call Assistant to capture a 45‑second answer for each question. Listen back and trim any filler.
2. Simulate follow‑ups: After each recorded answer, immediately answer the suggested follow‑up. This builds the habit of extending a story naturally.
3. Tie to your resume: Pick one or two real projects where you implemented HTTP/2 or HTTP/3. Draft a brief bullet that links the protocol benefit to a measurable outcome, and rehearse that as part of your answer.

---