前言
协议是 RPC 的基础。数据在连接上以什么格式传输，服务端如何确定收到请求的大小，同一个连接上能不能同时存在多个请求，请求如果出错了应该怎么响应……这些都是需要协议解决的问题。
从定义上讲，协议通过定义规则、格式和语义来约定数据如何在网络间传输。RPC 需要通信的两端都能够识别同一种协议。数据在网络上以比特流的方式传输，如果本端的协议对端不识别，对端就无法从请求中获取到有用信息，就会出现鸡同鸭讲的情况，无法实现上层的业务需求。
一个简单的协议需要定义数据交换格式，协议格式和请求方式。
数据交换格式在 RPC 中也叫做序列化格式。常用的序列化有 JSON / Protobuf / Hessian 等，评价序列化优劣一般从三个维度：
- 序列化后的字节数组大小
- 序列化和反序列化速度
- 序列化后的可读性
协议在选取序列化方式时，按照具体的需求在这三个维度中互相取舍。序列化后的数组越小，越节省网络流量，但序列化过程可能更消耗时间。JSONXML 这类基于文本的序列化方式往往更容易被开发者接受，因为相比于一连传的字节数组，文本更容易被理解，在各层设备中都能比较容易的识别，但可读性提高的后果是性能大幅降低。
协议格式是和 RPC 框架紧密相关的，按照功能划分有两种：
- 一种是紧凑型协议，只提供用于调用的简单元数据和数据内容；
- 另外一种是复合型协议，会携带框架层的元数据用来提供功能上的增强，这类协议的一个代表就是 RSocket。
请求方式和协议格式息息相关，常见的请求格式有同步 Request/Response 和异步 Request/Response，区别是客户端发出一个请求后，是否需要同步等待响应返回。如果不需要等待响应，一个链接上就可以同时存在多个未完成的请求，这也被叫做多路复用。另外的请求模型有 Streaming ，在一次完整的业务调用中存在多次 RPC，每次都传输一部分数据，适合流数据传输。
有了这三个基本约定，就能实现一个简单的 RPC 协议了。
Dubbo3 的一个核心内容就是定义下一代 RPC 协议。除了基础的通信功能，新协议还应该具有以下特性：
- 统一的跨语言二进制格式
- 支持 Streaming 和应用层全双工调用模型
- 易于扩展
- 能够被各层设备识别
这里我们对比一些常用的协议，来探索新协议的形态。
HTTP/1.1
HTTP/1.1 应该是应用最广泛的协议，简单清晰的语法，跨语言以及对原生移动端的支持都让其成为了事实上最被广泛接受的 RPC 方案。
然而从 RPC 协议的诉求上讲， HTTP1.1 主要有以下几个问题
- 队头阻塞(HOL)导致其在单连接的性能低下，尽管支持了 pipeline 但仍无法避免响应按序返回；
- 基于文本的协议每次请求都会重复携带很多繁杂无用的头部信息，浪费带宽影响性能；
- 纯粹的 Request/Response 请求模型，无法实现 Server Push，只能依靠客户端轮询，同样 Streaming 的全双工也是不安全的。
RESP
RESP 是 Redis 使用的通信协议，其简洁易于理解的格式也助力了 Redis 各语言客户端的快速发展。但是这种类似 HTTP/1.1 的协议也存在着同样的性能问题。
- 序列化表达能力弱，通常还需要借助其他序列化方式辅助，然而协议中又不支持设置特定序列化方式，只能依靠客户端约定；
- 同样存在队头阻塞问题，pipeline 无法从根本上解决单连接性能问题；
- Pub/Sub 在单连接情况下也有数量瓶颈。
Dubbo2.0
Dubbo2.0 协议直接定义在 TCP 传输层协议上，为协议功能定义提供了最大的灵活性，但同时也正是因为这样明显的灵活性优势，RPC 协议普遍都是定制化的私有协议。
Dubbo 协议体 Body 中有一个可扩展的 attachments 部分，这给 RPC 方法之外额外传递附加属性提供了可能，是一个很好的设计。但是类似的 Header 部分，却缺少类似的可扩展 attachments，这点可参考 HTTP 定义的 Ascii Header 设计，将 Body Attachments 和 Header Attachments 做职责划分。
- Body 协议体中的一些 RPC 请求定位符如 Service Name、Method Name、Version 等，可以提到 Header 中，和具体的序列化协议解耦，以更好的被网络基础设施识别或用于流量管控；
- 扩展性不够好，欠缺协议升级方面的设计，如 Header 头中没有预留的状态标识位，或者像 HTTP 有专为协议升级或协商设计的特殊 packet；
- 在 Java 版本的代码实现上，不够精简和通用。如在链路传输中，存在一些语言绑定的内容；消息体中存在冗余内容，如 Service Name 在 Body 和 Attachments 中都存在。
HTTP/2.0
HTTP/2.0 保留了 HTTP/1 的所有语义，在保持兼容的同时，在通信模型和传输效率上做了很大的改进，主要也是为了解决 HTTP/1 中的问题。
- 支持单条链路上的 Multiplexing，相比于 Request - Response 独占链路，基于 Frame 实现更高效利用链路，StreamId 提供了上下文状态，client 可以根据 StreamId 支持乱序 Response 返回；
- 头部压缩 HPACK，基于静态表和动态表实现了 Header 缓存，减少传输数据量；
- Request - Stream 语义，原生支持 Server Push 和 Stream 数据传输；
- Binary Frame，二进制分帧，可以单独处理 Header 和 Data。
HTTP/2.0 虽然克服了以上问题，但也存在着一些争议点，比如在 TCP 的上层进行流量控制的必要性，以及对 HTTP 语义通过 HPACK 兼容是否过于繁琐复杂。
gRPC
相比较于一些框架将应用层协议构建在裸 TCP 上，gRPC 选择了 HTTP/2.0 作为传输层协议。通过对 Header 内容和 Payload 格式的限定实现上层协议功能。
下面是 gRPC 的一些设计理念：
- Coverage & Simplicity，协议设计和框架实现要足够通用和简单，能运行在任何设备之上，甚至一些资源首先的如 IoT、Mobile 等设备；
- Interoperability & Reach，要构建在更通用的协议之上，协议本身要能被网络上几乎所有的基础设施所支持；
- General Purpose & Performant，要在场景和性能间做好平衡，首先协议本身要是适用于各种场景的，同时也要尽量有高的性能；
- Payload Agnostic，协议上传输的负载要保持语言和平台中立；
- Streaming，要支持 Request - Response、Request - Stream、Bi-Steam 等通信模型；
- Flow Control，协议自身具备流量感知和限制的能力；
- Metadata Exchange，在 RPC 服务定义之外，提供额外附加数据传输的能力。
在这样的设计理念指导下，gRPC 最终被设计为一个跨语言、跨平台、通用的协议。功能上基本已经完全具备或可以轻易扩展出需要的新功能。然而我们知道，软件工程没有银弹，相比较于裸 TCP 专有协议，极限性能上 gRPC 肯定是要差一些。但是对大部分应用来说，相比较于 HTTP/1.1 的协议，gRPC/HTTP2 已经在性能上取得了很大的进步，同时又兼顾了可读性。
序列化上，gRPC 被设计成保持 payload 中立，但实际的跨语言场景需要一个强规范的接口定义语言来保证序列化结果的一致。在 gRPC 的官方实现中，protobuf 和 json 分别用来支持性能场景和开发效率场景。从序列化方式的选择到协议的各维度比较，基于 gRPC 扩展出新的协议是最优的选择。
Dubbo3.0
Dubbo3.0 的协议基于 gRPC ，在应用层、异常处理、协议层负载均衡支持和 Reactive 支持上提供了扩展。主要有三个目标：
- 在分布式大规模集群场景下，提供更完善的负载均衡，以获取更高性能和保证稳定性；
- 支持 tracing/monitoring 等分布式标准扩展，支持微服务标准化以及平滑迁移；
- Reactive 语义在协议层增强，能够提供分布式 back-pressure 能力和更完善的 Streaming 支持。
除了协议层的支持，Dubbo3.0 新协议还包括易用性方面的支持，包括同时支持 IDL compiler 和 Annotation Compiler。客户端将更完善地支持原生异步回调、Future 异步和同步调用，服务端将使用非反射调用，这十分显著地提升了客户端和服务端性能。从用户迁移的角度，Dubbo 框架将提供平滑的协议升级支持，力求尽可能少的改造代码或配置就能带来成倍的性能提升。
