低速网络下HTTP/2结合AWS ALB大文件下载失败问题排查

架构说明 #

client <-> AWS NLB <-> AWS ALB <-> 静态文件服务器

问题现象 #

在低速网络环境下（如限制带宽至512kbps），使用HTTP/2协议下载12MB文件时会失败，报错HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)；但切换为HTTP/1.1协议，或带宽提升至1024kbps及以上时，下载可正常完成。该现象不依赖后端服务类型，Django动态服务、uWSGI静态服务、Nginx静态服务均出现一致问题。

复现示例 #

通过Socks代理限制带宽时的失败场景：

$ curl -x socks5://localhost:1080 https://example.com/file.pdf --output "file.pdf"

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 79 12.6M   79 10.0M    0     0  61254      0  0:03:36  0:02:51  0:00:45 64422
curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

添加--http1.1参数后，相同命令可正常完成下载；带宽限制为1024kbps时，HTTP/2下载也无异常。

补充细节 #

• 问题并非curl专属，浏览器中同样出现相同故障；
• 使用curl -v未获取到额外错误信息；
• 后端服务（Nginx/uWSGI）无错误输出，日志显示请求已成功处理，示例uWSGI日志：

  [pid: 44|app: 0|req: 2603/9176] [ip] () {34 vars in 639 bytes} [Wed Oct 16 09:29:29 2024] GET /file.pdf => generated 13243923 bytes in 2425 msecs (HTTP/1.1 200) 8 headers in 314 bytes (103471 switches on core 0)
  

• AWS ALB日志无异常记录，仅显示请求“成功”但实际传输字节数远低于文件总大小。

排查方向（针对AWS ALB） #

结合现象及架构，重点排查ALB的HTTP/2相关配置与实现：

1. Idle Timeout超时配置：AWS ALB默认连接空闲超时为60秒，低速下载12MB文件（512kbps下需约3分钟）会远超该阈值。ALB可能因长时间未检测到“活跃”数据包（低速传输的数据包间隔可能接近或超过超时时间），主动断开HTTP/2连接，导致流异常关闭。建议将ALB的idle timeout调至足够覆盖大文件低速传输的时长（如300秒）后测试。
2. HTTP/2流控制与帧限制：ALB对HTTP/2的流窗口大小、最大帧大小有默认限制，低速传输时可能因流窗口耗尽后未及时更新，导致传输中断。可尝试调整ALB的HTTP/2相关参数（如增大初始窗口大小），或验证是否存在此类限制触发的问题。
3. ALB平台版本兼容性：部分旧版本ALB的HTTP/2协议实现可能存在低速大文件传输的bug，误将持续低速的流判定为异常。建议升级ALB至最新平台版本（如v2）后重试。
4. NLB与ALB间的层间交互：虽然HTTP/2问题集中在ALB层面，但NLB的四层转发配置（如超时、MTU）也可能间接影响ALB的HTTP/2处理。可临时绕过NLB直接访问ALB，验证问题是否依然存在，以排除NLB的影响。

内容的提问来源于stack exchange，提问作者Alice Heaton