從網絡基礎説起：TCP的能力與侷限

剛開始接觸網絡編程時，我覺得TCP已經足夠完美——它能夠建立穩定的連接、保證數據可靠傳輸、處理網絡擁塞，這似乎就是網絡通信的全部需求。

但在實際開發中，我遇到了一個基礎卻關鍵的問題：

// 發送方連續發送兩條獨立消息
socket.write("Hello");
socket.write("World");

// 接收方可能一次收到："HelloWorld"
// 完全無法區分原始的消息邊界

這一現象常被稱作TCP粘包問題，但這其實是一種誤解。其本質是TCP作為字節流協議的無邊界特性：TCP只負責可靠地傳輸字節序列，卻不關心這些字節應該如何被組織成有意義的業務消息。

TCP的三個核心特性：

  • 面向連接：通信前需要通過三次握手建立連接
  • 可靠傳輸：通過確認、重傳、排序等機制保證數據可靠送達
  • 基於字節流：數據沒有自然邊界，只是連續的字節序列（二進制）

個人理解： TCP就像是一個可靠的物流系統，保證把所有的貨物（字節）都按順序送達，但它會把所有貨物都裝進一條連續的傳送帶（字節流）——貨物確實都到了，但接收方需要自己根據包裹上的信息（應用層協議）來重新拆分和識別每個獨立的包裹。

所謂“粘包”，其實是一個偽命題。TCP傳輸的是字節流，而非消息包。如何在流中界定消息，是應用層協議需要解決的問題。

HTTP協議的出現：為數據賦予意義

面對TCP的侷限性，應用層協議應運而生。HTTP協議通過在TCP之上定義明確的報文格式，解決了消息邊界和語義表達的問題。

HTTP通過標準的報文結構定義消息邊界：

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 48

{"name": "Alice", "email": "alice@example.com"}

關鍵就在於Content-Length: 48這個頭部——它明確告訴接收方消息體的確切長度，從而解決了TCP的粘包問題。

HTTP協議的主要價值：

  • 定義消息邊界：通過Content-Length或chunked編碼標識消息範圍
  • 標準化通信語義：GET、POST、PUT、DELETE等標準方法
  • 豐富的能力擴展：緩存控制、內容協商、狀態管理
  • 通用兼容性：被所有主流平台和語言支持

結論： TCP解決了"可靠傳輸"的問題，而HTTP等應用層協議解決了"傳輸什麼"和"如何解析"的問題。

新的困惑：為什麼要在HTTP之上再引入RPC？

隨着分佈式系統的發展，大家都能發現基於HTTP的服務間調用會存在一些不便：

// 基於HTTP的服務調用需要大量樣板代碼
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);
}
// 太多的底層細節需要處理！

每次調用都需要處理HTTP狀態碼、異常情況、序列化反序列化等重複工作。這讓我們開始思考：能否讓遠程服務調用像調用本地方法一樣簡單？

RPC的核心理念：透明化的遠程調用

RPC（Remote Procedure Call），又叫做遠程過程調用，其目標就是讓遠程服務調用對開發者透明。

// 理想的RPC調用方式
User user = userService.getUser(123);

// 而不是處理各種網絡通信細節

重要概念澄清（基於個人理解）：
RPC本身不是具體的協議，而是一種調用範式或技術思想。它的核心目標是讓程序員能夠像調用本地方法那樣調用遠程服務。

但是我們不能説“使用RPC協議”，因為RPC本身不是協議。

正確的表述方式：

  • ✅ "我們使用gRPC協議進行RPC調用"
  • ❌ "我們使用RPC協議"

因為RPC本身不是協議，而gRPC、Thrift、Dubbo等才是具體的協議實現。

RPC與HTTP的關係：不同維度的技術

RPC與HTTP的關係這是最容易產生混淆的地方。通過學習和實踐，我個人理解為：

RPC和HTTP根本不在同一個技術層級：

  • RPC是一種調用範式，對標的是本地方法調用
  • HTTP是一種具體的應用層協議
  • RPC可以通過HTTP實現，也可以通過自定義的TCP或UDP協議實現

比如gRPC選擇基於HTTP/2協議實現，而很多早期的RPC框架使用自定義的TCP二進制協議。

RPC協議與RPC框架的完整生態

RPC協議：通信的基礎規範

協議主要定義三個核心方面：

  1. 消息格式：定義消息如何開始、結束，頭部和體部的結構
  2. 序列化方式：規定數據如何編碼和解碼
  3. 傳輸規則：確定通信流程和交互模式

RPC框架：基於協議的完整解決方案

現代RPC框架在基礎協議之上提供了企業級的能力：

  • 核心層：實現通信協議本身
  • 組件層：提供序列化、服務發現、負載均衡等基礎組件
  • 治理層：包含容錯、監控、註冊中心等運維能力
  • 應用層：讓開發者透明地進行遠程方法調用

總結： 協議定義了機器之間如何對話，框架讓開發者無需關心對話過程而專注業務邏輯。

現代架構中的技術選型：各司其職的分工

通過參與實際項目，我逐漸理解了HTTP和RPC在現代架構中的分工原則。針對大部分公司而言，基本上都是如此。

內部服務調用：RPC框架的優勢領域

在微服務架構內部，RPC框架因其性能優勢成為首選：

RPC的高性能主要源於：

  1. 高效的序列化
// JSON序列化：可讀性好但體積大
{"id": 123, "name": "Alice", "age": 30}  // 約40字節

// Protobuf二進制：體積小，解析快
\x08\x7B\x12\x05Alice\x18\x1E  // 僅11字節
// 體積減少70%以上，序列化速度提升明顯
  1. 協議開銷優化
  • 長連接減少TCP握手開銷
  • 多路複用提升連接利用率
  • 頭部壓縮減少傳輸數據量
  1. 專為性能設計
  • 精簡的協議頭設計
  • 二進制編碼效率
  • 零拷貝等技術應用

對外API暴露：HTTP協議的不可替代性

當需要向外部提供API時，HTTP協議展現出其獨特價值：

HTTP的通用性優勢：

  • 無與倫比的生態系統：所有平台、語言、設備都支持HTTP
  • 成熟的工具鏈：瀏覽器、Postman、curl等調試工具
  • 網絡友好性：80/443端口普遍開放
  • 易於測試調試：直接通過瀏覽器或命令行工具測試
// 前端調用HTTP API簡單直接
fetch('/api/users/123')
  .then(response => response.json())
  .then(user => {
    displayUser(user);
  });

真實世界的架構實踐

現代互聯網公司的典型架構體現了清晰的分層設計：

有了TCP為什麼還需要HTTP？再用RPC？這次徹底講明白了_RPC

這種架構的智慧：

  • 內外有別：對外保證兼容性，對內追求性能
  • 關注點分離：網關處理橫切關注點，業務服務專注核心邏輯
  • 協議轉換：在網關層完成HTTP到RPC的協議轉換

總結與核心觀點

針對文章內容，整體總結一下：

技術演進脈絡：

  1. TCP層：解決網絡層的可靠傳輸問題
  2. HTTP層：解決應用層的消息格式和語義問題
  3. RPC層：優化分佈式系統的服務調用體驗

現代架構的最佳實踐：

  • 公司內部服務調用：優先採用RPC框架（如gRPC、Dubbo）
  • 核心原因：極致性能。二進制編碼、協議開銷低、長連接複用
  • 對外暴露接口：普遍採用HTTP協議（及RESTful風格）
  • 核心原因：無與倫比的通用性。生態系統成熟，客户端兼容性好

核心結論：
這是一個"內外有別"的最佳實踐——性能至上的內部集羣採用RPC框架，兼容性優先的對外開放接口採用HTTP協議。