This is an automated email from the ASF dual-hosted git repository.
liujun pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
The following commit(s) were added to refs/heads/master by this push:
new 520db97ceb update triple protocol spec (#2763)
520db97ceb is described below
commit 520db97cebef967aefdd6ebe332f5dc6ed213c7c
Author: Ken Liu <[email protected]>
AuthorDate: Wed Jul 5 13:26:44 2023 +0800
update triple protocol spec (#2763)
---
.../blog/integration/dubbo-graalvm-support.md | 2 +-
content/zh-cn/overview/reference/protocols/http.md | 1 +
content/zh-cn/overview/reference/protocols/tcp.md | 2 +
.../overview/reference/protocols/triple-spec.md | 322 +++++++++++++++++++++
.../zh-cn/overview/reference/protocols/triple.md | 39 +--
data/announcements/zh/scheduled.yaml | 2 +-
...vm-copilation2.png => graalvm-compilation2.png} | Bin
7 files changed, 347 insertions(+), 21 deletions(-)
diff --git a/content/zh-cn/blog/integration/dubbo-graalvm-support.md
b/content/zh-cn/blog/integration/dubbo-graalvm-support.md
index 75d77b8f23..286dfa5c34 100644
--- a/content/zh-cn/blog/integration/dubbo-graalvm-support.md
+++ b/content/zh-cn/blog/integration/dubbo-graalvm-support.md
@@ -1,6 +1,6 @@
---
title: "走向 Native 化：Spring&Dubbo AOT 技术示例与原理讲解"
-linkTitle: "Native Image"
+linkTitle: "走向 Native 化：Dubbo AOT 正式发布"
date: 2023-06-28
tags: ["Java", "Native Image", "GraalVM"]
authors: ["刘军", "华钟明"]
diff --git a/content/zh-cn/overview/reference/protocols/http.md
b/content/zh-cn/overview/reference/protocols/http.md
index 2cf2064879..3f4b2ac41b 100644
--- a/content/zh-cn/overview/reference/protocols/http.md
+++ b/content/zh-cn/overview/reference/protocols/http.md
@@ -4,6 +4,7 @@ linkTitle: HTTP 协议规范
title: HTTP 协议规范
type: docs
weight: 3
+working_in_progress: true
---
diff --git a/content/zh-cn/overview/reference/protocols/tcp.md
b/content/zh-cn/overview/reference/protocols/tcp.md
index 5e8f397dc0..8a19320ac5 100644
--- a/content/zh-cn/overview/reference/protocols/tcp.md
+++ b/content/zh-cn/overview/reference/protocols/tcp.md
@@ -6,6 +6,8 @@ type: docs
weight: 2
---
+
+
## 协议规范 Specification
- Magic - Magic High & Magic Low (16 bits)
diff --git a/content/zh-cn/overview/reference/protocols/triple-spec.md
b/content/zh-cn/overview/reference/protocols/triple-spec.md
new file mode 100644
index 0000000000..d66872a4a1
--- /dev/null
+++ b/content/zh-cn/overview/reference/protocols/triple-spec.md
@@ -0,0 +1,322 @@
+---
+description: "Triple 协议规范"
+linkTitle: Triple 协议规范
+title: Triple 协议设计理念与规范
+type: docs
+weight: 1
+working_in_progress: true
+---
+
+## 1 协议设计理念
+Triple 协议的设计参考了 gRPC、gRPC-Web、通用 HTTP
等多种协议模式，吸取每个协议各自的特性和优点，最终设计成为一个易于浏览器访问、完全兼容 gRPC 且支持 Streaming 通信的协议，Triple
支持同时运行在 HTTP/1、HTTP/2 协议之上。
+
+Triple 协议的设计目标如下：
+* Triple 设计为对人类、开发调试友好的一款基于 HTTP 的协议，尤其是对 unary 类型的 RPC 请求。
+* 完全兼容基于 HTTP/2 的 gRPC 协议，因此 Dubbo Triple 协议实现可以 100% 与 gRPC 体系互调互通。
+* 仅依赖标准的、被广泛使用的 HTTP 特性，以便在实现层面可以直接依赖官方的标准 HTTP 网络库。
+
+当与 Protocol Buffers 一起使用时（即使用 IDL 定义服务），Triple 协议可支持
unary、client-streaming、server-streaming 和 bi-streaming RPC 通信模式，支持二进制
Protobuf、JSON 两种数据格式 payload。 Triple 实现并不绑定 Protocol Buffers，比如你可以使用 Java
接口定义服务，Triple 协议有对这种模式的扩展 Content-type 支持。
+
+## 2 示例
+### 2.1 Unary 请求
+
+以 HTTP/1 请求为例，目前 HTTP/1 协议仅支持 Unary RPC，支持使用 application/proto 和
application/json 编码类型，使用方式与 REST 风格请求保持一致，同时响应也包含常规的 HTTP 响应编码（如 200 OK）。
+
+```text
+> POST /org.apache.dubbo.demo.GreetService/Greet HTTP/1.1
+> Host: 127.0.0.1:30551
+> Content-Type: application/json
+>
+> ["Dubbo"]
+
+< HTTP/1.1 200 OK
+< Content-Type: application/json
+<
+< {"greeting": "Hello, Dubbo!"}
+```
+
+一个包含指定超时时间的调用请求。
+
+```text
+> POST /org.apache.dubbo.demo.GreetService/Greet HTTP/1.1
+> Host: 127.0.0.1:30551
+> Content-Type: application/json
+> Rest-service-timeout: 5000
+>
+> ["Dubbo"]
+
+< HTTP/1.1 200 OK
+< Content-Type: application/json
+<
+< {"greeting": "Hello, Buf!"}
+```
+
+> 目前仅支持 POST 请求类型，我们将考虑在未来支持 GET 请求类型，GET 请求可能适用于具有幂等属性的一些服务调用。
+
+### 2.2 Streaming 调用请求
+
+Triple 仅支持在 HTTP/2 上支持 Streaming RPC。并且为了与 gRPC 协议保持兼容，Triple 在 HTTP/2
协议实现上（包含 Streaming RPC）保持与标准 gRPC 协议完全一致。
+
+Request
+
+```text
+HEADERS (flags = END_HEADERS)
+:method = POST
+:scheme = http
+:path = /google.pubsub.v2.PublisherService/CreateTopic
+:authority = pubsub.googleapis.com
+grpc-timeout = 1S
+content-type = application/grpc+proto
+grpc-encoding = gzip
+authorization = Bearer y235.wef315yfh138vh31hv93hv8h3v
+
+DATA (flags = END_STREAM)
+<Length-Prefixed Message>
+```
+
+Response
+
+```text
+HEADERS (flags = END_HEADERS)
+:status = 200
+grpc-encoding = gzip
+content-type = application/grpc+proto
+
+DATA
+<Length-Prefixed Message>
+
+HEADERS (flags = END_STREAM, END_HEADERS)
+grpc-status = 0 # OK
+trace-proto-bin = jher831yy13JHy3hc
+```
+
+## 3 规范详情
+
+Triple 协议支持同时运行在 HTTP/1 和 HTTP/2 协议之上，其包含以下两部分内容：
+1. 一套自定义的精简 HTTP RPC 子协议，支持 HTTP/1 和 HTTP/2 作为传输层实现，仅支持 Request-Response 类型的
Unary RPC。
+2. 一套基于 gRPC 协议的扩展子协议（仍保持和 gRPC 的 100% 兼容），仅支持 HTTP/2 实现，支持 Streaming RPC。
+
+### 3.1 Triple 之 HTTP RPC 协议
+
+大部分的 RPC 调用都是 unary (request-response) 模式的。Triple HTTP RPC 协议 unary
模式能很好的满足后端服务间的数据传输需求，同时可以让浏览器、cURL 以及其他一些 HTTP 工具更容易的访问后端服务，即使用标准的 HTTP
协议发起调用即可。
+
+Triple HTTP RPC 同时支持 HTTP/1、HTTP/2 作为底层传输层协议，在实现上对应支持的 content-type 类型为
application/json、application/proto
+
+#### 3.1.1 请求 Request
+
+- Request → Request-Headers Bare-Message
+- Request-Headers → Call-Specification *Leading-Metadata
+- Call-Specification →
+Schema Http-Method Path Http-Host Content-Type TRI-Service-Timeout
TRI-Service-Version TRI-Service-Group
+Content-Encoding Accept-Encoding Accept Content-Length
+- Scheme → "http" / "https"
+- Http-Method → POST
+- Path → /Service-Name/Method-Name; case-sensitive
+- Service-Name → service interface full classname
+- Method-Name → service interface declared method`s name
+- Http-Host → Target-IP:Target-Port
+- Target-IP → target server ip or domain
+- Target-Port → target server process port
+- Content-Type → “Content-Type: ” “application/” Message-Codec
+- Message-Codec → (“json” / {custom})
+- TRI-Protocol-Version → "tri-protocol-version" "1"
+- TRI-Service-Timeout → “tri-service-timeout: ” Timeout-Milliseconds
+- Timeout-Milliseconds → positive integer
+- TRI-Service-Version → “tri-unary-service-version: ” Version
+- Version → dubbo service version
+- TRI-Service-Group → "tri-service-group: " Group
+- Group → dubbo service group
+- Content-Encoding → “content-encoding” Content-Coding
+- Content-Coding → “identity” / “gzip” / “br” / “zstd” / {custom}
+- Accept-Encoding → “accept-encoding” Content-Coding *("," [" “]
Content-Coding) ; subset of HTTP quality value syntax
+- Content-Length → length of the encoded payload
+- Leading-Metadata → Custom-Metadata
+- Custom-Metadata → ASCII-Metadata / Binary-Metadata
+- ASCII-Metadata → Header-Name ASCII-Value
+- Binary-Metadata → {Header-Name "-bin"} {base64-encoded value}
+- Header-Name → 1*( %x30-39 / %x61-7A / "_" / "-" / ".") ; 0-9 a-z _ - .
+- ASCII-Value → 1*( %x20-%x7E ) ; space & printable ASCII
+- Bare-Message → data that encoded by json or custom and Content-Encoding
+
+Triple 协议请求的仅支持 POST 请求，请求 path 为 interfaceName/methodName，为了实现调用超时机制，需要添加
tri-service-timeout (单位 ms)，
+
+Dubbo 框架支持基于 **分组（group）** 和 **版本（version）** 的服务隔离机制，因此 Triple 协议中引入了
tri-service-group、tri-service-version 支持。
+
+**Request-Headers** 以标准的 HTTP header 的形式发送，如果收到的 headers 数量过多，server 可返回相应错误信息。
+
+**TRI-Protocol-Version** 头用来区分具有相同 Content-Type 的 triple 协议请求和其他协议请求，因为
application/json 格式的 Content-Type 非常普遍。所有的 Dubbo 原生客户端实现都应该在请求中携带
TRI-Protocol-Version，Dubbo 服务端或代理可以选择拒绝没有 TRI-Protocol-Version 的请求并返回
Http-Status 400 错误。
+
+如果 Server 不支持 **Message-Codec** 指定的编码格式，则必须返回标准 HTTP 415 编码表明 Unsupported
Media Type 异常。
+
+**Bare-Message** 即请求 payload 采用有序的数组编码形式，将方法的参数按顺序进行 Array 封装后进行 json
序列化，方法参数的位置与数组下标保持一致，当 Triple server 接收到请求体时，根据每个参数的类型进行反序列化成对应的参数数组。如果
Content-Encoding 指定了相应值，则 payload 将被压缩。Bare-Message 将作为 HTTP Body 在链路上传输。
+
+##### Request 报文示例
+
+- 请求行
+ - POST /org.apache.dubbo.demo.GreetService/greeting HTTP/1.1
+- 请求头
+ - Host: 127.0.0.1:30551
+ - Content-Type: application/json
+ - Accept: application/json
+ - Content-Length: 11
+ - Accept-Encoding: compress, gzip
+ - tri-service-version: 1.0.0
+ - tri-service-group: dubbo
+ - tri-service-timeout: 3000
+- 请求体
+ - [{"world"}]
+
+```latex
+POST /org.apache.dubbo.demo.GreetService/Greet HTTP/1.1
+Host: 127.0.0.1:30551
+Content-Type: application/json
+Accept: application/json
+Content-Length: 11
+Accept-Encoding: compress, gzip
+tri-service-version: 1.0.0
+tri-service-group: dubbo
+tri-service-timeout: 3000
+
+[{"world"}]
+```
+
+
+#### 3.1.2 响应 Response
+
+- Response → Response-Headers *Bare-Message
+- Response-Headers → HTTP-Status Content-Type [Content-Encoding]
[Accept-Encoding] *Leading-Metadata *Prefixed-Trailing-Metadata
+- HTTP-Status → 200 /{error code translated to HTTP}
+- Bare-Message → data that encoded by Content-Type and Content-Encoding
+
+对于成功 Response 响应 **HTTP-Status** 是 200，在这种场景下，响应体的 Content-Type 将保持和请求体的
Content-Type 保持一致。**Bare-Message** 就是 RPC 响应的 Payload，以 Content-Type
指定的方式进行编码并且以 Content-Encoding 来压缩（如果指定了 Content-Encoding 的话）。Bare-Message 作为
HTTP response body 发送。
+
+异常 Response 响应的 HTTP-Status 是 non-200，并且都是标准的 HTTP status
code，在这个场景下，**Content-Type** 必须是 "application/json"。**Bare-Message** 可以是空的，如果
Bare-Message 有值的话则是一个标准 JSON 格式数据，如果 **Content-Encoding**
有指定的话则是一个压缩过的数据，Bare-Message 作为标准的 HTTP response body 发送回调用方。客户端可以根据以下表格，查询
HTTP-Status 与 RPC status 之间的映射关系，以了解具体的 RPC 错误情况。
+
+##### Response 报文格式
+** 成功响应 **
+
+```latex
+HTTP/1.1 200 OK
+Content-Type: application/json
+Content-Length: 11
+
+hello world
+```
+
+** 失败响应 **
+
+```latex
+HTTP/1.1 400 Bad Request
+Content-Type: application/json
+Content-Length: 46
+{"status":20,"message":"request format error"}
+```
+
+#### 3.1.3 Error Codes
+
+Dubbo 的错误码参考
+
+```
+ status http-status message
+ 20 200 ok
+ 25 400 serialization error
+ 30 408 client side timeout
+ 31 408 server side timeout
+ 35 500 channel inactive,
directly return the unfinished requests
+ 40 400 request format error
+ 50 500 response format error
+ 60 404 service not found.
+ 70 500 service error
+ 80 500 internal server error
+ 90 500 internal client error
+```
+
+> Connect 的 HTTP to Error Code 参考
+>
+> | HTTP Status | Inferred Code |
+> | --- | --- |
+> | 400 Bad Request | invalid_argument |
+> | 401 Unauthorized | unauthenticated |
+> | 403 Forbidden | permission_denied |
+> | 404 Not Found | unimplemented |
+> | 408 Request Timeout | deadline_exceeded |
+> | 409 Conflict | aborted |
+> | 412 Precondition Failed | failed_precondition |
+> | 413 Payload Too Large | resource_exhausted |
+> | 415 Unsupported Media Type | internal |
+> | 429 Too Many Requests | unavailable |
+> | 431 Request Header Fields Too Large | resource_exhausted |
+> | 502 Bad Gateway | unavailable |
+> | 503 Service Unavailable | unavailable |
+> | 504 Gateway Timeout | unavailable |
+> | _all others_ | unknown |
+
+
+### 3.2 Triple 之扩展版 gRPC 协议
+
+Triple 协议的 Streaming 请求处理完全遵循 gRPC 协议规范，且仅支持 HTTP/2 作为传输层协议。
+
+Triple 支持的 content-type 类型为标准的 gRPC 类型，包括
application/grpc、application/grpc+proto、application/grpc+json，除此之外，Triple
在实现上还扩展了 application/triple+wrapper 编码格式。
+
+#### 3.2.1 Outline
+
+The following is the general sequence of message atoms in a GRPC request &
response message stream
+
+* Request → Request-Headers \*Length-Prefixed-Message EOS
+* Response → (Response-Headers \*Length-Prefixed-Message Trailers) /
Trailers-Only
+
+
+#### 3.2.2 Requests
+
+* Request → Request-Headers \*Length-Prefixed-Message EOS
+
+Request-Headers are delivered as HTTP2 headers in HEADERS + CONTINUATION
frames.
+
+* **Request-Headers** → Call-Definition \*Custom-Metadata
+* **Call-Definition** → Method Scheme Path TE [Authority] [Timeout]
Content-Type [Message-Type] [Message-Encoding] [Message-Accept-Encoding]
[User-Agent] Service-Version Service-Group Tracing-ID Tracing-Span-ID
Cluster-Info
+* **Method** → ":method POST"
+* **Scheme** → ":scheme " ("http" / "https")
+* **Path** → ":path" "/" Service-Name "/" {_method name_} # But see note
below.
+* **Service-Name** → {_IDL-specific service name_}
+* **Authority** → ":authority" {_virtual host name of authority_}
+* **TE** → "te" "trailers" # Used to detect incompatible proxies
+* **Timeout** → "grpc-timeout" TimeoutValue TimeoutUnit
+* **TimeoutValue** → {_positive integer as ASCII string of at most 8 digits_}
+* **TimeoutUnit** → Hour / Minute / Second / Millisecond / Microsecond /
Nanosecond
+ * **Hour** → "H"
+ * **Minute** → "M"
+ * **Second** → "S"
+ * **Millisecond** → "m"
+ * **Microsecond** → "u"
+ * **Nanosecond** → "n"
+* **Content-Type** → "content-type" "application/grpc" [("+proto" / "+json" /
{_custom_})]
+* **Content-Coding** → "identity" / "gzip" / "deflate" / "snappy" / {_custom_}
+* <a name="message-encoding"></a>**Message-Encoding** → "grpc-encoding"
Content-Coding
+* **Message-Accept-Encoding** → "grpc-accept-encoding" Content-Coding \*(","
Content-Coding)
+* **User-Agent** → "user-agent" {_structured user-agent string_}
+* **Message-Type** → "grpc-message-type" {_type name for message schema_}
+* **Custom-Metadata** → Binary-Header / ASCII-Header
+* **Binary-Header** → {Header-Name "-bin" } {_base64 encoded value_}
+* **ASCII-Header** → Header-Name ASCII-Value
+* **Header-Name** → 1\*( %x30-39 / %x61-7A / "\_" / "-" / ".") ; 0-9 a-z \_ - .
+* **ASCII-Value** → 1\*( %x20-%x7E ) ; space and printable ASCII
+* Service-Version → "tri-service-version" {Dubbo service version}
+* Service-Group → "tri-service-group" {Dubbo service group}
+* Tracing-ID → "tri-trace-traceid" {tracing id}
+* Tracing-RPC-ID → "tri-trace-rpcid" {_span id _}
+* Cluster-Info → "tri-unit-info" {cluster infomation}
+
+#### 3.2.3 Responses
+
+* **Response** → (Response-Headers \*Length-Prefixed-Message Trailers) /
Trailers-Only
+* **Response-Headers** → HTTP-Status [Message-Encoding]
[Message-Accept-Encoding] Content-Type \*Custom-Metadata
+* **Trailers-Only** → HTTP-Status Content-Type Trailers
+* **Trailers** → Status [Status-Message] \*Custom-Metadata
+* **HTTP-Status** → ":status 200"
+* **Status** → "grpc-status" 1\*DIGIT ; 0-9
+* **Status-Message** → "grpc-message" Percent-Encoded
+* **Percent-Encoded** → 1\*(Percent-Byte-Unencoded / Percent-Byte-Encoded)
+* **Percent-Byte-Unencoded** → 1\*( %x20-%x24 / %x26-%x7E ) ; space and VCHAR,
except %
+* **Percent-Byte-Encoded** → "%" 2HEXDIGIT ; 0-9 A-F
+
+以上即为 Triple 扩展版本的 gRPC 协议，更多详细规范说明请参照 <a
href="https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md";
target="_blank">gRPC 协议规范</a>。
\ No newline at end of file
diff --git a/content/zh-cn/overview/reference/protocols/triple.md
b/content/zh-cn/overview/reference/protocols/triple.md
index 1bc9c44bce..3c5b7f7556 100644
--- a/content/zh-cn/overview/reference/protocols/triple.md
+++ b/content/zh-cn/overview/reference/protocols/triple.md
@@ -1,38 +1,39 @@
---
-description: "HTTP/2 (Triple) 协议规范"
-linkTitle: Triple 协议规范
-title: Triple 协议设计理念与规范
+description: "Triple 协议优势与目标：Triple 协议是 Dubbo3 设计的基于 HTTP 的 RPC 通信协议规范，它完全兼容
gRPC 协议并可同时运行在 HTTP/1 和 HTTP/2 之上。"
+linkTitle: Triple 协议优势与目标
+title: Triple 协议优势与目标
type: docs
weight: 1
+working_in_progress: true
---
## 简介
-Triple 协议是 Dubbo3 设计的基于 HTTP 的 RPC 通信协议规范，它基于 gRPC 设计而来因此可以完全兼容 gRPC 协议，可同时运行在
HTTP/1 和 HTTP/2 之上。
+Triple 协议是 Dubbo3 设计的基于 HTTP 的 RPC 通信协议规范，它完全兼容 gRPC 协议，支持
Request-Response、Streaming 流式等通信模型，可同时运行在 HTTP/1 和 HTTP/2 之上。
Dubbo 框架提供了 Triple 协议的多种语言实现，它们可以帮助你构建浏览器、gRPC 兼容的 HTTP API 接口：你只需要定义一个标准的
Protocol Buffer 格式的服务并实现业务逻辑，Dubbo 负责帮助生成语言相关的 Server Stub、Client
Stub，并将整个调用流程无缝接入如路由、服务发现等 Dubbo 体系。Go、Java 等语言的 Triple 协议实现原生支持 HTTP/1
传输层通信，相比于 gRPC 官方实现，Dubbo 框架提供的协议实现更简单、更稳定，帮助你更容易的开发和治理微服务应用。
针对某些语言版本，Dubbo 框架还提供了更贴合语言特性的编程模式，即不绑定 IDL 的服务定义与开发模式，比如在 Dubbo Java 中，你可以选择使用
Java Interface 和 Pojo 类定义 Dubbo 服务，并将其发布为基于 Triple 协议通信的微服务。
## 协议规范(Specification)
-Triple 协议是参考 gRPC 与 gRPC-Web 两个协议设计而来，它吸取了两个协议各自的特性和优点，将它们整合在一起，成为一个完全兼容 gRPC
且支持 Streaming 通信的协议，同时 Triple 还支持 HTTP/1、HTTP/2。
+基于 Triple 协议，你可以实现以下目标：
-Triple 协议的设计目标如下：
-* Triple 设计为对人类友好、开发调试友好的一款基于 HTTP 的协议，尤其是对 unary 类型的 RPC 请求。
-* 完全兼容基于 HTTP/2 的 gRPC 协议，因此 Dubbo Triple 协议实现可以 100% 与 gRPC 体系互调互通。
-* 仅依赖标准的、被广泛使用的 HTTP 特性，以便在实现层面可以直接依赖官方的标准 HTTP 网络库。
+### 当 Dubbo 作为 Client 时
+Dubbo Client 可以访问 Dubbo 服务端 (Server) 发布的 Triple 协议服务，同时还可以访问标准的 gRPC 服务端。
+* 调用标准 gRPC 服务端，发送 Content-type 为标准 gRPC 类型的请求：application/grpc,
application/grpc+proto, and application/grpc+json
+* 调用 Dubbo 服务端，发送 Content-type 为 Triple 类型的请求：application/json,
application/proto, application/triple+wrapper
-当与 Protocol Buffers 一起使用时，Dubbo Triple 协议实现支持
unary、client-streaming、server-streaming 和 bi-streaming RPC，可以支持二进制
Protobuf、JSON 两种数据 payload。Triple 协议不使用 HTTP trailers，因此可以与任何网络基础设施配合使用。
+### 当 Dubbo 作为 Server 时
+Dubbo Server 默认将同时发布对 Triple、gRPC 协议的支持，并且 Triple 协议可以同时工作在 HTTP/1、HTTP/2
之上。因此，Dubbo Server 可以处理 Dubbo 客户端发过来的 Triple 协议请求，可以处理标准的 gRPC 协议请求，还能处理
cURL、浏览器发送过来的 HTTP 请求。以 Content-type 区分就是：
+* 处理 gRPC 客户端发送的 Content-type 为标准 gRPC
类型的请求：application/grpc、application/grpc+proto、application/grpc+json
+* 处理 Dubbo 客户端发送的 Content-type 为 Triple
类型的请求：application/json、application/proto、application/grpc+wrapper
+* 处理 cURL、浏览器等发送的 Content-type 为 Triple
类型的请求：application/json、application/proto、application/grpc+wrapper
-Unary RPC使用 application/grpc+proto 和 application/json 内容类型，看起来类似于精简的 REST
方言。大多数请求都是 POST，路径是从 Protobuf 模式派生的，请求和响应主体是有效的 Protobuf 或 JSON（没有 gRPC
风格的二进制框架），响应具有有意义的 HTTP 状态代码。
+详细在此查看详细的 [Triple Specification](../triple-spec)。
-请参考以下文档编写详细的 Triple Specification。
-* [参考文档1](https://connect.build/docs/protocol/)
-* [参考文档2](https://github.com/grpc/grpc/edit/master/doc/PROTOCOL-HTTP2.md)
+## 与 gRPC 协议的关系
+上面提到 Triple 完全兼容 gRPC 协议，那既然 gRPC 官方已经提供了多语言的框架实现，为什么 Dubbo 还要通过 Triple
重新实现一遍那？核心目标主要有以下两点：
-## 为什么要再实现一遍 gRPC 协议
-既然 gRPC 官方已经提供了多语言的框架实现，为什么 Dubbo 还要重新实现一遍那？核心目标主要有以下两点：
-
-* 首先，在协议设计上，Dubbo 参考 gRPC 与 gRPC-Web 两个协议设计了自定义的 Triple 协议：Triple 是一个基于 HTTP
传输层协议的 RPC 协议，它完全兼容 gRPC，可以同时运行在 HTTP/1、HTTP/2 之上。
+* 首先，在协议设计上，Dubbo 参考 gRPC 与 gRPC-Web 两个协议设计了自定义的 Triple 协议：Triple 是一个基于 HTTP
传输层协议的 RPC 协议，它完全兼容 gRPC 的同时可运行在 HTTP/1、HTTP/2 之上。
* 其次，Dubbo 框架在每个语言的实现过程中遵循了符合框架自身定位的设计理念，相比于 grpc-java、grpc-go 等框架库，Dubbo
协议实现更简单、更纯粹，尝试在实现上规避 gRPC 官方库中存在的一系列问题。
gRPC 本身作为 RPC 协议规范非常优秀，但我们发现原生的 gRPC 库实现在实际使用存在一系列问题，包括实现复杂、绑定 IDL、难以调试等，Dubbo
在协议设计与实现上从实践出发，很好的规避了这些问题：
@@ -57,7 +58,7 @@ Dubbo 提供的 Triple 协议实现非常简单，对应 Dubbo 中的 Protocol
Dubbo 完全兼容 gRPC 协议及相关特性包括 streaming、trailers、error details 等，你选择直接在 Dubbo
框架中使用 Triple 协议（另外，你也可以选择使用原生的 gRPC 协议），然后你就可以直接使用 Dubbo
客户端、curl、浏览器等访问你发布的服务。在与 gRPC 生态互操作性方面，任何标准的 gRPC 客户端，都可以正常访问 Dubbo 服务；Dubbo
客户端也可以调用任何标准的 gRPC 服务，这里有提供的
[互操作性示例](https://github.com/apache/dubbo-samples/tree/master/3-extensions/protocol/dubbo-samples-triple/src/main/java/org/apache/dubbo/sample/tri/interop)
-以下是使用 curl 客户端访问 Dubbo 服务端一个 Triple 协议服务的示例：
+以下是使用 cURL 客户端访问 Dubbo 服务端 Triple 协议服务的示例：
```sh
curl \
diff --git a/data/announcements/zh/scheduled.yaml
b/data/announcements/zh/scheduled.yaml
index 37dfd30a90..a5c5aa38a9 100644
--- a/data/announcements/zh/scheduled.yaml
+++ b/data/announcements/zh/scheduled.yaml
@@ -22,7 +22,7 @@ announcements:
我们非常高兴地宣布，Dubbo 3.2 已经正式发布了！这个版本带来了许多新功能和改进，也是 Dubbo
在面对云原生化的当下的一次重要的尝试。<br /><br />
欢迎扫描右侧二维码关注 Apache Dubbo 微信公众号！
- name: CommunityOverCode 2023
- startTime: 2023-07-05T00:00:00
+ startTime: 2023-07-30T00:00:00
endTime: 2023-08-20T18:00:00
style: >-
background-image: linear-gradient(90deg, rgb(249, 145, 6) 0%, rgb(252,
29, 68) 100%);
diff --git a/static/imgs/blog/2023/6/graalvm/graalvm-copilation2.png
b/static/imgs/blog/2023/6/graalvm/graalvm-compilation2.png
similarity index 100%
rename from static/imgs/blog/2023/6/graalvm/graalvm-copilation2.png
rename to static/imgs/blog/2023/6/graalvm/graalvm-compilation2.png
