v1.0.4

本次优化

大幅提升「上行」吞吐。 此前 H2 载体的服务端从不设置流控窗口，沿用 h2 缺省的
64 KiB——整条隧道跑在一条 H2 流上，这个窗口就是上行（客户端→节点）的总窗口，
于是无论链路多快，上行都被钉死在约 8 Mbps（65ms RTT，与带宽无关）。

现将服务端上行流控窗口设为 4 MiB（连接级 8 MiB），单条流上行可达约 500 Mbps
（65ms RTT）。取值刻意比客户端（16 MiB）保守：服务端同时承载多条会话，且这个 h2
窗口不走 mux 的共享内存预算，最坏内存 = 窗口 × 并发会话数。

扩窗内存预算上调。 节点侧自适应扩窗的全节点共享内存池由 256 MiB 提到
1 GiB——它是扩窗内存的硬顶（与用户数无关），只在真正高速传输时按需支取、
空闲不占，为高带宽时延积链路留足峰值窗口余量。

重要：本次只改善「上行」，下行取决于客户端 SDK

隧道下行吞吐由客户端 SDK 的接收窗口决定，节点端已具备所需的一切。若客户端
使用的是 2026-08-19 之前构建的旧 SDK（接收窗口自适应尚未加入，固定 256 KiB），
下行仍会被钉在约 32 Mbps（65ms RTT）——这需要重新编译并下发 SDK 才能解决，
与本次节点发布相互独立。

内存提示（小内存节点）

节点扩窗预算现为 1 GiB（共享上限，非预分配，只在高速传输时按需支取）。面向内存
较大的机器（如 8 GB 的 c6in.xlarge，占比约 12%）。1–2 GB 内存的小节点在高并发
高速场景下可能吃紧，如有需要请反馈，可提供按机器内存自适应的版本。

升级

bash install.sh

配置原样保留，只换二进制并重启。向后兼容：流控窗口是 wire 上动态协商的，本次改的
是取值而非线格式，新旧节点与新旧 SDK 可混连，不必锁步升级。

产物

文件	架构
dbk-node-x86_64-unknown-linux-gnu.tar.gz	x86_64 / amd64
dbk-node-aarch64-unknown-linux-gnu.tar.gz	aarch64 / arm64

最低 glibc 2.28（Debian 10+ / Ubuntu 20.04+）。