二、 HTTP/2（Triple）协议
1. Triple 协议背景
1) Triple 协议选型背景
Triple 协议是 Dubbo3 推 出 的 主 力协议。 Triple 意 为 第 三 代 ， 通 过
Dubbo1.0/Dubbo2.0 两代协议的演进，以及云原生带来的技术标准化浪潮，
Dubbo3 新协议 Triple 应运而生。
a) RPC 协议基本定义
协议是 RPC 的核心，它规范了数据在网络中的传输内容和格式。除必须的请求、响应数据外，通常还会包含额外控制数据，如单次请求的序列化方式、超时时间、压缩方式和鉴权信息等。
协议的内容包含三部分：
• 数据交换格式：定义 RPC 的请求和响应对象在网络传输中的字节流内容，也叫
作序列化方式。
• 协议结构：定义包含字段列表和各字段语义以及不同字段的排列方式。
• 协议通过定义规则、格式和语义来约定数据如何在网络间传输。一次成功的 RPC
需要通信的两端都能够按照协议约定进行网络字节流的读写和对象转换。如果
两端对使用的协议不能达成一致，就会出现鸡同鸭讲，无法满足远程通信的需
求
RPC 协议的设计需要考虑以下内容：
• 通用性：统一的二进制格式，跨语言、跨平台、多传输层协议支持。
• 扩展性：协议增加字段、升级、支持用户扩展和附加业务元数据
• 性能：As fast as it can be。
• 穿透性：能够被各种终端设备识别和转发：网关、代理服务器等。
通用性和高性能通常无法同时达到，需要协议设计者进行一定的取舍。
b) HTTP/1.1 协议
比于直接构建于 TCP 传输层的私有 RPC 协议，构建于 HTTP 之上的远程调用解决方案会有更好的通用性，如 WebServices 或 REST 架构，使用 HTTP+JSON 可以说是一个事实标准的解决方案。
选择构建在 HTTP 之上，有两个最大的优势：
• HTTP 的语义和可扩展性能很好的满足 RPC 调用需求。
• 通用性，HTTP 协议几乎被网络上的所有设备所支持，具有很好的协议穿透性。
但也存在比较明显的问题：
• 典型的 Request–Response 模型，一个链路上一次只能有一个等待的 Request请求。会产生 HOL。
• Human Readable Headers，使用更通用、更易于人类阅读的头部传输格式，但性能相当差。
• 无直接 Server Push 支持，需要使用 Polling Long-Polling 等变通模式。
c) gRPC 协议
上面提到了在 HTTP 及 TCP 协议之上构建 RPC 协议各自的优缺点，相比于 Dubbo构建于 TCP 传输层之上，Google 选择将 gRPC 直接定义在 HTTP/2 协议之上。
gRPC 的优势由 HTTP2 和 Protobuf 继承而来。
• 基于 HTTP2 的协议足够简单，用户学习成本低，天然有 server push/多路复用/流量控制能力。
• 基于 Protobuf 的多语言跨平台二进制兼容能力，提供强大的统一跨语言能力。
• 基于协议本身的生态比较丰富，k8s/etcd 等组件的天然支持协议，云原生的事实协议标准。
但是也存在部分问题
• 对服务治理的支持比较基础，更偏向于基础的 RPC 功能，协议层缺少必要的统一定义，对于用户而言直接用起来并不容易。
• 强绑定 protobuf 的序列化方式，需要较高的学习成本和改造成本，对于现有的偏单语言的用户而言，迁移成本不可忽视。
《Apache Dubbo微服务开发从入门到精通》——通信协议——二、 HTTP/2（Triple）协议(2) : https://developer.aliyun.com/article/1224947
