Why Dubbo3’s Triple Protocol Beats Traditional RPCs: A Deep Dive

1. Overview of Dubbo3 Protocols

Dubbo3 natively supports the Triple (Dubbo3) and Dubbo2 protocols and also integrates third‑party protocols such as gRPC, Thrift, JsonRPC, Hessian2, and REST. The article focuses on the Triple protocol, which is the primary RPC protocol of Dubbo3.

2. What Is the Triple Protocol?

Triple is the third‑generation RPC protocol of Dubbo3, created to address the evolution from Dubbo1.0/Dubbo2.0 and the standardisation wave brought by cloud‑native technologies. It adopts HTTP/2 as the transport layer and is fully compatible with gRPC.

3. Fundamentals of RPC Protocol Design

An RPC protocol defines how data is transmitted over the network, including request/response payloads and auxiliary control data such as serialization method, timeout, compression, and authentication.

Data exchange format – the byte‑stream representation of request and response objects.

Protocol structure – the list of fields, their semantics, and ordering.

Semantic rules – how both ends must read/write the byte stream according to the protocol.

4. Design Considerations for RPC Protocols

Universality – a unified binary format that works across languages, platforms, and transport layers.

Extensibility – ability to add fields, upgrade versions, and attach custom metadata.

Performance – as fast as possible.

Penetrability – easy to be recognised and forwarded by gateways, proxies, and other network devices.

5. HTTP/1.1‑Based RPC

Building RPC directly on TCP offers high performance, but HTTP‑based solutions provide better universality. HTTP/1.1 with JSON is a de‑facto standard, offering two main advantages:

Rich semantics and extensibility of HTTP meet RPC needs.

Ubiquitous support across virtually all networked devices.

However, HTTP/1.1 suffers from:

Request‑Response model causing head‑of‑line blocking.

Human‑readable headers that degrade performance.

Lack of native server‑push, requiring work‑arounds like long‑polling.

6. gRPC on HTTP/2

gRPC leverages HTTP/2 and Protobuf, gaining:

Simple learning curve, built‑in server push, multiplexing, and flow control.

Cross‑language binary compatibility via Protobuf.

Rich ecosystem with native support in Kubernetes, etcd, and other cloud‑native components.

Its drawbacks include limited service‑governance features and a strong coupling to Protobuf, which raises migration costs for existing single‑language users.

7. Why Choose Triple?

The team selected a protocol compatible with gRPC and based on HTTP/2, naming it Triple. Triple addresses the shortcomings of both HTTP/1.1‑based RPC and vanilla gRPC:

Performance: Separates metadata from payload, allowing gateways to bypass payload deserialization and reduce latency.

Routing: Custom headers (metadata) enable fine‑grained cluster routing, facilitating gray releases and disaster recovery.

Security: Supports mutual TLS (mTLS) and other encryption mechanisms.

Usability: In addition to Protobuf, Triple supports Hessian, JSON, and other serializers, making migration to Triple virtually cost‑free for existing Dubbo services.

8. Current Status and Advantages

Triple is fully compatible with native gRPC clients, has been validated in large‑scale production, and offers:

Cross‑language interoperability.

Enhanced request models, including streaming and bidirectional calls.

High extensibility and penetrability, supporting tracing, monitoring, and service‑mesh friendly deployment.

Multiple serialization options and seamless upgrade paths.

Zero‑impact upgrade for Java users—only a protocol name change is required.

9. Triple Protocol Details

Key header mappings added by Triple:

Service‑Version → “tri‑service‑version” (Dubbo service version)

Service‑Group → “tri‑service‑group” (Dubbo service group)

Tracing‑ID → “tri‑trace‑traceid” (trace identifier)

Tracing‑RPC‑ID → “tri‑trace‑rpcid” (span identifier)

Cluster‑Info → “tri‑unit‑info” (cluster information)

These headers enable versioning, grouping, full‑link tracing, and flexible routing.

Triple Streaming

Beyond traditional unary calls, Triple provides Streaming RPC, which is essential for large file transfers, live streaming, and other high‑throughput scenarios. Multiple logical streams share a single TCP connection, each identified by a StreamId, ensuring ordered read/write per stream.

10. Summary

Triple is Dubbo3’s flagship protocol, employing a layered design with Protobuf‑based serialization and HTTP/2 transport. It delivers superior serialization efficiency, supports multiple serializers, and benefits from HTTP/2’s security and flow‑control features. Triple works for server‑side services, browsers, mobile apps, and IoT devices, while seamlessly integrating Dubbo3’s full service‑governance capabilities.

In the cloud‑native era, open standards for RPC are inevitable; Triple’s alignment with gRPC and HTTP/2 positions it as a key step for Dubbo3 toward cloud‑native micro‑services.

Appendix: Dubbo2 Protocol Specification

Key fields of the Dubbo2 binary protocol:

Magic – 16‑bit identifier (0xdabb).

Req/Res – 1‑bit flag (1 for request, 0 for response).

2 Way – 1‑bit flag indicating whether a response is expected.

Event – 1‑bit flag for event messages (e.g., heartbeat).

Serialization ID – 5‑bit identifier (e.g., 6 for fastjson).

Status – 8‑bit code (e.g., 20 = OK, 30 = CLIENT_TIMEOUT, …).

Request ID – 64‑bit unique identifier.

Data Length – 32‑bit length of the serialized payload.

Variable Part – serialized byte arrays identified by the Serialization ID.

When the message is a request, the variable part consists of:

Dubbo version

Service name

Service version

Method name

Method parameter types

Method arguments

Attachments

When the message is a response, the variable part consists of:

Return value type (e.g., RESPONSE_NULL_VALUE = 2, RESPONSE_VALUE = 1, RESPONSE_WITH_EXCEPTION = 0)

Return value

Note: In the current Dubbo implementation, when JSON serialization is used, a newline character is inserted between each part of the variable section.

Dubbo version bytes (
)</code><code>Service name bytes (
)</code><code>...