dubbo协议

比于直接构建于 TCP 传输层的私有 RPC 协议，构建于 HTTP 之上的远程调用解决方案会有更好的通用性WebServices 或 REST 架构，使用 HTTP + JSON 可以说是一个事实标准的解决方案。

1、HTTP 的语义和可扩展性能很好的满足 RPC 调用需求。

2、通用性，HTTP 协议几乎被网络上的所有设备所支持，具有很好的协议穿透性。

优势

1、典型的 Request – Response 模型，一个链路上一次只能有一个等待的 Request 请求。会产生 HOL。

2、Human Readable Headers，使用更通用、更易于人类阅读的头部传输格式，但性能相当差

3、没有服务器推送的支持，需要使用长链接轮训的模式

存在的问题

HTTP/1.1

gRPC 直接定义在 HTTP/2 协议之上，gRPC 的优势由HTTP2 和 Protobuf 继承而来

1、基于 HTTP2 的协议足够简单，用户学习成本低，天然有 server push/ 多路复用 / 流量控制能力

2、基于 Protobuf 的多语言跨平台二进制兼容能力，提供强大的统一跨语言能力

3、基于协议本身的生态比较丰富，k8s/etcd 等组件的天然支持协议，云原生的事实协议标准

1、对服务治理的支持比较基础，更偏向于基础的 RPC 功能，协议层缺少必要的统一定义，对于用户而言直接用起来并不容易。

2、强绑定 protobuf （Protocol Buffers）的序列化方式，需要较高的学习成本和改造成本，对于现有的偏单语言的用户而言，迁移成本不可忽视

gRPC

兼容 gRPC ，以 HTTP2 作为传输层构建新的协议

【性能上】：Triple 协议采取了 metadata 和 payload 分离的策略，这样就可以避免中间设备，如网关进行 payload 的解析和反序列化，从而降低响应时间。

【路由支持】：由于 metadata 支持用户添加自定义 header ，用户可以根据 header 更方便的划分集群或者进行路由，这样发布的时候切流灰度或容灾都有了更高的灵活性。

【安全性】：支持双向TLS认证（mTLS）等加密传输能力。

【易用性】：Triple 除了支持原生 gRPC 所推荐的 Protobuf 序列化外，使用通用的方式支持了 Hessian / JSON 等其他序列化，能让用户更方便的升级到 Triple 协议。对原有的 Dubbo 服务而言，修改或增加 Triple 协议 只需要在声明服务的代码块添加一行协议配置即可，改造成本几乎为 0

提供完善的请求模型，除了request/response模型，还支持Streaming 和 Bidirectional

协议框架图

Service-Version → “tri-service-version” {Dubbo service version}  --【用来区分Dubbo 服务的 version】Service-Group → “tri-service-group” {Dubbo service group}  --【用来区分Dubbo服务的Group信息】Tracing-ID → “tri-trace-traceid” {tracing id}  --【用于全链路追踪能力】Tracing-RPC-ID → “tri-trace-rpcid” {_span id _}  --【用于全链路追踪能力】Cluster-Info → “tri-unit-info” {cluster infomation}   --【表示集群信息，可以使用其构建一些如集群划分等路由相关的灵活的服务治理能力。】

协议内容

在一些大文件传输、直播等应用场景中， consumer或provider需要跟对端进行大量数据的传输

数据分片：通过多次RPC调用进行传输，如果我们对这些已经拆分了的RPC数据包进行并行传输，那么到对端后相关的数据包是无序的，需要对接收到的数据进行排序拼接，相关的逻辑会非常复杂

串行传输拆分之后的RPC数据包：对应的网络传输RTT与数据处理的时延会是非常大的。

方案

会在consumer跟provider之间建立多条用户态的长连接，Stream。同一个TCP连接之上能同时存在多个Stream，其中每条Stream都有StreamId进行标识，对于一条Stream上的数据包会以顺序方式读写

stream方案

Streaming用处

Triple 协议

协议