This is an automated email from the ASF dual-hosted git repository.
albumenj 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 b2f839de7bd Add triple blog (#1778)
b2f839de7bd is described below
commit b2f839de7bda07a1611c4e3bfe1736e92567e1d3
Author: Albumen Kevin <[email protected]>
AuthorDate: Wed Dec 28 21:06:33 2022 +0800
Add triple blog (#1778)
---
.../blog/java/codeanalysis/triple-backpressure.md | 111 +++++++++++++++++++++
static/imgs/blog/2022/12/28/triple/1.png | Bin 0 -> 403771 bytes
static/imgs/blog/2022/12/28/triple/2.png | Bin 0 -> 1058411 bytes
static/imgs/blog/2022/12/28/triple/3.png | Bin 0 -> 711198 bytes
static/imgs/blog/2022/12/28/triple/4.png | Bin 0 -> 119297 bytes
static/imgs/blog/2022/12/28/triple/5.png | Bin 0 -> 179812 bytes
static/imgs/blog/2022/12/28/triple/6.png | Bin 0 -> 611762 bytes
static/imgs/blog/2022/12/28/triple/7.png | Bin 0 -> 1329508 bytes
static/imgs/blog/2022/12/28/triple/8.png | Bin 0 -> 492419 bytes
static/imgs/blog/2022/12/28/triple/9.png | Bin 0 -> 1140060 bytes
10 files changed, 111 insertions(+)
diff --git a/content/zh/blog/java/codeanalysis/triple-backpressure.md
b/content/zh/blog/java/codeanalysis/triple-backpressure.md
new file mode 100644
index 00000000000..d2c4c11ed48
--- /dev/null
+++ b/content/zh/blog/java/codeanalysis/triple-backpressure.md
@@ -0,0 +1,111 @@
+---
+title: "Dubbo 3 之 Triple 流控反压原理解析"
+linkTitle: "Dubbo 3 之 Triple 流控反压原理解析"
+date: 2022-12-28
+author: 顾欣
+description: >
+ 一文了解 Dubbo 3 中基于Triple 协议实现的流控反压原理。。
+---
+
+Triple 是 Dubbo 3 提出的基于 HTTP2 的开放协议，
+旨在解决 Dubbo 2 私有协议带来的互通性问题。
+Triple 基于 HTTP/2 定制自己的流控，支持通过特定的异常通知客户端业务层服务端负载高情况，
+保护了服务端被大流量击垮，提高系统高可用能力。
+
+# 一、流控反压现状
+
+客户端和服务器端在接收数据的时候有一个缓冲区来临时存储数据，
+但是缓冲区的大小是有限制的，所以有可能会出现缓冲区溢出的情况，
+HTTP 通过流控保护数据溢出丢失风险。
+
+## 1、HTTP/1 流控
+
+在 HTTP/1.1 中，流量的控制依赖的是底层TCP协议，在客户端和服务器端建立连接的时候，
+会使用系统默认的设置来建立缓冲区。在数据进行通信的时候，会告诉对方它的接收窗口的大小，
+这个接收窗口就是缓冲区中剩余的可用空间。如果接收窗口大小为零，则说明接收方缓冲区已满，
+则发送方将不再发送数据，直到客户端清除其内部缓冲区，然后请求恢复数据传输。
+
+## 2、HTTP/2 流控
+
+HTTP/2 使用了多路复用机制，一个TCP连接可以有多个 HTTP/2 连接，
+故在 HTTP/2 中，有更加精细的流控制机制，允许服务端实现自己数据流和连接级的流控制。
+服务端与客户端初次见了连接时，会通过发送 `HTTP/2 SettingsFrame`设置初始化的流控窗口大小，
+用于 `Stream` 级别流控，默认为 65,535 字节。
+定好流控窗口后，每次客户端发送数据就会减少流控窗口的大小，
+服务端收到数据后会发送窗口更新包（`WINDOW_UPDATE frame`）通知客户端更新窗口。
+客户端收到窗口更新包后就会增加对应值的流控窗口，从而达到动态控制的目的。
+
+
+
+# 二、Triple流控反压
+
+Netty 基于 HTTP/2 实现了基础的流控，当服务端负载过高，客户端发送窗口为 0 时，
+新增请求就无法被发送出去，会在缓存到客户端待发送请求队列中，缓存数据过大，
+就会造成客户端内存溢出，影响业务程序。
+
+Triple 基于 Netty 实现了 HTTP/2 协议，通过 `HTTP/2 FlowController`接口统一封装，
+在实现分为进站（inbound）和出站（outbound）两个维度的实现。
+Triple 在 inbound 流量上使用了 Netty 的默认流控实现，
+在 outbound 上实现了自己流控，基于服务端负载，
+将服务端流量压力透传到客户端业务层，实现客户端的业务反压，暂停业务继续发送请求，
+保护服务端不被大流量击垮。
+
+## 1 连接初始化
+
+Triple在初次建立连接时，通过 `TripleHttpProtocol` 初始化 HTTP/2 配置，
+默认流控窗口 `DEFAULT_WINDOW_INIT_SIZE = MIB_8`，
+并在服务端和客户端加入自己的 outbound 流控接口。
+
+
+
+## 2 Inbound流控
+
+Inbound 流量会通过 `DefaultHttpLocalFlowController` 的 `consumeBytes` 方法实现流控窗口更新与发送。
+
+### 1.入口传入HTTP 流与更新数据大小
+
+
+
+### 2.找到对应连接实现数据消费
+
+
+
+### 3.更新流控窗口
+
+
+
+### 4.发送流控更新数据包（window_update）
+
+
+
+## 3 Outbound流控
+
+Outbound 通过 Triple 自己的流控实现 `TriHttpRemoteFlowController`，
+将服务端压力反馈到业务层，保护服务端被大流量击垮。
+
+### 1.发送数据时判断是否还有窗口
+
+
+
+### 2.窗口为0时抛出特定异常
+
+
+
+### 3.反馈客户端流控异常
+
+
+
+## 4 总结
+
+Triple 通过将底层客户端发送窗口为 0 场景封装为特定流控异常，
+透传至客户端上层业务，阻止客户端业务继续数据发送，
+有效的保护了服务端被大流量击垮和客户端的内存溢出的问题。
+
+# 三、未来展望
+
+目前 Triple 已经基本实现了流控反压能力，未来我们将深度联动业务，
+基于业务负载自适应调整反压流控，
+一是在 inbound 上将流控窗口包发送时机调整到服务端业务处理完成后，
+二是在 outbound 流量上关联客户端业务层，动态调整客户端发送速率。
+从而实现基于服务端业务负载动态反压流控机制。
+
diff --git a/static/imgs/blog/2022/12/28/triple/1.png
b/static/imgs/blog/2022/12/28/triple/1.png
new file mode 100644
index 00000000000..851a22c8689
Binary files /dev/null and b/static/imgs/blog/2022/12/28/triple/1.png differ
diff --git a/static/imgs/blog/2022/12/28/triple/2.png
b/static/imgs/blog/2022/12/28/triple/2.png
new file mode 100644
index 00000000000..f20b9db6f6b
Binary files /dev/null and b/static/imgs/blog/2022/12/28/triple/2.png differ
diff --git a/static/imgs/blog/2022/12/28/triple/3.png
b/static/imgs/blog/2022/12/28/triple/3.png
new file mode 100644
index 00000000000..35664fcf558
Binary files /dev/null and b/static/imgs/blog/2022/12/28/triple/3.png differ
diff --git a/static/imgs/blog/2022/12/28/triple/4.png
b/static/imgs/blog/2022/12/28/triple/4.png
new file mode 100644
index 00000000000..5671be37061
Binary files /dev/null and b/static/imgs/blog/2022/12/28/triple/4.png differ
diff --git a/static/imgs/blog/2022/12/28/triple/5.png
b/static/imgs/blog/2022/12/28/triple/5.png
new file mode 100644
index 00000000000..19a7e0cd841
Binary files /dev/null and b/static/imgs/blog/2022/12/28/triple/5.png differ
diff --git a/static/imgs/blog/2022/12/28/triple/6.png
b/static/imgs/blog/2022/12/28/triple/6.png
new file mode 100644
index 00000000000..f9d1f4617ee
Binary files /dev/null and b/static/imgs/blog/2022/12/28/triple/6.png differ
diff --git a/static/imgs/blog/2022/12/28/triple/7.png
b/static/imgs/blog/2022/12/28/triple/7.png
new file mode 100644
index 00000000000..6317165fc9f
Binary files /dev/null and b/static/imgs/blog/2022/12/28/triple/7.png differ
diff --git a/static/imgs/blog/2022/12/28/triple/8.png
b/static/imgs/blog/2022/12/28/triple/8.png
new file mode 100644
index 00000000000..9f92be148bf
Binary files /dev/null and b/static/imgs/blog/2022/12/28/triple/8.png differ
diff --git a/static/imgs/blog/2022/12/28/triple/9.png
b/static/imgs/blog/2022/12/28/triple/9.png
new file mode 100644
index 00000000000..3291a19e6c8
Binary files /dev/null and b/static/imgs/blog/2022/12/28/triple/9.png differ
