HTTP就是一種RPC,
只要是遠程調用都可以叫RPC，和是不是通過http沒什么關系。
http好比普通話，rpc好比團伙內部黑話。
講普通話，好處就是誰都聽得懂，誰都會講。
講黑話，好處是可以更精簡、更加保密、更加可定制，壞處就是要求“說”黑話的那一方（client端）也要懂，而且一旦大家都說一種黑話了，換黑話就困難了。首先 http 和 rpc 並不是一個並行概念。
rpc是遠端過程調用，其調用協議通常包含傳輸協議和序列化協議。
傳輸協議包含: 如著名的 [gRPC](grpc / grpc.io) 使用的 http2 協議，也有如dubbo一類的自定義報文的tcp協議。
序列化協議包含: 如基於文本編碼的 xml json，也有二進制編碼的 protobuf hessian等。
因此我理解的你想問的問題應該是：為什么要使用自定義 tcp 協議的 rpc 做后端進程通信？
要解決這個問題就應該搞清楚 http 使用的 tcp 協議，和我們自定義的 tcp 協議在報文上的區別。
首先要否認一點 http 協議相較於自定義tcp報文協議，增加的開銷在於連接的建立與斷開。http協議是支持連接池復用的，也就是建立一定數量的連接不斷開，並不會頻繁的創建和銷毀連接。二一要說的是http也可以使用protobuf這種二進制編碼協議對內容進行編碼，因此二者最大的區別還是在傳輸協議上。
通用定義的http1.1協議的tcp報文包含太多廢信息，一個POST協議的格式大致如下
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>
即使編碼協議也就是body是使用二進制編碼協議，報文元數據也就是header頭的鍵值對卻用了文本編碼，非常占字節數。如上圖所使用的報文中有效字節數僅僅占約 30%，也就是70%的時間用於傳輸元數據廢編碼。當然實際情況下報文內容可能會比這個長，但是報頭所占的比例也是非常可觀的。
那么假如我們使用自定義tcp協議的報文如下
報頭占用的字節數也就只有16個byte，極大地精簡了傳輸內容。
這也就是為什么后端進程間通常會采用自定義tcp協議的rpc來進行通信的原因。
所謂的效率優勢是針對http1.1協議來講的，http2.0協議已經優化編碼效率問題，像grpc這種rpc庫使用的就是http2.0協議。這么來說吧http容器的性能測試單位通常是kqps，自定義tpc協議則通常是以10kqps到100kqps為基准
簡單來說成熟的rpc庫相對http容器，更多的是封裝了“服務發現”，"負載均衡"，“熔斷降級”一類面向服務的高級特性。可以這么理解，rpc框架是面向服務的更高級的封裝。如果把一個http servlet容器上封裝一層服務發現和函數代理調用，那它就已經可以做一個rpc框架了。
所以為什么要用rpc調用？
因為良好的rpc調用是面向服務的封裝，針對服務的可用性和效率等都做了優化。單純使用http調用則缺少了這些特性。
參考 https://www.zhihu.com/question/41609070/answer/191965937