Häufig gestellte Fragen - AWS SDK für Go v2
Wie konfiguriere ich den HTTP-Client meines SDK? Gibt es Richtlinien oder bewährte Verfahren?Wie sollte ich Betriebs-Timeouts konfigurieren?Anfragen des SDK haben eine Zeitüberschreitung oder dauern zu lange. Wie behebe ich das?Wie behebe ich einen read: connection reset Fehler?Warum erhalte ich die Fehlermeldung „Ungültige Signatur“, wenn ich einen HTTP-Proxy mit dem SDK verwende?

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Häufig gestellte Fragen

Wie konfiguriere ich den HTTP-Client meines SDK? Gibt es Richtlinien oder bewährte Verfahren?

Wir sind nicht in der Lage, Kunden zu beraten, wie sie ihren HTTP-Workflow so konfigurieren können, dass sie für ihren speziellen Workload am effektivsten sind. Die Antwort darauf ist das Produkt einer multivariaten Gleichung, zu deren Eingabefaktoren unter anderem gehören, aber nicht darauf beschränkt sind:

  • die Netzwerkauslastung der Anwendung (TPS, Durchsatz usw.)

  • die Dienste, die genutzt werden

  • die Recheneigenschaften der Bereitstellung

  • der geografische Charakter des Einsatzes

  • das gewünschte Anwendungsverhalten oder die Anforderungen der Anwendung selbst (SLAs, Zeitpläne usw.)

Wie sollte ich Betriebs-Timeouts konfigurieren?

Ähnlich wie bei der vorherigen Frage kommt es darauf an. Zu den hier zu berücksichtigenden Elementen gehören die folgenden:

  • Alle oben genannten Faktoren betreffen die HTTP-Client-Konfiguration

  • Ihre eigenen Anwendungszeiten oder SLA-Einschränkungen (z. B. wenn Sie selbst Traffic für andere Verbraucher bereitstellen)

Die Antwort auf diese Frage sollte fast NIEMALS auf rein empirischer Beobachtung des Upstream-Verhaltens beruhen — z. B. „Ich habe 1000 Aufrufe für diesen Vorgang getätigt, er hat höchstens 5 Sekunden gedauert, also werde ich den Timeout auf dieser Grundlage mit einem Sicherheitsfaktor von 2 bis 10 Sekunden festlegen“. Die Umgebungsbedingungen können sich ändern, Dienste können sich vorübergehend verschlechtern, und solche Annahmen können sich ohne Vorwarnung als falsch erweisen.

Anfragen des SDK haben eine Zeitüberschreitung oder dauern zu lange. Wie behebe ich das?

Wir können Ihnen bei längeren Anrufen oder bei Betriebsunterbrechungen nicht weiterhelfen, da wir zu viel Zeit in der Leitung verbracht haben. „Wire Time“ ist im SDK wie folgt definiert:

  • Für die HTTPClient.Do() Methode eines SDK-Clients aufgewendete Zeit

  • Zeit, die in Read() s für einen HTTP-Antworttext verbracht wurde, der an den Aufrufer weitergeleitet wurde (z. B. GetObject

Wenn Sie aufgrund von Betriebslatenz oder Timeouts Probleme haben, sollten Sie zunächst Telemetriedaten des SDK-Betriebszyklus abrufen, um die zeitliche Trennung zwischen der auf der Leitung verbrachten Zeit und dem damit verbundenen Overhead des Vorgangs zu ermitteln. Weitere Informationen finden Sie im Leitfaden zum Timing von SDK-Vorgängen, der einen wiederverwendbaren Codeausschnitt enthält, mit dem Sie dies erreichen können.

Wie behebe ich einen read: connection reset Fehler?

Das SDK wiederholt standardmäßig alle Fehler, die dem connection reset Muster entsprechen. Dies deckt die Fehlerbehandlung für die meisten Operationen ab, bei denen die HTTP-Antwort der Operation vollständig verarbeitet und in ihren modellierten Ergebnistyp deserialisiert wird.

Dieser Fehler kann jedoch immer noch in einem Kontext außerhalb der Wiederholungsschleife auftreten: Bestimmte Dienstoperationen leiten den HTTP-Antworttext der API direkt an den Aufrufer weiter, sodass er direkt über die Leitung abgerufen wird io.ReadCloser (z. B. GetObject die Objektnutzlast). Dieser Fehler kann auftreten, wenn Sie eine Antwort Read auf den Antworttext ausführen.

Dieser Fehler weist darauf hin, dass Ihr Host, der Dienst oder eine zwischengeschaltete Partei (z. B. NAT-Gateways, Proxys, Load Balancer) die Verbindung geschlossen hat, während Sie versucht haben, die Antwort zu lesen.

Dies kann aus verschiedenen Gründen auftreten:

  • Sie haben den Antworttext einige Zeit lang nicht verwendet, nachdem die Antwort selbst empfangen wurde (nachdem der Dienstvorgang aufgerufen wurde). Wir empfehlen Ihnen, den HTTP-Antworttext für diese Art von Vorgängen so schnell wie möglich zu verwenden.

  • Sie haben einen zuvor empfangenen Antworttext nicht geschlossen. Dies kann auf bestimmten Plattformen zum Zurücksetzen der Verbindung führen. Sie MÜSSEN alle io.ReadCloser Instanzen schließen, die in der Antwort einer Operation angegeben werden, unabhängig davon, ob Sie deren Inhalt verwenden.

Versuchen Sie außerdem, eine tcpdump für eine betroffene Verbindung am Rand Ihres Netzwerks auszuführen (z. B. hinter allen Proxys, die Sie kontrollieren). Wenn Sie feststellen, dass der AWS Endpunkt anscheinend TCP-RST sendet, sollten Sie die AWS Support-Konsole verwenden, um ein Verfahren gegen den betreffenden Dienst einzuleiten. Seien Sie bereit, eine Anfrage IDs und genaue Zeitstempel anzugeben, wann das Problem aufgetreten ist.

Warum erhalte ich die Fehlermeldung „Ungültige Signatur“, wenn ich einen HTTP-Proxy mit dem SDK verwende?

Der Signaturalgorithmus für AWS Dienste (im Allgemeinen Sigv4) ist an die Header der serialisierten Anfrage gebunden, genauer gesagt an die meisten Header mit dem Präfix. X- Proxys neigen dazu, die ausgehende Anfrage zu modifizieren, indem sie zusätzliche Weiterleitungsinformationen hinzufügen (oft über einen X-Forwarded-For Header), wodurch die vom SDK berechnete Signatur effektiv gebrochen wird.

Wenn Sie einen HTTP-Proxy verwenden und Signaturfehler auftreten, sollten Sie versuchen, die Anfrage so zu erfassen, wie sie vom Proxy ausgeht, und feststellen, ob es sich um eine andere Anfrage handelt.