优势
【性能上】：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】<br>Service-Group → “tri-service-group” {Dubbo service group} --【用来区分Dubbo服务的Group信息】<br>Tracing-ID → “tri-trace-traceid” {tracing id} --【用于全链路追踪能力】<br>Tracing-RPC-ID → “tri-trace-rpcid” {_span id _} --【用于全链路追踪能力】<br>Cluster-Info → “tri-unit-info” {cluster infomation} --【表示集群信息，可以使用其构建一些如集群划分等路由相关的灵活的服务治理能力。】
Streaming用处
在一些大文件传输、直播等应用场景中， consumer或provider需要跟对端进行大量数据的传输
方案
数据分片：通过多次RPC调用进行传输，如果我们对这些已经拆分了的RPC数据包进行并行传输，那么到对端后相关的数据包是无序的，需要对接收到的数据进行排序拼接，相关的逻辑会非常复杂
串行传输拆分之后的RPC数据包：对应的网络传输RTT与数据处理的时延会是非常大的。
stream方案
会在consumer跟provider之间建立多条用户态的长连接，Stream。同一个TCP连接之上能同时存在多个Stream，其中每条Stream都有StreamId进行标识，对于一条Stream上的数据包会以顺序方式读写
