http 和 rpc 並不是乙個並行概念。
http是超文字傳輸協議，應用層網路協議。
rpc不是協議，是指遠端過程呼叫，對不同應用間相互呼叫的一種描述。其呼叫協議通常包含傳輸協議和編碼協議；支援http和tcp；
rpc呼叫是面向服務的封裝，針對服務的可用性和效率等都做了優化。單純使用http呼叫則缺少了這些特性。
例如rpc框架提供的負載均衡，服務治理，自動熔斷/降級，實現二進位制傳輸等；
如果把乙個http server容器上封裝一層服務發現和函式**呼叫，那它就已經可以做乙個rpc框架了。
總結：rpc是一種程式設計模式，把對伺服器的呼叫抽象為過程呼叫，通常伴隨著框架**自動生成等功能。使用rpc做網路服務開發時，通常只需要實現伺服器端的乙個處理函式，其餘的客戶端呼叫，序列化反序列化，方法派發等都由框架或者生成的**來完成，較大地減輕了網路服務開發和呼叫的複雜性。rpc框架更多的在內網中應用間呼叫使用，http 除了內網傳輸，更習慣用在跨網間，跨語言間呼叫。
有http 了，為什麼還要rpc？
技術應該不是為了使用新技術而去使用，而應該是舊技術存在某些瓶頸，存在難以支撐或者擴充套件性越老越差等問題暴露出來之後，用新技術來進行解決。那rpc最大的優點，或者說它相比簡單的http介面，它的優勢 更適合它的業務場景是怎樣呢？簡單的http又 不足，哪些場景明顯不太適合呢？rpc remote p...
有http 請求，為什麼還要用rpc呼叫？
這個回答裡恰巧講了一些rpc通訊協議的細節，但是強調一遍通訊協議不是rpc最重要的部分，不要被這個回答帶偏了。如果要了解rpc請更多的去了解服務治理 soa 的一些基本策略,推薦去看看dubbo的文件。這個問題其實是有理解誤區的，首先 http 和 rpc 並不是乙個並行概念。rpc是遠端過程呼叫，...
有了 IP 位址，為什麼還要用 MAC 位址？
估計很多人都有這個疑問，但沒見哪本書上解釋清楚，都只是描述ip是什麼，mac是什麼。當資料報到達區域網後，完全可以直接送到對應的ip位址主機，為什麼還要詢問一下對應ip主機的mac位址？乙個郵遞員拿著位址詳細到教室的一封信，收件人是小明，教室裡沒有重名的，郵遞員問 小明的學號是多少？小明站起來回答 ...