本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
常見問答集
如何設定 SDK 的 HTTP 用戶端？ 是否有任何指導方針或最佳實務？
我們無法為客戶提供有關如何以對其特定工作負載最有效的方式設定其 HTTP 工作流程的指導。答案是多變量方程式的乘積，其輸入因素包括但不限於：
-
應用程式的網路足跡 (TPS、輸送量等）
-
正在使用的服務
-
部署的運算特性
-
部署的地理本質
-
應用程式本身所需的應用程式行為或需求 (SLAs、計時等）
如何設定操作逾時？
就像上一個問題一樣，它取決於。此處要考慮的元素包括下列項目：
-
上述有關 HTTP 用戶端組態的所有因素
-
您自己的應用程式時間或 SLA 限制條件 （例如，如果您將流量提供給其他消費者）
此問題的答案幾乎絕不應基於對上游行為的純粹經驗觀察 - 例如「我對此操作進行了 1000 次呼叫，最多需要 5 秒，因此我將根據安全因素 2 倍到 10 秒的逾時設定逾時」。環境條件可能會變更、服務可能會暫時降級，而且這些類型的假設可能會在沒有警告的情況下變成錯誤。
開發套件提出的請求逾時或耗時太久，如何修正此問題？
由於花費在線路上的時間較長，我們無法協助進行延長或逾時的操作呼叫。開發套件中的「換線時間」定義為下列任何一項：
-
在 SDK 用戶端
HTTPClient.Do()方法中花費的時間 -
在已轉送給發起人的 HTTP 回應內文
Read()上花費的時間 （例如GetObject)
如果您因為操作延遲或逾時而遇到問題，您的第一個動作應該是取得 SDK 操作生命週期的遙測，以判斷花費在線路上的時間和操作的周圍額外負荷之間的時間明細。請參閱 SDK 操作的計時指南，其中包含可達成此目標的可重複使用程式碼片段。
如何修正read: connection reset錯誤？
依預設，軟體開發套件會重試符合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 代理並遇到簽章錯誤，您應該在請求從代理傳出時努力擷取請求，並判斷其是否不同。
