本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
常见问题
如何配置我的 SDK 的 HTTP 客户端？ 是否有任何准则或最佳实践？
我们无法指导客户如何以最有效满足其特定工作负载需求的方式配置其 HTTP 工作流程。这个问题的答案是多元方程的计算结果，其输入因子包括但不限于：
-
应用程序的网络占用空间（TPS、吞吐量等）
-
正在使用的服务
-
部署的计算特征
-
部署的地理特性
-
所需的应用程序行为或应用程序本身的需求（SLAs、时间等）
我应该如何配置操作超时？
就像前一个问题一样，视情况而定。这里要考虑的要素包括：
-
以上所有与 HTTP 客户端配置相关的因素
-
您自己的应用程序计时或 SLA 约束（例如，如果您自己向其他使用者提供流量）
这个问题的答案几乎不应该基于对上游行为的纯粹实证观察 - 例如“我对这项操作进行了 1000 次调用，最多花了 5 秒，所以我将以此为基础设置超时，安全系数为 2 倍，即 10 秒”。环境条件可能会发生变化，服务性能可能会暂时下降，这些类型的假设可能会在没有警告的情况下出错。
SDK 发出的请求超时或耗时太长，我该如何解决这个问题？
由于在线路上花费的时间较长，我们无法协助处理长时间或超时的操作调用。SDK 中的“线路时间”定义为以下任何一项：
-
在 SDK 客户端的
HTTPClient.Do()方法上花费的时间 -
在已转发给调用方（例如
GetObject）的 HTTP 响应正文上，执行Read()操作所消耗的时间
如果您因操作延迟或超时而遇到问题，首先应采取的行动是获取 SDK 操作生命周期的遥测数据，以确定在线路上花费的时间与操作的周围开销之间的时间细分。请参阅关于 SDK 操作计时的指南，其中包含可以实现此功能的可重复使用的代码段。
如何修复 read: connection reset 错误？
默认情况下，SDK 会重试任何与 connection reset 模式匹配的错误。这将涵盖大多数操作的错误处理，在这些操作中，操作的 HTTP 响应被完全消耗并反序列化为其建模结果类型。
但是，此错误仍可能出现在重试循环之外的上下文中：某些服务操作直接将 API 的 HTTP 响应正文转发给调用方，以便直接通过 io.ReadCloser（例如 GetObject 的对象有效载荷）从线路上使用。在响应正文上执行 Read 时，可能会遇到此错误。
此错误表明，您的主机、服务或任何中间方（例如 NAT 网关、代理、负载均衡器）在尝试读取响应时关闭了连接。
出现此错误有以下几种原因：
-
在收到响应本身之后（在调用服务操作之后）的一段时间内，您并未使用响应正文。对于这些类型的操作，建议您尽快使用 HTTP 响应正文。
-
您没有关闭之前收到的响应正文。这可能会导致某些平台上的连接重置。无论您是否使用操作响应中的内容，都必须关闭操作响应中提供的任何
io.ReadCloser实例。
除此之外，可以尝试在网络边缘（例如，在您控制的任何代理之后）对受影响的连接运行 tcpdump。如果您看到 AWS 端点似乎在发送 TCP RST，则应使用 AWS 支持控制台对违规服务提起诉讼。请准备好提供问题发生的请求 IDs和具体时间戳。
在 SDK 中使用 HTTP 代理时，为什么会出现“签名无效”错误？
AWS 服务的签名算法（通常是 sigv4）与序列化请求的标头相关联，更具体地说，大多数标头都带有前缀。X-代理很容易通过添加额外的转发信息（通常通过 X-Forwarded-For 标头）来修改传出的请求，这实际上会破坏 SDK 计算出的签名。
如果您使用的是 HTTP 代理并遇到签名错误，则应努力捕获似乎从代理传出的请求，并确定请求是否有所不同。
