dubbo协议

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

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

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

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

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

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

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

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

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

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

【性能上】：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需要跟对端进行大量数据的传输

方案

stream方案