k6项目中HTTP/2请求序列异常问题的分析与解决

问题背景

在使用k6进行负载测试时，开发人员遇到了一个奇怪的HTTP/2请求序列问题。具体表现为：在特定的GET和POST请求交替序列中，k6会在第二个POST请求时"挂起"，无法完成请求。这个问题特别出现在通过Akamai CDN访问的服务上，而直接访问后端服务则不会出现。

问题现象

测试序列如下：

1. 发送GET请求
2. 发送GET请求
3. 发送POST请求（16KB请求体）
4. 发送GET请求
5. 发送GET请求
6. 发送POST请求（16KB请求体）→ 此处请求挂起

有趣的是，如果只发送GET请求或只发送POST请求，测试都能正常运行。问题仅出现在GET和POST请求交替发送时。

深入分析

通过GODEBUG=http2debug=2的调试输出和代码追踪，发现问题的核心在于HTTP/2的流控制机制：

1. 在第一个POST请求时，16KB的数据被完整发送（16384字节）
2. 但在第二个POST请求时，只发送了16383字节，缺少最后一个字节
3. 客户端等待流控制窗口更新，但从未收到，导致永久阻塞

进一步分析发现，问题实际上是由于代码中的对象共享导致的意外行为。测试脚本中使用了Object.assign(options1, options2)而不是Object.assign({}, options1, options2)，导致GET请求意外携带了POST请求的body。

HTTP/2协议层面的理解

HTTP/2协议中，流控制是一个重要特性，用于防止发送方压倒接收方。每个流都有一个初始窗口大小（默认为65535字节），发送方需要等待接收方通过WINDOW_UPDATE帧更新窗口后才能继续发送数据。

在这个案例中，Akamai对带有body的GET请求的处理方式似乎破坏了流控制状态机，导致后续POST请求无法正确完成。而其他HTTP/2实现（如nghttp2和Spring Boot）则能正确处理这种非标准请求。

解决方案

1. 修复测试脚本，确保GET请求不会携带body：

   // 错误方式 - 会共享对象引用
   Object.assign(options1, options2);
   
   // 正确方式 - 创建新对象
   Object.assign({}, options1, options2);
   

2. 在Akamai端配置更宽容的HTTP/2实现，能够优雅处理非标准请求

经验总结

1. 在编写测试脚本时，要特别注意对象引用的共享问题
2. HTTP/2虽然提供了性能优势，但也引入了新的复杂性，特别是在流控制方面
3. 不同CDN和服务器对HTTP/2的实现可能有细微差别，需要进行充分测试
4. 使用SSLKEYLOGFILE和Wireshark等工具可以极大帮助调试加密的HTTP/2流量

这个问题展示了即使看似简单的负载测试也可能隐藏着复杂的问题，需要开发者对协议细节有深入理解才能有效诊断和解决。