AWS App Mesh大文件下载请求超时配置最佳实践咨询

架构与问题场景 #

基于ECS Fargate搭建的服务，集成了App Mesh、Envoy Proxy和ELB，整体运行正常，但遇到大文件下载问题：当下载请求耗时超过30秒时会失败，小文件则能正常下载。

经排查，问题根源是App Mesh Virtual Node Listener的超时设置：

• 默认未配置时，会触发30秒超时，中断大文件下载
• 设置固定长超时（如600秒），仍可能因文件过大再次触发超时
• 设置0秒超时（预期实现“无限制”），大文件下载可成功，但不确定该操作是否合规、是否存在风险

核心问题 #

• App Mesh Listener设置0秒请求超时是否属于最佳实践？
• 该操作是否会引发未知问题？
• 若不合规，如何避免App Mesh在30秒后中断文件流？

相关响应头信息 #

下载成功时的响应头示例：

HTTP/2 200 OK
date: Wed, 05 Oct 2022 09:06:45 GMT
content-type: application/octet-stream
content-length: 17325639
content-disposition: attachment; filename="a08c94a3-068e-486f-92c7-371d00984ddc.zip"
expires: Wed, 05 Oct 2022 09:07:45 GMT
cache-control: private, max-age=60
last-modified: Wed, 05 Oct 2022 07:11:28 GMT
access-control-allow-headers: Cache-Control, X-CSRF-Token, X-Requested-With
access-control-allow-origin: *
server: envoy
x-envoy-upstream-service-time: 55
X-Firefox-Spdy: h2

服务器原本设置但可能被Envoy移除的响应头：

connection: keep-alive

解答 #

1. 设置0秒请求超时是否为最佳实践？ #

不是最佳实践。虽然App Mesh允许将请求超时设为0来禁用超时，能暂时解决大文件下载问题，但这种做法等于放弃了超时保护机制，存在明显的潜在风险。

2. 可能引发的问题 #

• 资源耗尽：如果后端服务出现异常（如进程挂起、资源耗尽），无超时限制的请求会持续占用Envoy和上游服务的连接资源，可能导致连接池被占满，新请求无法建立，最终引发服务雪崩。
• 调试难度升级：没有超时限制，慢请求或异常请求无法被自动终止，排查性能瓶颈或服务故障时，很难快速定位问题根源。
• 组件配置冲突：ELB本身存在默认60秒的空闲超时，即使App Mesh设为0，若ELB的空闲超时触发，连接仍会被中断，需要同步调整多组件配置，增加维护复杂度。

3. 更合理的替代方案 #

针对大文件下载场景，推荐以下几种更稳妥的处理方式：

• 按请求类型配置差异化超时：在App Mesh中通过路由规则，为文件下载请求单独设置更长的超时时间，常规请求保持合理的短超时（如30秒）。比如根据content-disposition响应头、特定API路径来匹配下载请求，设置适配业务最大下载时长的超时（如3600秒）。
• 启用分块传输编码：让后端服务返回Transfer-Encoding: chunked响应头，替代固定的content-length。此时Envoy会将响应视为流式传输，只要每个数据块之间的间隔不超过空闲超时，就不会触发整体请求超时。同时要确保后端服务和Envoy都启用了分块传输支持。
• 调整空闲超时而非请求超时：请求超时是整个请求从开始到完成的总时长，而空闲超时是连接无数据传输的时长。对于大文件下载，只要数据持续传输，空闲超时就不会触发。可以将App Mesh的空闲超时设为合理值（如60秒），同时确保后端服务持续发送数据块，避免连接空闲。
• 同步调整ELB超时：如果使用Application Load Balancer，默认空闲超时为60秒，需将其调整为不小于App Mesh的超时设置，避免ELB提前中断连接。

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