AWS SDK Rust 多部分上传失败问题分析与解决方案

问题背景

AWS SDK Rust 用户在升级到较新版本后遇到了多部分上传功能失效的问题。具体表现为上传过程中出现"current throughput: 0 B/s is below minimum: 1 B/s"的错误提示，导致上传操作失败。

问题现象

用户在使用aws-config 1.4.0、aws-sdk-s3 1.28.0和aws-smithy-types 1.1.9版本组合时，多部分上传功能开始出现以下错误日志：

[DEBUG] current throughput: 0 B/s is below minimum: 1 B/s
[DEBUG] grace period ended; timing out request
[DEBUG] not retrying because we are out of attempts

技术分析

这个问题源于AWS SDK Rust引入的"停滞流保护"(Stalled Stream Protection)机制。该机制旨在检测并防止上传或下载过程中出现停滞情况，默认情况下会监控传输速率，如果低于设定的最小值(默认为1B/s)，则会中断连接。

对于大文件上传场景，特别是网络条件不佳的环境，这种保护机制可能会误判正常的上传过程为停滞状态。在底层实现上，这是通过aws_smithy_runtime::client::http::body::minimum_throughput模块来监控和执行的。

解决方案

AWS SDK Rust团队提供了几种解决方案：

1. 完全禁用停滞流保护：

let config = aws_config::defaults(aws_config::BehaviorVersion::latest())
    .stalled_stream_protection(StalledStreamProtectionConfig::disabled())
    .load()
    .await;

2. 仅禁用上传部分的保护（推荐方案）：

let config = aws_config::defaults(aws_config::BehaviorVersion::latest())
    .stalled_stream_protection(
        StalledStreamProtectionConfig::enabled()
            .upload_enabled(false)
            .build(),
    )
    .load()
    .await;

3. 调整最低吞吐量阈值（如果未来版本支持）： 开发者可以设置更高的最低吞吐量阈值以适应特定网络环境。

最佳实践建议

1. 对于大文件上传场景，建议采用方案2，仅禁用上传部分的保护，保留下载保护
2. 在网络条件不稳定的环境中，考虑实现自定义的重试逻辑
3. 监控上传进度，提供用户反馈，避免长时间无响应
4. 考虑分块大小调整，找到适合当前网络环境的最佳分块大小

技术原理深入

停滞流保护机制的核心是防止资源被长时间占用而没有任何进展。它通过定期检查数据传输速率来实现：

1. 设置一个监控周期（如1秒）
2. 计算该周期内的数据传输量
3. 如果低于阈值，开始计时
4. 超过宽限期后仍低于阈值，则终止连接

对于多部分上传，每个部分的上传都是独立的HTTP请求，因此每个部分都会受到此机制的影响。在网络波动或高延迟环境下，即使实际上传在进行中，短期的速率下降也可能触发保护机制。

后续发展

AWS SDK Rust团队已意识到这一问题，并在后续版本中进行了优化。开发者应关注官方更新日志，及时获取最新的稳定性改进和功能增强。

对于特殊场景下的上传需求，建议开发者根据实际网络条件调整SDK配置，或考虑实现自定义上传策略以获得更好的控制权和适应性。