這個回答裡恰巧講了一些rpc通訊協議的細節，但是強調一遍通訊協議不是rpc最重要的部分，不要被這個回答帶偏了。如果要了解rpc請更多的去了解服務治理(soa)的一些基本策略,推薦去看看dubbo的文件。
這個問題其實是有理解誤區的，首先 http 和 rpc 並不是乙個並行概念。
rpc是遠端過程呼叫，其呼叫協議通常包含傳輸協議和編碼協議。
傳輸協議包含: 如著名的 [grpc](grpc / grpc.io) 使用的 http2 協議，也有如dubbo一類的自定義報文的tcp協議。
編碼協議包含: 如基於文字編碼的 xml json，也有二進位制編碼的 protobuf binpack 等。
因此我理解的你想問的問題應該是：為什麼要使用自定義 tcp 協議的 rpc 做後端程序通訊？
要解決這個問題就應該搞清楚 http 使用的 tcp 協議，和我們自定義的 tcp 協議在報文上的區別。
首先要否認一點 http 協議相較於自定義tcp報文協議，增加的開銷在於連線的建立與斷開。http協議是支援連線池復用的，也就是建立一定數量的連線不斷開，並不會頻繁的建立和銷毀連線。二一要說的是http也可以使用protobuf這種二進位制編碼協議對內容進行編碼，因此二者最大的區別還是在傳輸協議上。
通用定義的http1.1協議的tcp報文包含太多廢資訊，乙個post協議的格式大致如下
即使編碼協議也就是body是使用二進位制編碼協議，報文元資料也就是header頭的鍵值對卻用了文字編碼，非常佔位元組數。如上圖所使用的報文中有效位元組數僅僅占約 30%，也就是70%的時間用於傳輸元資料廢編碼。當然實際情況下報文內容可能會比這個長，但是報頭所佔的比例也是非常可觀的。
那麼假如我們使用自定義tcp協議的報文如下
這也就是為什麼後端程序間通常會採用自定義tcp協議的rpc來進行通訊的原因。
-- 分割線 2017.08.03 --
可能回答裡面沒有描述清楚，這個回答僅僅是用來糾正victory的回答的。所謂的效率優勢是針對http1.1協議來講的，http2.0協議已經優化編碼效率問題，像grpc這種rpc庫使用的就是http2.0協議。這麼來說吧http容器的效能測試單位通常是kqps，自定義tpc協議則通常是以10kqps到100kqps為基準
簡單來說成熟的rpc庫相對http容器，跟多的是封裝了「服務發現」，"錯誤重試"一類面向服務的高階特性。可以這麼理解，rpc框架是面向服務的更高階的封裝。如果把乙個http server容器上封裝一層服務發現和函式**呼叫，那它就已經可以做乙個rpc框架了。
所以為什麼要用rpc呼叫？
因為良好的rpc呼叫是面向服務的封裝，針對服務的可用性和效率等都做了優化。單純使用http呼叫則缺少了這些特性。
有http了，為什麼還要用rpc？
http 和 rpc 並不是乙個並行概念。http是超文字傳輸協議，應用層網路協議。rpc不是協議，是指遠端過程呼叫，對不同應用間相互呼叫的一種描述。其呼叫協議通常包含傳輸協議和編碼協議 支援http和tcp rpc呼叫是面向服務的封裝，針對服務的可用性和效率等都做了優化。單純使用http呼叫則缺少...
有http 了，為什麼還要rpc？
技術應該不是為了使用新技術而去使用，而應該是舊技術存在某些瓶頸，存在難以支撐或者擴充套件性越老越差等問題暴露出來之後，用新技術來進行解決。那rpc最大的優點，或者說它相比簡單的http介面，它的優勢 更適合它的業務場景是怎樣呢？簡單的http又 不足，哪些場景明顯不太適合呢？rpc remote p...
已經有 apt get，為什麼還要用 apt？
從 ubuntu 16.04 開始，乙個值得注意的新功能是 apt 命令的引入。事實上，apt 的第乙個穩定版本是 2014 年發布的，但是隨著 ubuntu 16.04 的發布，人們才開始注意到它。越來越多的人使用apt install package代替apt get install packa...