<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>k6 on </title>
    <link>/tags/k6/</link>
    <description>Recent content in k6 on </description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Wed, 25 Mar 2026 16:30:00 +0800</lastBuildDate><atom:link href="/tags/k6/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Spring Boot 3.5 开启 h2c 后，真的比 HTTP/1.1 更快吗？一次完整压测实验复盘</title>
      <link>/posts/spring-boot-35-h2c-benchmark/</link>
      <pubDate>Wed, 25 Mar 2026 16:30:00 +0800</pubDate>
      
      <guid>/posts/spring-boot-35-h2c-benchmark/</guid>
      <description>如果你还没理清 h2 和 h2c 的区别，可以先看我的基础概念篇。
这一篇不再讲概念，而是回答一个更实际的问题：
Spring Boot 3.5 把 h2c 打开以后，真的会比 HTTP/1.1 更快吗？
我在自己的 Shop Platform 概念验证（POC）项目里，围绕 buyer-bff -&amp;gt; marketplace-service 做了一整轮压测。这次实验全程基于 Java 25 (LTS) 并在 Spring Boot 中开启了 虚拟线程 (Virtual Threads)。
2026-04 实践更新 当前主线仓库里，BFF 的下游调用已经进一步演进成 @HttpExchange typed clients；因此本文关于 h2c / HTTP/1.1 的性能讨论依然成立，但调用栈样例请理解为“传输层对比实验”，不再代表今天 main 分支的全部客户端装配细节。
先说这次实验里的几个观察：
不会天然更快 但在特定 workload 下，的确可能更快 关键不在“有没有开 h2c”，而在“你的请求模型有没有真的吃到多路复用”，以及虚拟线程在高并发 I/O 场景下会不会放大这件事 这篇文章就是这次实验的完整复盘。
实验背景 这个项目本身是一套基于 Spring Boot 3.5 + Java 25 的微服务电商平台 POC。BFF 层会聚合多个下游领域服务，非常适合拿来验证协议层优化。
在 Java 25 这一最新的 LTS 版本中，虚拟线程的调度已经非常成熟。我在所有服务中都开启了： spring.</description>
    </item>
    
  </channel>
</rss>
