Today’s computer network interview question has been asked by major companies such as ByteDance, Meituan, and Tencent, making it quite common.
Before HTTP/3.0, it was based on the TCP protocol, but HTTP/3.0 will abandon TCP in favor of the UDP-based QUIC protocol:
- HTTP/1.x and HTTP/2.0: Both versions of the HTTP protocol are explicitly built on top of TCP. TCP provides reliable, connection-oriented transmission, ensuring that data arrives in order and without errors, which is crucial for the correct display of web content. Before sending an HTTP request, a connection must first be established through TCP’s three-way handshake.
- HTTP/3.0: This is a significant change. HTTP/3 abandons TCP and instead uses the QUIC protocol, which is built on UDP.
Why does HTTP/3 make this change? There are two main reasons:
- To solve the Head-of-Line Blocking (HOL blocking) problem.
- To reduce connection establishment latency.
Next, we will detail these two optimizations.
In HTTP/2, although multiple request/response streams can be transmitted concurrently over a single TCP connection (multiplexing), the characteristics of TCP (ensuring order and reliability) mean that if a TCP packet from one stream is lost or delayed, the entire TCP connection will be blocked, waiting for that packet to be retransmitted. This affects all HTTP/2 streams on that TCP connection, even if packets from other streams have already arrived.QUIC (running on UDP) solves this problem. QUIC implements its own multiplexing and flow control mechanisms internally. Different HTTP request/response streams are truly independent at the QUIC level. If a packet from one stream is lost, it only blocks that stream and does not affect other streams on the same QUIC connection (essentially multiplexing + polling), greatly improving the efficiency of concurrent transmission.
In addition to solving the Head-of-Line Blocking problem, HTTP/3.0 can also reduce the latency of the handshake process. In HTTP/2.0, to establish a secure HTTPS connection, it requires both a TCP three-way handshake and a TLS handshake:
- TCP three-way handshake: The client and server exchange SYN and ACK packets to establish a TCP connection. This process requires 1.5 RTT (round-trip time), which is the time it takes for a packet to be sent and received.
- TLS handshake: The client and server exchange keys and certificates to establish a TLS encryption layer. This process requires at least 1 RTT (TLS 1.3) or 2 RTTs (TLS 1.2).
Therefore, establishing a connection in HTTP/2.0 requires at least 2.5 RTTs (TLS 1.3) or 3.5 RTTs (TLS 1.2). In contrast, in HTTP/3.0, the QUIC protocol used (TLS 1.3, which supports both 1 RTT and 0 RTT handshakes) allows connection establishment in just 0-RTT or 1-RTT. This means that QUIC can establish a new connection without any additional round-trip time in the best case.
Relevant proof can be found in the following two links:
- https://zh.wikipedia.org/zh/HTTP/3
- https://datatracker.ietf.org/doc/rfc9114/
⭐ Recommended Reading:
- Why do you choose JWT for authentication? What issues need to be considered?
- How to use the Session-Cookie scheme for authentication? How to do it under multiple server nodes?
- How to determine if a number is among 1 billion unique numbers?
📌 For Java backend technical interview preparation, I highly recommend “Java Interview Guide” and JavaGuide, which have over 400 contributors maintaining high quality. Additionally, the current interview trend is shifting towards scenario-based questions, so you can refer to “High-Frequency System Design & Scenario Questions for Backend Interviews” (20+ high-frequency system design & scenario interview questions) for preparation!