I remember when I first started working and encountered the concept of RPC; I was filled with confusion—if HTTP works just fine, why create RPC? It wasn’t until I participated in several microservices projects that I truly understood the value of each. Today, let’s clarify the relationships between these protocols.
Starting from Network Basics: The Capabilities and Limitations of TCP
When I first started with network programming, I thought TCP was perfect—it could establish stable connections, ensure reliable data transmission, and handle network congestion. This seemed to cover all the needs of network communication.
However, in actual development, I encountered a fundamental yet critical issue:
// The sender continuously sends two independent messages
socket.write("Hello");
socket.write("World");
// The receiver might receive: "HelloWorld"
// Completely unable to distinguish the original message boundariesThis is a typical manifestation of the TCP sticky packet problem. The byte stream characteristic of TCP means it is only responsible for reliably transmitting byte sequences, without caring about how these bytes should be organized into meaningful business messages.
Three Core Features of TCP:
- • Connection-oriented: A connection must be established through a three-way handshake before communication
- • Reliable transmission: Ensures data is reliably delivered through acknowledgment, retransmission, and ordering mechanisms
- • Byte stream-based: Data has no natural boundaries, just a continuous sequence of bytes (binary)
My Personal Understanding: TCP is like a reliable logistics system that ensures all goods are delivered, but mixes all packages together for delivery—while the goods do arrive, the receiver needs to sort and organize them again.
The Emergence of the HTTP Protocol: Giving Meaning to Data
In light of TCP’s limitations, application layer protocols emerged. The HTTP protocol solves the issues of message boundaries and semantic expression by defining a clear message format on top of TCP.
HTTP defines message boundaries through a standard message structure:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 48
{"name": "Alice", "email": "[email protected]"}The key lies in the <span>Content-Length: 48</span> header—it explicitly tells the receiver the exact length of the message body, thus solving the TCP sticky packet problem.
The Main Values of the HTTP Protocol:
- • Defines message boundaries: Identifies message ranges through Content-Length or chunked encoding
- • Standardizes communication semantics: Standard methods like GET, POST, PUT, DELETE
- • Rich capability extensions: Cache control, content negotiation, state management
- • Universal compatibility: Supported by all major platforms and languages
Conclusion: TCP solves the problem of “reliable transmission,” while application layer protocols like HTTP solve the problems of “what to transmit” and “how to parse.”
New Confusion: Why Introduce RPC on Top of HTTP?
With the development of distributed systems, it has become apparent that service calls based on HTTP can be inconvenient:
// HTTP-based service calls require a lot of boilerplate code
HttpClient client = HttpClients.createDefault();
HttpPost post = new HttpPost("http://user-service/getUser");
post.setHeader("Content-Type", "application/json");
String jsonBody = "{\"user_id\": 123}";
post.setEntity(new StringEntity(jsonBody));
HttpResponse response = client.execute(post);
if (response.getStatusLine().getStatusCode() == 200) {
String responseBody = EntityUtils.toString(response.getEntity());
User user = objectMapper.readValue(responseBody, User.class);
}
// Too many low-level details to handle!Each call requires handling HTTP status codes, exceptions, serialization, and deserialization, leading us to ponder:Can we make remote service calls as simple as calling local methods?
The Core Idea of RPC: Transparent Remote Calls
RPC (Remote Procedure Call), also known as remote procedure invocation, aims to make remote service calls transparent to developers.
// Ideal RPC call method
User user = userService.getUser(123);
// Instead of handling various network communication detailsClarification of Important Concepts (Based on Personal Understanding): RPC itself is not a specific protocol, but a calling paradigm or technical idea. Its core goal is to allow programmers to call remote services as if they were calling local methods.
However, we cannot say “using RPC protocol” because RPC itself is not a protocol.
Correct Expressions:
- • ✅ “We use gRPC protocol for RPC calls”
- • ❌ “We use RPC protocol”
Because RPC itself is not a protocol, but gRPC, Thrift, Dubbo, etc., are specific protocol implementations.
The Relationship Between RPC and HTTP: Different Dimensions of Technology
The relationship between RPC and HTTP is where confusion often arises. Through learning and practice, I personally understand that:
RPC and HTTP are fundamentally not at the same technical level:
- • RPC is a calling paradigm, corresponding to local method calls
- • HTTP is a specific application layer protocol
- • RPC can be implemented over HTTP or through custom TCP or UDP protocols
For example, gRPC chooses to implement over HTTP/2, while many early RPC frameworks used custom TCP binary protocols.
The Complete Ecosystem of RPC Protocols and Frameworks
RPC Protocol: The Basic Communication Specification
The protocol mainly defines three core aspects:
- 1. Message format: Defines how messages start, end, and the structure of headers and bodies
- 2. Serialization method: Specifies how data is encoded and decoded
- 3. Transmission rules: Determines the communication process and interaction patterns
RPC Framework: A Complete Solution Based on Protocols
Modern RPC frameworks provide enterprise-level capabilities on top of basic protocols:
- • Core layer: Implements the communication protocol itself
- • Component layer: Provides basic components like serialization, service discovery, load balancing
- • Governance layer: Includes operational capabilities like fault tolerance, monitoring, registration center
- • Application layer: Allows developers to transparently perform remote method calls
Summary: The protocol defines how machines communicate, while the framework allows developers to focus on business logic without worrying about the communication process.
Technical Selection in Modern Architectures: Division of Labor
Through participation in actual projects, I gradually understood the division of labor principles between HTTP and RPC in modern architectures. For most companies, it is generally as follows.
Internal Service Calls: The Advantageous Domain of RPC Frameworks
Within microservice architectures, RPC frameworks have become the preferred choice due to their performance advantages:
The high performance of RPC mainly comes from:
- 1. Efficient serialization
// JSON serialization: good readability but large size {"id": 123, "name": "Alice", "age": 30} // about 40 bytes // Protobuf binary: small size, fast parsing \x08\x7B\x12\x05Alice\x18\x1E // only 11 bytes // Size reduced by over 70%, serialization speed significantly improved - 2. Protocol overhead optimization
- • Long connections reduce TCP handshake overhead
- • Multiplexing improves connection utilization
- • Header compression reduces the amount of data transmitted
- • Streamlined protocol header design
- • Binary encoding efficiency
- • Zero-copy and other technology applications
External API Exposure: The Irreplaceability of HTTP Protocol
When it comes to providing APIs to external parties, the HTTP protocol demonstrates its unique value:
The General Advantages of HTTP:
- • Unmatched ecosystem: All platforms, languages, and devices support HTTP
- • Mature toolchain: Debugging tools like browsers, Postman, curl
- • Network friendliness: Ports 80/443 are generally open
- • Easy testing and debugging: Directly test through browsers or command-line tools
// Frontend calling HTTP API is simple and direct
fetch('/api/users/123')
.then(response => response.json())
.then(user => {
displayUser(user);
});Real-World Architectural Practices
The typical architecture of modern internet companies reflects a clear layered design:
The Wisdom of This Architecture:
- • Internal and external differentiation: Ensures compatibility externally while pursuing performance internally
- • Separation of concerns: The gateway handles cross-cutting concerns, while business services focus on core logic
- • Protocol conversion: Completes the conversion from HTTP to RPC at the gateway layer
Summary and Core Points
In summary of the article content:
Technical Evolution Path:
- 1. TCP Layer: Solves the reliable transmission problem at the network layer
- 2. HTTP Layer: Solves message format and semantic issues at the application layer
- 3. RPC Layer: Optimizes the service call experience in distributed systems
Best Practices in Modern Architecture:
- • Internal service calls: Prefer using RPC frameworks (like gRPC, Dubbo)
- • Core reason: Extreme performance. Binary encoding, low protocol overhead, long connection reuse
- • Exposing external interfaces: Generally use HTTP protocol (and RESTful style)
- • Core reason: Unmatched universality. Mature ecosystem, good client compatibility
Core Conclusion: This is a best practice of “internal and external differentiation”—performance-first internal clusters use RPC frameworks, while compatibility-first external open interfaces use HTTP protocol.
The content of this article is a personal understanding and summary from the author’s learning process, and there may be inaccuracies or misunderstandings. Readers are welcome to provide corrections.
Of course, I have also been practicing for two and a half years 😄, theoretically 🤌 it should be fine.
