Why TCP, HTTP, and RPC Aren’t Competing – They’re Successive Abstractions

Network Protocols as a Delivery System

Think of network communication like sending a package. TCP acts as the logistics company that guarantees delivery without caring about the package contents, while HTTP adds a standardized envelope and postal rules, and RPC provides a private concierge service that lets developers invoke remote methods as if they were local.

TCP – The Logistics Company

Guarantees no loss, ordering, or corruption of data.

Handles retransmission, checksum, and flow control.

Ignores the payload – it only ensures the package arrives.

HTTP – Standard Envelope + Postal Rules

Built on top of TCP, HTTP defines how to write the envelope (URL, headers, body), the delivery process (request/response), and the operation semantics (GET, POST, PUT, DELETE).

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

Key benefits of HTTP:

Standardization : Any language or system can interoperate.

Statelessness : Naturally supports horizontal scaling.

Extensibility : Headers can be extended indefinitely.

Human‑readable : Easy to debug and troubleshoot.

Cross‑platform : Browsers support it out of the box.

Drawbacks include high serialization cost, header bloat, and limited ability to express complex business semantics.

RPC – Private Concierge Service

RPC (Remote Procedure Call) lets developers call remote services with the same syntax as local method calls, abstracting away networking, serialization, retries, and load balancing.

User user = userService.getUserById(123);
Order order = orderService.createOrder(user, items);

Developers only care about method name, parameters, and return value; the framework handles connection, serialization, timeout, retry, and load balancing.

Three Generations of Abstraction

1️⃣ Bare TCP Era (1980s)

socket = connect("192.168.1.1:8080")
send(socket, raw_data)
response = receive(socket)

Problems: disparate data formats, manual packet framing, no unified semantics, and poor interoperability.

2️⃣ HTTP Unifies the World (1990s)

Goal: enable every system to converse using a common language, sacrificing some performance for universal connectivity, browser ecosystem, and REST architecture.

3️⃣ RPC Returns (2000s‑Present)

With micro‑services, the number of services explodes, call chains grow, and performance and governance become critical, leading to the resurgence of RPC frameworks such as gRPC, Thrift, and Dubbo.

Key Insight: RPC Shifts Complexity, Not Performance

RPC is often mistaken for a speed boost, but its real value is moving distributed‑system complexity from business code into infrastructure and frameworks.

HTTP vs RPC – Core Comparison

Dimension          HTTP/REST                RPC (gRPC)
-----------------------------------------------------
Call style          Manual request          Local‑method call
Contract            Documentation           Strong IDL contract
Error handling      Loose                  Typed, framework‑driven
Retry/Timeout       Business‑level handling  Built‑in by framework
Data format         JSON / XML               Protobuf (binary)
Performance         Medium                  High
Coupling            Loose                   Tight
Browser support     Native                  Requires gateway
Evolution           Flexible                Requires version governance
Scope               External APIs            Internal services

Why “External HTTP, Internal RPC”?

The decisive factor is organizational boundaries: external systems are uncontrolled, diverse, and cannot enforce version upgrades, so a flexible, loosely‑coupled HTTP interface is preferred; internal systems share the same organization, allowing strict contracts and coordinated evolution via RPC.

Pitfall of RPC – Version Governance

Strong dependence on IDL.

Interface changes require full‑chain upgrades.

High cost for gray‑release and compatibility.

REST tolerates “dirty” interfaces; RPC demands “clean” contracts.

HTTP/2 + Protobuf ≠ gRPC

While you can combine HTTP/2 with Protobuf, gRPC adds a complete engineering ecosystem: IDL, code generation, interceptors, load balancing, circuit breaking, and observability. The difference is the surrounding infrastructure, not just the transport and serialization.

Service Mesh – The Next Step for RPC

Service Mesh abstracts RPC governance out of SDKs into the infrastructure layer, providing language‑agnostic, unified control, and allowing business code to remain pure.

Evolution Summary (One‑Line Diagram)

Reliability (TCP)
   ↓
Standardization (HTTP)
   ↓
Development Efficiency (RPC)
   ↓
Infrastructure Abstraction (Service Mesh)

Final Takeaways

TCP is the foundation.

HTTP is the universal specification.

RPC is an engineering encapsulation for internal services.

There is no winner‑takes‑all; the optimal combination depends on the scenario: small systems favor simplicity, large systems prioritize efficiency.

Understand the problem each layer solves, and you won’t be stuck debating “HTTP or RPC”.