What JEP 517’s QUIC-based transport actually means for your microservices, your latency, and your connection handling — explained simply.

1. The Background — Why TCP Was Holding Us Back

For decades, TCP was the unsung backbone of the internet. It was reliable, well-understood, and essentially everywhere. However, as microservice architectures grew in complexity and services started making hundreds of internal HTTP calls per second, TCP’s limitations became increasingly hard to ignore.

The most notorious of those limitations is something called head-of-line (HOL) blocking. In simple terms: if a single packet in a TCP stream gets lost or delayed on the network, every other request waiting in that stream has to pause and wait — even the completely unrelated ones. Think of it like a supermarket checkout where one slow transaction freezes every register in the store.

HTTP/2, which arrived in 2015, helped a lot. It introduced multiplexing — the ability to send multiple requests over a single connection simultaneously. But because it still ran on top of TCP, it couldn’t fully escape HOL blocking at the transport layer. The protocol was clever, but the foundation underneath hadn’t changed.

That is precisely the problem JEP 517 is designed to solve.

Quick Context HTTP/3 was standardised by the IETF back in 2022 (RFC 9114). By 2025, browsers had already adopted it widely and roughly a third of all websites supported it. Java’s built-in client, however, was still on HTTP/2 — until now.

2. What Exactly Is JEP 517?

JEP 517 is a Java Enhancement Proposal that updates the java.net.http.HttpClient — the built-in HTTP client added in JDK 11 — to support HTTP/3. JDK 26 reached General Availability on 17 March 2026, and JEP 517 shipped with it.

Although the enhancements to the HTTP Client API appear simple to use, supporting HTTP/3 on top of QUIC represents the result of several years of dedicated development effort within the JDK team.

Importantly, it is worth noting that support is only being added, but the default will remain HTTP/2, which has been the case since the HttpClient was initially added in JDK 11. In other words, your existing code continues to work exactly as before. You only get HTTP/3 when you ask for it — which is a sensible, low-risk approach to rolling out such a significant change.

HTTP Version Support in Java HttpClient

JEP 517 · JDK 26 GA · Existing code is unaffected — HTTP/3 activates only when explicitly requested

Meta description: JEP 517 brings HTTP/3 and QUIC-based transport to Java’s built-in HTTP Client in JDK 26. Learn what this means for microservice latency, connection handling, and service-to-service communication in plain language.

3. QUIC, Simply Explained

QUIC is the transport protocol underneath HTTP/3. Originally developed at Google and later standardised by the IETF, it swaps TCP for UDP as its foundation. Now, UDP has traditionally been associated with “fire and forget” — no ordering, no guarantees. QUIC, however, layers reliability, ordering, and security directly on top of UDP, giving you the best of both worlds.

Here is why that matters in practice. With QUIC, each request stream is truly independent at the transport level. If a packet belonging to one stream is dropped on the network, only that stream pauses momentarily. All other streams in the same connection keep flowing at full speed. For a microservice making ten parallel API calls, this difference can be meaningful — especially in cloud environments where packet loss is a real, everyday occurrence.

Additionally, QUIC merges the connection handshake and the TLS handshake into a single step. This results in dramatically reduced connection times — around 20–50 ms for HTTP/3, compared to HTTP/2’s 40–100 ms. And for repeat connections to the same server, QUIC supports 0-RTT resumption, meaning data can start flowing with the very first packet — no round-trip required to re-establish the session.

0-RTT in Plain English: Imagine picking up a phone call with an old colleague. Instead of the usual “Hi, it’s me, do you remember…” formalities, you jump straight into the conversation because you already know each other. QUIC’s 0-RTT does the same thing for your service-to-service connections.

4. The Latency Picture — Real Numbers

So what does this actually look like in practice? Fortunately, there is real-world data to look at. The improvements are most pronounced under two specific conditions: high-latency networks (like intercontinental calls) and packet-loss scenarios (common in cloud and containerised environments). Let’s look at the numbers.

Time to First Byte — HTTP/1.1 vs HTTP/2 vs HTTP/3

Response Latency Under Packet Loss Conditions

The numbers tell a clear story. A Catchpoint study highlighted HTTP/3’s advantages under high-loss conditions: testing across six countries showed HTTP/3 achieved a 41.80% reduction in median Time To First Byte (TTFB), demonstrating faster initial server responses.

Furthermore, faster connections: HTTP/3 sets up connections up to 50% faster than HTTP/2, and reduces latency by 55% on high-loss networks. For microservice teams running workloads in cloud regions with variable network quality, these are not marginal gains.

5. What Changes for Connection Handling

Beyond raw latency, there is another dimension that matters a great deal for service-to-service communication: how connections are managed over time. This is where QUIC introduces some genuinely new behaviours worth understanding.

5.1 Connection Migration

TCP ties a connection to a specific combination of IP address and port. Change either one — say, a pod restarts in Kubernetes and gets a new IP — and the TCP connection is dead. You need to reconnect from scratch. QUIC, on the other hand, identifies connections using a connection ID that is independent of the network address. This means a service can migrate from one network endpoint to another without dropping the connection. For containerised microservices that scale up and down regularly, this is a notable reliability improvement.

5.2 Multiplexing Without Head-of-Line Blocking

HTTP/3 uses the QUIC reliable transport-layer protocol rather than TCP, which provides more reliable transport, especially in environments with high rates of packet loss. Streams inside a QUIC connection are truly independent, so a delayed packet in one request stream never holds up the others. Under HTTP/2, the TCP layer could not make this distinction.

5.3 Built-In Encryption

With TCP-based protocols, TLS is an additional layer you bolt on top. With QUIC, TLS 1.3 is non-negotiable — it is woven into the protocol itself. For microservice teams that already enforce mutual TLS, this doesn’t change much. But it does mean there is no way to accidentally deploy an unencrypted HTTP/3 connection, which is a welcome security default.

6. The Opt-In Model and How It Works

One of the most thoughtful design decisions in JEP 517 is how discovery and fallback work. Since it is impossible to know ahead of time whether a target server supports HTTP/3, the client needs a strategy. There are two main approaches available.

The first is setting the preferred version at the HttpClient level. When you do this, the client attempts both an HTTP/3 connection and an HTTP/2 connection in parallel, and uses whichever succeeds first — a “happy eyeballs” style approach. If the UDP-based QUIC connection attempt fails, either because the server does not support HTTP/3 or if the connection does not complete in a timely manner, the client automatically downgrades to HTTP/2, and then HTTP/1.1 if needed.

The second approach is setting the preference at the HttpRequest level. Here, the client tries HTTP/3 first, and only falls back if it cannot connect at all. This is more deliberate — you’re expressing a stronger preference for HTTP/3 on a specific call.

Here is what the basic opt-in looks like at the client level:

Java — HttpClient with HTTP/3 preference (JDK 26+)

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;

// Build a client that prefers HTTP/3, falls back to HTTP/2 automatically
HttpClient client = HttpClient.newBuilder()
    .version(HttpClient.Version.HTTP_3)
    .build();

HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("https://your-service.internal/api/data"))
    .GET()
    .build();

HttpResponse<String> response = client.send(
    request,
    HttpResponse.BodyHandlers.ofString()
);

System.out.println("Protocol: " + response.version());
System.out.println("Body: " + response.body());

No Rewrite Required: The API change here is minimal by design. You are essentially changing one line — the .version() call. Everything else stays the same: the builder pattern, the request structure, the response handling. JEP 517 was specifically designed to require minimal code changes.

7. Protocol Comparison at a Glance

To make this tangible, here is how the three HTTP versions compare across the dimensions that matter most for microservice communication:

8. Concrete Implications for Microservice Teams

Let’s get practical. If you’re building or maintaining a microservice architecture on the JVM, here are the scenarios where adopting HTTP/3 is likely to give you a measurable edge — and where it probably won’t change much at all.

8.1 Where HTTP/3 Will Make a Difference

Cross-region service calls. If your architecture spans multiple cloud regions or availability zones, latency between services is already elevated. QUIC’s faster handshake and 0-RTT resumption directly reduce the overhead on every new connection to those remote services.

Environments with packet loss. Kubernetes clusters and cloud VMs see real packet loss, especially under heavy load. Since HTTP/3 streams are independent at the transport level, a dropped packet in one request doesn’t cascade to delay others sharing the same connection. Under HTTP/2, it does.

Frequently reconnecting clients. Services that create new HTTP connections often — for instance, short-lived Lambda functions or horizontally scaled pods — benefit from the faster 1-RTT and 0-RTT connection setup. Less time establishing connections means more time doing actual work.

Mobile-facing API gateways. A 2025 Akamai report shows HTTP/3 reduces latency by 30% on mobile networks. If your Java gateway serves mobile clients, enabling HTTP/3 on the client side — and ensuring your upstream supports it — is worth evaluating.

8.2 Where the Gains Are More Modest

On the other hand, for same-datacenter service calls over stable, low-latency connections, HTTP/2 is already very fast. HTTP/3’s performance benefits are more situational, showing the strongest gains for mobile users on unstable networks, high-latency connections, and returning visitors. Internal calls over a well-managed private network may see little to no improvement — and that’s fine. The point is to understand where the protocol change pays off.

Adoption Strategy: A sensible rollout approach: start by enabling HTTP/3 on services that communicate cross-region or with external APIs. Measure TTFB and error rates before and after. Once you have confidence in the behaviour, broaden adoption to other service boundaries. The auto-fallback in JEP 517 means a misconfigured or unsupported endpoint will simply revert to HTTP/2, so the risk of breakage is low.

9. Current Limitations Worth Knowing

JEP 517 is a first implementation, and the JDK team has been transparent about its current boundaries. Being aware of these upfront will save you from unexpected surprises in production.

It is also worth noting that while HTTP/3 is already supported by most web browsers and deployed on about a third of all websites, the server landscape varies. Before routing service traffic over HTTP/3, verify that your upstream services — or the load balancers in front of them — actually support it. The JEP 517 fallback mechanism covers you if they don’t, but it’s better to verify upfront.

10. What We Have Learned

JEP 517, shipping in JDK 26, marks a genuinely significant moment for Java developers. After years of HTTP/3 being a browser-only story, the JVM now has first-class support for QUIC-based transport — built directly into the standard library, with no external dependencies required.

• HTTP/3 replaces TCP with QUIC (UDP), eliminating head-of-line blocking at the transport layer and enabling faster connection setup.
• The Java HttpClient API change is intentionally minimal — one line of configuration unlocks HTTP/3 with automatic fallback to HTTP/2.
• Real-world benchmarks show up to 41.8% TTFB reduction and up to 55% latency improvement on packet-loss-prone networks.
• The biggest wins for microservice teams are in cross-region calls, unstable network conditions, and frequently reconnecting clients.
• Current limitations include client-side only support and early-stage maturity — production adoption should be phased and measured.
• TLS 1.3 is mandatory with QUIC, which improves baseline security with no extra configuration required.

As the ecosystem matures and server-side QUIC support becomes more widespread, HTTP/3 will likely become the default for new Java service-to-service communication. For now, the opt-in model in JEP 517 gives teams a safe, incremental path to get there.