Socket 通信和 RPC 通信对比学习

加载中... 浏览

Socket 和 RPC 都和网络通信有关，但它们不是同一层东西。Socket 更像底层通信能力，RPC 更像把远程调用包装成本地函数调用的一种通信模型。

1. 先用一句话区分

可以先这样理解：

Socket 关心的是“两个程序怎么通过网络收发数据”；RPC 关心的是“怎么像调用本地函数一样调用远程服务”。

它们的关注点不一样。

Socket 更底层，RPC 更偏工程抽象。

txt

应用代码
  ↓
RPC 框架
  ↓
序列化 / 协议 / 负载均衡 / 超时 / 重试
  ↓
Socket / TCP / HTTP
  ↓
网络

也就是说，很多 RPC 框架底层仍然会用到 Socket 或基于 Socket 的网络协议。

2. 什么是 Socket 通信

Socket 可以理解成网络通信的端点。

两个程序想通过网络通信，通常需要：

服务端监听一个 IP 和端口。
客户端连接这个 IP 和端口。
双方建立连接后发送和接收字节数据。

大致模型：

txt

Client Socket  <---- TCP Connection ---->  Server Socket

Socket 本身不关心你传的是用户信息、订单信息还是文件内容。

它更关心：

连接怎么建立。
数据怎么发送。
数据怎么接收。
连接什么时候关闭。

所以 Socket 通信比较底层，灵活，但也意味着很多事情要自己处理。

3. Socket 通信需要自己处理什么

如果直接基于 Socket 写业务通信，通常要自己考虑：

数据格式是什么。
一条消息从哪里开始，到哪里结束。
粘包、拆包怎么处理。
客户端断开连接怎么办。
超时怎么处理。
重连怎么处理。
服务端如何处理并发连接。
错误码和异常如何表达。

比如 TCP 是字节流协议，它只保证字节顺序，不保证你一次发送的一段数据，在接收方就一定完整对应一次读取。

所以你需要设计消息边界。

常见方式：

固定长度消息。
使用分隔符。
在消息头里写 body 长度。

这也是为什么直接写 Socket 更接近底层网络编程。

4. 什么是 RPC 通信

RPC 的全称是 Remote Procedure Call，远程过程调用。

它想解决的问题是：

明明服务在另一台机器上，能不能让调用方式像调用本地函数一样简单？

比如本地函数调用：

const user = getUserById(1)

RPC 希望远程调用也能写得类似：

const user = userService.getUserById(1)

但实际背后发生了很多事情：

txt

调用方法
  ↓
参数序列化
  ↓
网络传输
  ↓
服务端反序列化
  ↓
执行真实方法
  ↓
结果序列化
  ↓
网络返回
  ↓
客户端拿到结果

RPC 把这些细节封装起来，让开发者更关注业务调用。

5. RPC 框架通常帮我们做什么

一个成熟的 RPC 框架通常不只是“发请求”。

它可能包括：

接口定义。
参数序列化和反序列化。
网络通信。
服务发现。
负载均衡。
超时控制。
重试机制。
熔断降级。
调用链追踪。
错误处理。

比如后端服务之间互相调用时，RPC 可以让调用体验更统一。

txt

Order Service -> User Service
Order Service -> Payment Service
Order Service -> Inventory Service

如果每个调用都手写 Socket，工程复杂度会非常高。

6. Socket 和 RPC 的核心区别

可以从几个角度对比：

对比点	Socket 通信	RPC 通信
所在层次	更底层	更高层
关注重点	数据怎么收发	远程方法怎么调用
数据格式	自己定义	框架或协议定义
使用体验	像操作连接和字节流	像调用函数
工程能力	很多要自己实现	框架通常内置
灵活性	高	受框架约束
适合场景	自定义协议、长连接、底层通信	微服务调用、内部服务通信

所以它们不是简单的替代关系。

RPC 可以基于 TCP、HTTP/2、HTTP/1.1 等协议实现，而这些协议底层最终都离不开网络 Socket 能力。

7. 用一个例子理解区别

假设有一个查询用户信息的需求：

txt

根据 userId 查询用户信息

Socket 思路

如果用 Socket，你可能要自己定义协议：

txt

请求：
GET_USER 1

响应：
USER 1 张三 20

然后你还要处理消息解析、异常、连接断开、重试等问题。

RPC 思路

如果用 RPC，你会更像定义一个接口：

interface UserService {
  getUserById(id: number): User
}

调用方只关心：

const user = userService.getUserById(1)

至于请求怎么编码、怎么传输、服务端怎么找到方法、结果怎么返回，交给 RPC 框架处理。

8. Socket 更适合什么场景

Socket 更适合需要细粒度控制通信过程的场景。

比如：

即时通信。
游戏服务器。
自定义二进制协议。
长连接推送。
对性能和协议格式要求非常高的系统。

这些场景里，开发者可能需要直接控制连接、心跳、消息格式和传输方式。

9. RPC 更适合什么场景

RPC 更适合服务之间调用。

比如：

微服务内部通信。
后端服务调用另一个后端服务。
分布式系统中模块之间的远程调用。
需要统一服务治理能力的系统。

RPC 的重点不是“能通信”，而是“让远程服务调用更规范、更工程化”。

10. 初学时的理解顺序

如果从学习角度看，可以按这个顺序理解：

先理解网络通信的本质：进程之间通过网络交换数据。
再理解 Socket：程序通过 Socket 建立连接、收发字节。
再理解协议：双方必须约定数据格式和消息边界。
再理解 RPC：把远程通信封装成方法调用。
最后理解服务治理：负载均衡、超时、重试、熔断、监控。

这样就不会把 Socket 和 RPC 混成一类概念。

11. 小结

Socket 和 RPC 可以这样记：

Socket 是偏底层的网络通信接口。
RPC 是偏上层的远程调用模型。
Socket 让程序能通过网络收发数据。
RPC 让远程服务调用更像本地函数调用。
直接用 Socket 更灵活，但要处理很多细节。
使用 RPC 更工程化，但需要遵守框架和协议约定。

一句话总结：

Socket 解决“怎么通信”，RPC 解决“怎么把远程通信组织成服务调用”。

留言板

加载评论中...

1. 先用一句话区分 ​

2. 什么是 Socket 通信 ​

3. Socket 通信需要自己处理什么 ​

4. 什么是 RPC 通信 ​

5. RPC 框架通常帮我们做什么 ​

6. Socket 和 RPC 的核心区别 ​

7. 用一个例子理解区别 ​

Socket 思路 ​

RPC 思路 ​

8. Socket 更适合什么场景 ​

9. RPC 更适合什么场景 ​

10. 初学时的理解顺序 ​

11. 小结 ​

留言板