谈到RPC，就避免不了序列化的话题。

gRPC默认的序列化方式是protobuf，原因很简单，因为两者都是google发明的，哈哈。

在当初Google开源protobuf时，很多人就期待是否能把RPC的实现也一起开源出来。没想到最终出来的是gRPC，终于补全了这一块。

事实上的跨语言序列化方案只有三个： protobuf, thrift, json。

• json体积太大，并且缺少类型信息，实际上只用在RESTful接口上，并没有看到RPC框架会默认选json做序列化的。

国内一些大公司的使用情况：

• protobuf ，腾迅，百度等

• thrift，小米，美团等

• hessian， 阿里用的是自己维护的版本，有js/cpp的实现，因为阿里主用java，更多是历史原因。

序列化就是把对象转换为二进制数据，反序列化就把二进制数据转换为对象。

各种序列化库层出不穷，其中有一个重要的区别：类型信息存放在哪？

可以分为三种：

1. 不保存类型信息

   典型的是各种json序列化库，优点是灵活，缺点是使用的双方都要知道类型是什么。当然有一些json库会提供一些扩展，偷偷把类型信息插入到json里。

2. 类型信息保存到序列化结果里

   比如java自带的序列化，hessian等。缺点是类型信息冗余。比如RPC里每一个request都要带上类型。因此有一种常见的RPC优化手段就是两端协商之后，后续的请求不需要再带上类型信息。

3. 在生成代码里带上类型信息

   通常是在IDL文件里写好package和类名，生成的代码直接就有了类型信息。比如protobuf, thrift。缺点是需要生成代码，双方都要知道IDL文件。

类型信息看起来是一个小事，但在安全上却会出大问题，后面会讨论。

这里讨论的是没有IDL定义的序列化方案，比如java自带的序列化，hessian, 各种json库。

以gRPC官方的Demo为例：

package helloworld;

// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

可以看到rpc的定义也是写在proto文件里的。实际上gRPC是protobuf的一个扩展，通过扩展生成gRPC相关的代码。

在protobuf出来以后，也不断出现新的方案。比如

1. 序列化漏洞通常比较严重，容易造成任意代码执行
2. 序列化漏洞在很多语言里都会有，比如Python Pickle序列化漏洞。

很多程序员不理解为什么反序列化可以造成任意代码执行。

反序列化漏洞到底是怎么工作的呢？很难直接描述清楚，这些漏洞都有很精巧的设计，把多个地方的代码串联起来。可以参考这个demo，跑起来调试下就可以有直观的印象：

下面来看下常见的序列化方案是怎么防止反序列化漏洞的：

这些序列化漏洞的根本原因是：没有控制序列化的类型范围

为什么在protobuf里并没有这些反序列化问题？

• protobuf在IDL里定义好了package范围
• protobuf的代码都是自动生成的，怎么处理二进制数据都是固定的

protobuf把一切都框住了，少了灵活性，自然就少漏洞。

• 应该重视反序列化漏洞，毕竟Oracle都不得不考虑把java序列化废弃了
• 序列化漏洞的根本原因是：没有控制序列化的类型范围
• 防止序列化漏洞，最好是使用白名单
• protobuf通过IDL生成代码，严格控制了类型范围
• protobuf不是完美的方案，但是作为跨语言的序列化事实方案之一，IDL生成代码比较麻烦也不是啥大问题

欢迎关注公众号：横云断岭的专栏，专注分享Java，Spring Boot，Arthas，Dubbo。