Questions fréquentes (FAQ) - AWS SDK pour Go v2
Comment configurer le client HTTP de mon SDK ? Existe-t-il des directives ou des meilleures pratiques ?Comment configurer les délais d'expiration des opérations ?Les demandes effectuées par le SDK arrivent à expiration ou prennent trop de temps, comment puis-je résoudre ce problème ?Comment corriger une read: connection reset erreur ?Pourquoi est-ce que je reçois des erreurs de « signature non valide » lorsque j'utilise un proxy HTTP avec le SDK ?

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Questions fréquentes (FAQ)

Comment configurer le client HTTP de mon SDK ? Existe-t-il des directives ou des meilleures pratiques ?

Nous ne sommes pas en mesure de fournir des conseils aux clients sur la manière de configurer leur flux de travail HTTP de la manière la plus efficace pour leur charge de travail particulière. La réponse à cette question est le produit d'une équation multivariée, avec des facteurs d'entrée tels que, mais sans s'y limiter, les suivants :

  • l'empreinte réseau de l'application (TPS, débit, etc.)

  • les services utilisés

  • les caractéristiques informatiques du déploiement

  • la nature géographique du déploiement

  • le comportement souhaité de l'application ou les besoins de l'application elle-même (horairesSLAs, etc.)

Comment configurer les délais d'expiration des opérations ?

Tout comme pour la question précédente, cela dépend. Les éléments à prendre en compte ici sont les suivants :

  • Tous les facteurs ci-dessus concernant la configuration du client HTTP

  • Vos propres contraintes en matière de calendrier de candidature ou de SLA (par exemple, si vous distribuez vous-même du trafic à d'autres consommateurs)

La réponse à cette question ne devrait presque JAMAIS être basée sur une simple observation empirique du comportement en amont. Par exemple, « J'ai effectué 1 000 appels pour cette opération, cela a pris au maximum 5 secondes. Je vais donc régler le délai d'attente en fonction de cela avec un facteur de sécurité de 2 à 10 secondes ». Les conditions environnementales peuvent changer, les services peuvent se dégrader temporairement, et ce type d'hypothèses peut devenir erroné sans avertissement.

Les demandes effectuées par le SDK arrivent à expiration ou prennent trop de temps, comment puis-je résoudre ce problème ?

Nous ne sommes pas en mesure de répondre aux appels opérationnels prolongés ou expirés en raison du temps passé sur le fil. Dans le SDK, le « temps de câblage » est défini comme suit :

  • Temps passé dans la méthode d'un client HTTPClient.Do() SDK

  • Temps passé en Read() s sur le corps d'une réponse HTTP qui a été transféré à l'appelant (par exempleGetObject)

Si vous rencontrez des problèmes liés à la latence des opérations ou à des délais impartis, la première chose à faire est d'obtenir des données télémétriques du cycle de vie des opérations du SDK afin de déterminer la répartition temporelle entre le temps passé sur le câble et le surcoût associé à l'opération. Consultez le guide sur le chronométrage des opérations du SDK, qui contient un extrait de code réutilisable permettant d'y parvenir.

Comment corriger une read: connection reset erreur ?

Le SDK essaie à nouveau de corriger les erreurs correspondant au connection reset modèle par défaut. Cela couvrira la gestion des erreurs pour la plupart des opérations, où la réponse HTTP de l'opération est entièrement consommée et désérialisée dans son type de résultat modélisé.

Cependant, cette erreur peut toujours se produire dans un contexte extérieur à la boucle de réessais : certaines opérations de service transmettent directement le corps de la réponse HTTP de l'API à l'appelant pour qu'il soit directement consommé par le fil io.ReadCloser (par exemple, la charge utile GetObject de l'objet). Vous pouvez rencontrer cette erreur lorsque vous effectuez un dans Read le corps de la réponse.

Cette erreur indique que votre hôte, le service ou tout intermédiaire (par exemple, les passerelles NAT, les proxys, les équilibreurs de charge) ont fermé la connexion alors qu'ils tentaient de lire la réponse.

Cela peut se produire pour plusieurs raisons :

  • Vous n'avez pas utilisé le corps de la réponse pendant un certain temps après la réception de la réponse elle-même (après l'appel de l'opération de service). Nous vous recommandons de consommer le corps de la réponse HTTP dès que possible pour ce type d'opérations.

  • Vous n'avez pas fermé un corps de réponse reçu précédemment. Cela peut entraîner des réinitialisations de connexion sur certaines plateformes. Vous DEVEZ fermer toutes io.ReadCloser les instances fournies dans la réponse d'une opération, que vous consommiez ou non son contenu.

En outre, essayez tcpdump d'exécuter une connexion affectée à la périphérie de votre réseau (par exemple, après tout proxy que vous contrôlez). Si vous constatez que le AWS point de terminaison semble envoyer un TCP RST, vous devez utiliser la console d' AWS assistance pour ouvrir un dossier contre le service incriminé. Soyez prêt à fournir une demande IDs et des horodatages précis indiquant le moment où le problème s'est produit.

Pourquoi est-ce que je reçois des erreurs de « signature non valide » lorsque j'utilise un proxy HTTP avec le SDK ?

L'algorithme de signature des AWS services (généralement sigv4) est lié aux en-têtes de la demande sérialisée, plus précisément à la plupart des en-têtes préfixés par. X- Les proxys ont tendance à modifier la demande sortante en ajoutant des informations de transfert supplémentaires (souvent via un X-Forwarded-For en-tête), ce qui brise effectivement la signature calculée par le SDK.

Si vous utilisez un proxy HTTP et que vous rencontrez des erreurs de signature, vous devez vous efforcer de capturer la demande telle qu'elle semble sortante du proxy et de déterminer si elle est différente.