Why Is RPC Faster Than HTTP? An In‑Depth Comparison for Interviews

Interview Focus Points

Protocol Understanding: Interviewers expect you to discuss HTTP/1.1 header overhead and how RPC frameworks streamline the protocol.

Serialization Mechanism: Compare text‑based JSON/XML with binary formats such as Protobuf, Hessian, and explain the performance gap.

Connection Management: Show awareness of long‑connection reuse and connection‑pool impact versus HTTP short‑connection overhead.

Engineering Analysis: Be able to state that RPC is not always faster—HTTP/2 and gRPC have reduced the difference.

Core Answer

In short, RPC beats traditional HTTP/1.1 + JSON for four main reasons:

Protocol format: Custom binary protocol with a fixed 16‑byte header versus bulky text headers (300‑800 bytes per request).

Serialization: Binary serialization (Protobuf/Hessian) is 5‑20× faster and produces 30‑60% smaller payloads than JSON.

Connection model: Persistent long connections with connection pools eliminate repeated TCP handshakes.

Network model: NIO/Epoll‑based Netty handles many concurrent connections with few threads, giving a higher throughput ceiling.

1. Protocol Format – "Bulky" vs "Slim"

HTTP/1.1 sends headers such as Content-Type, User-Agent, Accept on every request, which are irrelevant for internal service calls but must be parsed. Dubbo’s protocol header is a fixed 16‑byte binary structure (Magic Number + Flag + Status + Request ID + Data Length), containing no redundant fields. In high‑frequency calls, the header size difference (hundreds of bytes vs 16 bytes) is amplified.

2. Serialization – Text vs Binary

JSON includes field names, ASCII‑encoded numbers, and punctuation, inflating payload size. Protobuf replaces field names with numeric tags and uses Varint encoding, cutting data size roughly in half. Benchmarks on the same complex object (10 × 10⁴ serializations) show:

Serialization   Serialize   Deserialize   Size
JSON (Jackson)   ~5 ms       ~8 ms          100%
Hessian2         ~3 ms       ~4 ms          ~60%
Protobuf         ~1 ms       ~1.5 ms        ~30%
Kryo             ~0.8 ms     ~1 ms          ~35%

3. Connection Model – Short vs Long

HTTP/1.1 can keep connections alive, but browsers and many clients reuse them inefficiently. RPC frameworks (Dubbo, gRPC) are built on long‑living TCP connections with connection pools, allowing multiple concurrent requests over a single socket. Each TCP three‑way handshake costs ~1.5 RTT (plus TLS overhead), which becomes significant in high‑QPS scenarios.

4. Network Model – BIO vs NIO

Traditional HTTP servers often use a blocking I/O (BIO) model—one thread per request—leading to massive thread counts and context‑switch overhead under load. Modern RPC frameworks run on Netty’s NIO/Epoll model, handling thousands of connections with a thread pool sized to CPU cores, reducing context switches and lock contention.

Additional Optimizations in RPC Frameworks

Service discovery: Built‑in registries (Nacos, ZooKeeper) automatically track service instances.

Smart routing: Weight‑based, consistent‑hash, and same‑zone preferences.

Circuit breaking: Integration with Sentinel, Hystrix for fast failure.

Generic invocation: Calls without client SDK by sending raw parameters.

Common Misconceptions

Misconception: HTTP is always slower than RPC.

HTTP/2 introduces binary framing, multiplexing, and header compression (HPACK), dramatically improving performance. gRPC, built on HTTP/2 + Protobuf, achieves latency and throughput comparable to traditional RPC frameworks.

High‑Frequency Follow‑Up Questions

Why still use HTTP if RPC is better? – HTTP offers universal compatibility, browser support, and ecosystem tools (API gateways, CDNs, firewalls). Typical architecture: external APIs use HTTP, internal microservice calls use RPC.

Is gRPC an RPC or HTTP? – gRPC is an RPC framework that uses HTTP/2 as the transport layer and Protobuf for serialization, combining HTTP’s universality with RPC’s performance.

Performance gap between Dubbo and Spring Cloud OpenFeign? – Dubbo (custom TCP + Hessian2/Protobuf) usually delivers 2‑5× higher throughput and 30‑50% lower latency than OpenFeign (HTTP + JSON) on identical hardware, though Spring Cloud 6’s gRPC support narrows the gap.

Memory Mnemonic

RPC’s speed advantages can be remembered as "精、二、长、N" (Jing, Er, Chang, N):

精 – Protocol is concise (16‑byte header).

二 – Binary serialization reduces size and speeds up processing.

长 – Long‑lived connections reuse TCP handshakes.

N – NIO network model handles high concurrency with few threads.

Conclusion

RPC outperforms traditional HTTP/1.1 + JSON because its protocol is leaner, its serialization is binary and faster, it reuses long connections, and it runs on an efficient NIO network model. However, HTTP/2 + gRPC has largely closed the gap, so interview answers should emphasize the specific contrast between HTTP/1.1 + JSON and custom binary RPC rather than a blanket claim that HTTP is always slower.