c++如何实现简单的RPC远程调用框架_c++ 序列化与Socket网络传输整合【指南】

不能直接用 std::string 传结构体，因结构体含指针、虚表、对齐差异、大小端不一致，需序列化为跨平台中间格式（如 Protobuf）；手写协议须用固定宽类型、长度前缀字符串、magic+version 校验。

为什么不能直接用 std::string 传结构体

很多初学者尝试把 C++ 结构体对象直接 reinterpret_cast 发给 socket，结果在另一端读出来全是乱码或崩溃。这不是传输问题，而是序列化缺失：结构体可能含指针、虚函数表、字节对齐差异、平台大小端不一致。二进制内存布局 ≠ 可跨进程/跨机器传输的数据格式。必须先转成与语言、平台、编译器无关的中间表示，比如 Protocol Buffers 的 .proto 编码，或手写紧凑二进制协议。

用 protobuf + socket 实现最小 RPC 调用流程

跳过所有框架封装，只保留最核心三步：序列化请求 → 发送 → 反序列化响应。关键不是“怎么写服务端”，而是“怎么让调用看起来像本地函数”。例如定义一个 CalculateRequest 和 CalculateResponse，客户端填好字段，发过去，等回包解析。

• 先写 calc.proto，用 protoc --cpp_out=. calc.proto 生成 calc.pb.h 和 calc.pb.cc
• 客户端构造 CalculateRequest req，调用 req.SerializeAsString() 得到 std::string 字节流
• 发送前加 4 字节小端长度头（htonl(len)），避免粘包；服务端先 recv 4 字节，再按长度 recv 完整 body
• 服务端用 CalculateRequest::ParseFromString() 解析，计算后填 CalculateResponse 并同样带长度头返回

// 示例：发送带长度头的 protobuf 消息
void send_protobuf(int sock, const google::protobuf::Message& msg) {
    std::string data;
    msg.SerializeToString(&data);
    uint32_t len = htonl(data.size());
    send(sock, (char*)&len, 4, 0);
    send(sock, data.c_str(), data.size(), 0);
}

std::memcpy 直接拷贝结构体的风险点

即使你确认两端结构体定义完全一致、用相同编译器和 ABI，仍可能出错：

• #pragma pack(1) 忘了加，导致 struct 在 x86_64 上默认 8 字节对齐，但网络字节流是紧凑排列
• 成员含 std::string 或 std::vector —— 它们内部是堆地址，memcpy 只复制指针，对方解包即野指针
• Windows vs Linux 下 time_t 是 4 字节还是 8 字节？long 在不同平台宽度不同
• 没有版本兼容机制：v1 协议加了个字段，v2 客户端发过来，v1 服务端反序列化失败或静默截断

不用第三方库时，手写二进制协议要注意什么

如果坚持不用 protobuf、capnproto 等，至少保证以下底线：

• 所有整数字段显式用固定宽类型：int32_t、uint64_t，绝不用 int 或 size_t
• 字符串统一用“长度前缀 + UTF-8 字节”方式编码，长度本身用 uint16_t（小端）
• 每个消息开头放 1 字节 magic number（如 0xCA）和 1 字节 version，便于快速识别非法数据或协议升级
• 接收端必须做完整校验：magic 正确 → version 支持 → 长度在合理范围（防放大攻击）→ 实际 recv 字节数匹配

RPC 不是拼功能，是控边界。真正难的从来不是“怎么调通”，而是“对方进程崩溃、网络中断、序列化失败、字段被删”时，你的调用逻辑是否不崩、可诊断、能降级。