wastnet 与 Undertow 性能压测对比报告

选型一个 Java Web 框架，性能是绕不开的考量。wastnet 作为一款自研、零第三方依赖的网络框架，外界很自然就会问：它和成熟的工业级服务器比，到底处在什么位置？

为此，以与 Undertow 完全相同的压测口径，跑了一组对照数据。Undertow 是 WildFly 的默认 Web 服务器，也是 Java 领域久经考验的高性能 NIO 实现，把它作为对标对象最有参考价值。本文只摆数据、做客观对比，不立高下。

需要说明：单纯用 wrk 压一个 hello 接口（极小响应、无业务、无请求体）得到的数字，往往更多反映的是事件循环与连接建立的极限，很难真实代表框架在实际负载下的吞吐水平，也容易被「跑分」带偏。因此本次测试刻意覆盖了不同响应大小、是否携带请求 body、以及 HTTP/2 / h2c 等多种场景，尽量贴近真实差异。

测试环境与方法

• 工具：wrk（HTTP/1.1）与 h2load（HTTP/1.1、HTTP/2、HTTP/2 明文 h2c）
• 用例：一个简单的 /hello 文本响应，以及带请求体（上传 payload.bin）的场景
• 两个网络位置：本机回环 localhost（服务与压测客户端同机，均运行于 Linux）；局域网 192.168.5.1（跨机，服务运行于 Windows，压测客户端从 Linux 连入；wrk / h2load 在 Windows 上不可用，故压测统一在 Linux 侧发起）
• 时间：2026-08-08，单方 15s 持续压测

机器配置

两者服务端均使用相同配置（堆固定 -Xms256m -Xmx256m、默认线程），不经过额外 JVM 调优，以保证对照一致。

指标统一以吞吐量（req/s）为主，辅以延迟分布。注意：该数值为每秒处理请求数，分值越高代表性能越好。

本机回环（localhost）结果

本机场景下两者互有胜负：wrk 的 HTTP/1.1 与「HTTP/2 + 上传 body」两项 wastnet 领先；而 Undertow 在「HTTP/2 小响应」与「HTTP/2 明文 h2c」上表现更好，尤其 h2c 领先明显。

█ wastnet　█ undertow（每组独立线性刻度，█ 越长越高）

本机回环 localhost · req/s
H1.1 wrk   ██████████████████████████████████████████████████████████████ 340,063
           █████████████████████████████████████████████████████████████ 329,911
H1.1 resp  █████████████████████████████████████████████████████████████ 320,846
           ██████████████████████████████████████████████████████████████ 327,000
H1.1 body  ██████████████████████████████ 2,817
           ██████████████████████████████████████████████████████████████ 5,834
H2 resp    ███████████████████████████████████████████████████████████ 87,731
           ██████████████████████████████████████████████████████████████ 97,867
H2 body    ██████████████████████████████████████████████████████████████ 13,258
           ███████ 1,969
h2c        ███████████████████████████ 137,307
           ██████████████████████████████████████████████████████████████ 207,489

局域网跨机（192.168.5.1）结果

跨机场景下，wastnet 在 HTTP/2（含 TLS 与 h2c）以及高并发的 HTTP/1.1 上整体占优，其中 h2c 与「HTTP/2 + 上传 body」优势较大；但在「HTTP/1.1 + 上传 body」这种受网络往返主导的用例上，两者都偏低、差距很小。

█ wastnet　█ undertow（每组独立线性刻度，█ 越长越高）

局域网跨机 192.168.5.1 · req/s
H1.1 wrk   ██████████████████████████████████████████████████████████████ 22,962
           █████████████████████████████████████████████████████████████ 22,280
H1.1 resp  ██████████████████████████████████████████████████████████████ 161,186
           ███████████████████████████████████████████████████████ 130,780
H1.1 body  ██████████████████████████████████████████████████████████████ 57
           ███████████████████████████████████████████████████ 48
H2 resp    ██████████████████████████████████████████████████████████████ 103,892
           █████████████████████████████████████████████████████ 79,544
H2 body    ██████████████████████████████████████████████████████████████ 761
           ████ 65
h2c        ██████████████████████████████████████████████████████████████ 174,081
           ███████████████████████████████████████████ 97,614

结果解读

• 操作系统是分水岭：在 Linux 上（本机回环场景，服务端运行于 Linux），Undertow 在多个用例明显占优，尤其 h2c 明文（207,489 vs 137,307）与 h2 小响应（97,867 vs 87,731）；而在 Windows 上（跨机场景，服务端运行于 Windows），wastnet 整体占优。
• 带 body 的 h2 场景是机制问题，与 OS 无关：h2load · HTTP/2（TLS）+ 上传 body 一项，无论 Linux（13,258 vs 1,969）还是 Windows（761 vs 65），wastnet 都是数倍领先。同一用例在两种操作系统下呈现一致的悬殊差距，说明这不是 OS 差异导致，而是 Undertow 在该场景下的处理机制所致（猜测与其提前响应、请求体排空 / backpressure 的处理方式有关）。这一点与上面的 OS 分水岭相互独立，是另一层面的差距。
• 没有「全面领先」：无论哪一方，都有被对方反超的用例。这正是本文采用对照而非自证的理由。

关于 Undertow

Undertow 是一款值得尊敬的成熟作品。它背靠 WildFly 生态，经过大量生产环境打磨，在连接管理、协议兼容性与稳定性上的积淀是 wastnet 这样的新框架需要长期学习的。尤其在 h2c 与部分 h2 小响应用例上，Undertow 展现出的稳健让人印象深刻。

wastnet 基于 Apache 2.0 协议完全开源、免费使用。欢迎基于真实场景复测、提 issue、共建。

相关链接

• Gitee：https://gitee.com/xiaoch0209/wastnet
• GitHub：https://github.com/wycst02/wastnet
• 协议：Apache License 2.0

附：如何独立复测

本对照所用的方法、脚本与原始数据均公开，欢迎任何人独立复测、挑刺：

• 压测方法文档：BENCHMARK.md —— 含环境准备、6 个场景定义、wrk / h2load 参数与复现步骤。
• 压测脚本：bench.sh（Linux/macOS）、bench-start.bat（Windows 启动服务）；原始数据在 bench-results/。
• 被测版本：wastnet 1.0.1、Undertow 2.2.39.Final。

本文无意用一组数字自证强弱。压测机、网络、JDK、参数任一变动都可能改变结果；本文只是一次特定条件下的快照，目的是把差距摆出来、把短板找出来。若你有更贴近真实业务的场景或不同的配置，跑出的结论不同，那恰恰是有价值的反馈——欢迎提 issue 或 PR。