HTTP vs RPC: How Much Slower Is HTTP Really? Benchmark Data Reveals the Truth

What Are We Actually Comparing?

Before diving into data, the author clarifies the comparison scope. In daily parlance, "HTTP" and "RPC" refer to two concrete technology stacks:

HTTP camp: HTTP protocol + JSON serialization (typical representatives: Spring Cloud OpenFeign, RestTemplate)

RPC camp: TCP private protocol or HTTP/2 + binary serialization (typical representatives: Dubbo, gRPC)

Therefore, the statement "HTTP is slower than RPC" should be precisely framed as: HTTP/1.1 + JSON is slower than binary protocol + Protobuf. All subsequent data rests on this baseline.

The Data Speaks

gRPC vs REST

First conclusion: gRPC vs REST throughput differs by ~1x, latency by ~50%.

Dataset 1 comes from markaicode.com's 2025 benchmark (gRPC+Protobuf vs REST+JSON).

Throughput comparison:

Small payload: gRPC 25,800 req/s vs REST 12,450 req/s (gRPC leads 107%)

1 MB payload: gRPC 2,350 req/s vs REST 1,250 req/s (gRPC leads 88%)

Latency comparison:

Avg latency (small): gRPC 12.8 ms vs REST 24.5 ms (REST +11.7 ms)

P99 latency (small): gRPC 29 ms vs REST 56 ms (REST +27 ms)

Avg latency (1 MB): gRPC 98 ms vs REST 175 ms (REST +77 ms)

P99 latency (1 MB): gRPC 185 ms vs REST 325 ms (REST +140 ms)

Resource consumption:

CPU: gRPC 58% vs REST 72% (REST 19% higher)

Memory: gRPC 2.5 GB vs REST 3.8 GB (REST 34% higher)

Network bandwidth: gRPC 0.86 Gbps vs REST 1.45 Gbps (REST 41% higher)

Protobuf-serialized messages are 60%-80% smaller than JSON, a gap that widens with large payloads.

100 Concurrency: RPS Up 140%

A CSDN blogger's October 2025 Python test (Flask REST vs gRPC, wrk tool) showed gRPC avg latency 19.5 ms, RPS 5,120; REST avg latency 48.2 ms, RPS 2,076. gRPC RPS improved over 140% with lower CPU (54% vs 67%), corroborating the first dataset.

Dubbo Official Benchmark

Dubbo 3.0 POJO return-value benchmark: Dubbo+Hessian2 achieved 12,279 ops/s (P99 5.7 ms), while Triple (HTTP/2+Protobuf) reached 6,255 ops/s (P99 8.9 ms). Two notable findings:

Dubbo's private TCP protocol remains strongest; fixed-header binary protocol excels in pure Java point-to-point calls.

Same HTTP/2+Protobuf, Triple is noticeably slower than Dubbo private protocol. Dubbo docs acknowledge HTTP/2-based protocols are at a disadvantage vs TCP for point-to-point; Triple's strengths lie in gateway traversal, universality, and streaming.

Adopting an RPC framework doesn't guarantee performance; protocol implementation details matter equally.

HTTP/1.1 vs HTTP/2

Protocol version alone can yield ~45% throughput gain. One test showed HTTP/2 throughput ~81,153 req/s (2.46 ms latency) vs HTTP/1.1 ~55,760 req/s (3.59 ms latency) — ~45% higher throughput, ~31% lower latency. With simulated 50 ms network latency, HTTP/1.1 load time 3.53 s vs HTTP/2 1.73 s — nearly 2x difference.

HTTP/2 solves three HTTP/1.1 pain points: binary framing replaces text headers, multiplexing eliminates head-of-line blocking, HPACK header compression reduces header size 50%-90%.

Serialization Standalone Comparison

Many blame HTTP protocol, but the real bottleneck is JSON serialization.

Same data structure: JSON ~1,000 bytes, Protobuf ~200-400 bytes (2-5x smaller)

Serialization speed: Protobuf typically 2-10x faster than JSON depending on structure

Dubbo ecosystem serialization comparison (complex nested objects): Kryo response 90 bytes, TPS 8,444; default Hessian2 response 329 bytes, TPS 6,701. Same binary protocol, different serialization implementation yields >20% TPS difference. Performance optimization is a chain, not a single choice.

A Counter-Intuitive Data Point

.NET ecosystem tests show for very small payloads, REST can slightly outperform gRPC; gRPC's advantage emerges only as payload grows. Benchmark results are highly scenario-dependent — message size, concurrency, link length all matter. Discussing pros/cons without these parameters is meaningless.

Can Your Business Perceive That 15%?

All above data comes from extreme stress-test scenarios. Back to real business math:

Typical request: DB query 30 ms, business logic 20 ms, HTTP communication ~24 ms, total ~74 ms. Switch to gRPC: communication drops to ~13 ms, total ~63 ms. Saved 11 ms, ~15% of total latency.

Can users perceive this 15%? Most likely not. That's why many OpenFeign teams run fine in production without feeling performance pain — the communication protocol was never their bottleneck. One team hit 5,000 QPS target with HTTP; bottleneck naturally sank to DB queries, not the protocol.

But if your scenario matches any below, the protocol gap amplifies and binary protocols deserve serious consideration:

Long call chains: 7-8 services per request, saving 10 ms each = hundreds of ms end-to-end

Extremely high frequency: QPS in tens of thousands, throughput and CPU/memory cost gaps scale linearly

Large payloads: Big object transfer, JSON bloat and serialization overhead spike

Poor network: Mobile, IoT, cross-datacenter calls, bandwidth-constrained environments where small packets are a hard advantage

Where Exactly Is HTTP Slow?

Saying "HTTP is slow" is inaccurate. The slowness comes from HTTP/1.1 + JSON in three specific areas:

Text Headers vs Binary Headers

HTTP/1.1 headers are plain text, e.g.:

GET /api/user/123 HTTP/1.1<br/>Host: user-service<br/>Content-Type: application/json<br/>Accept: application/json<br/>Authorization: Bearer eyJhbGciOi...

Every request carries this text header block; server parses character by character. Typical HTTP header ~300-800 bytes. Dubbo's header is fixed 16-byte binary; gRPC uses HTTP/2 binary frames + HPACK — far lower overhead. Per-request difference is small but accumulates under high concurrency.

JSON Serialization

Serialization is the true performance heavyweight. JSON is text-based; serialize/deserialize both require string parsing and memory allocation. Hessian2 is a good middle ground: binary, no IDL required, works out-of-the-box in Java, performance between JSON and Protobuf — hence Dubbo's default.

Connection Management

HTTP/1.1 head-of-line blocking is a hard flaw. Keep-Alive allows connection reuse, but one connection handles only one request at a time. To send 10 concurrent requests, you need 10 connections. Dubbo's TCP protocol multiplexes multiple requests over one connection via requestId matching; gRPC over HTTP/2 similarly multiplexes multiple streams per connection — far higher connection utilization.

gRPC Also Uses HTTP

Many treat HTTP and RPC as opposites. But consider:

What transport does gRPC use? HTTP/2.

What are gRPC's core optimizations? Protobuf serialization + multiplexing.

So gRPC essentially packages a best-practice combo: HTTP/2 + Protobuf + multiplexing. It doesn't bypass HTTP; it uses a better HTTP version with more efficient serialization.

If you switch Spring Cloud to HTTP/2 (e.g., WebFlux+Netty) and replace JSON with Protobuf, performance approaches gRPC. The real answer isn't "HTTP is slow" but " HTTP/1.1 + JSON this specific combo is slow".

Protocol version and serialization method are the decisive variables, not the four letters HTTP

.

Understanding this prevents being misled by the simplistic "HTTP is slow" conclusion during technology selection.

Conclusion

So, how much slower is HTTP than RPC?

Data-layer answer:

Throughput 1-2x lower, latency 30%-50% higher, resource consumption 20%-40% higher in stress tests

.

Engineering-layer answer: Slow is HTTP/1.1 + JSON, not HTTP; and this gap drowns in DB and business logic overhead in most businesses, imperceptible to users. The right move: use monitoring to find the real bottleneck first, then decide whether to pay for a protocol upgrade.

No silver bullet in tech selection — only scenarios. Don't let binary thinking limit your architecture!