Author: hand do not touch the link: www.zhihu.com/question/41… The copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please indicate the source.

This answer happens to cover some details of THE RPC communication protocol, but again, the communication protocol is not the most important part of RPC. Don’t let this answer take you away from it. To learn more about RPC to learn more about some of the basic policies of service Governance (SOA), dubbo’s documentation is recommended.

First of all, HTTP and RPC are not parallel concepts.

RPC is a remote procedure call whose call protocol usually includes transport protocol and encoding protocol.

Transport protocols include: http2 used by the famous [gRPC](gRPC/grpc. IO), and TCP used for custom packets such as Dubbo.

Encoding protocols include: XML JSON based on text encoding, and Protobuf binpack based on binary encoding.

So I understand that the question you want to ask is: why use RPC with custom TCP protocol for back-end process communication?

To solve this problem, we should understand the difference between THE TCP protocol used by HTTP and our custom TCP protocol in the packet.

The first is to deny the fact that HTTP is more expensive in connection establishment and disconnection than custom TCP. The HTTP protocol supports connection pool multiplexing, which means that a certain number of connections are continuously opened and connections are not frequently created or destroyed. It is important to note that HTTP can also encode content using protobuf, a binary encoding protocol, so the biggest difference between the two is the transport protocol.

TCP packets of the generally defined HTTP1.1 protocol contain too much invalid information. The format of a POST protocol is as follows

HTTP/1.0 200 OK Content-Type: text/plain Content-Length: 137582 Expires: Thu, 05 Dec 1997 16:00:00 GMT last-Modified: Wed, 5 August 1996 15:55:28 GMT Server: Apache 0.84 < HTML > <body>Hello World</body> </ HTML >Copy the code

Even though the encoding protocol (body) is a binary encoding protocol, the message metadata (key-value pair of header header) is text encoded, which is very much in bytes. As shown in the figure above, the number of valid bytes in the packet only accounts for about 30%, that is, 70% of the time is used to transmit metadata waste codes. Of course, the actual message content may be longer than that, but the percentage of headers is still significant.

So suppose we use a custom TCP packet as follows

&amp; lt; img data-rawheight=&quot; 188&quot; src=&quot;Pic3.zhimg.com/50/v2-89c90…; data-rawwidth=&quot; 1220&quot; class=&quot; origin_image zh-lightbox-thumb&quot; width=&quot; 1220&quot; data-original=&quot; https://pic3.zhimg.com/v2-89c905b0806577471aa7789a25ac0d44_r.jpg&quot; &amp; gt;

The header takes up only 16 bytes, greatly simplifying the transmission.

This is why back-end processes often use RPC with a custom TCP protocol to communicate with each other.

— Dividing line 2017.08.03 —

Perhaps the answer was not clearly described, and this answer was only used to correct victory’s answer. The efficiency advantage is for the HTTP1.1 protocol, which has been optimized for coding efficiency, and RPC libraries like GRPC use the HTTP2.0 protocol. To put it this way, HTTP containers are typically measured in KQPS, while custom TPC protocols are typically measured in 10kqps to 100kqps

In short, mature RPC libraries encapsulate more advanced service-oriented features such as “service discovery” and “error retry” than HTTP containers. It can be understood that the RPC framework is a more advanced encapsulation of service orientation. If you wrap an HTTP Server container with a layer of service discovery and function proxy calls, it can already be an RPC framework.

So why use RPC calls?

Because good RPC calls are service-oriented encapsulation, they are optimized for service availability and efficiency. Using HTTP calls alone lacks these features.