Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Domande frequenti
Come posso configurare il client HTTP del mio SDK? Esistono linee guida o best practice?
Non siamo in grado di fornire indicazioni ai clienti su come configurare il flusso di lavoro HTTP nel modo più efficace per il loro particolare carico di lavoro. La risposta a questa domanda è il prodotto di un'equazione multivariata, con fattori di input tra cui, a titolo esemplificativo ma non esaustivo:
-
l'impronta di rete dell'applicazione (TPS, throughput, ecc.)
-
i servizi utilizzati
-
le caratteristiche di calcolo della distribuzione
-
la natura geografica della distribuzione
-
il comportamento o le esigenze dell'applicazione stessa desiderati (SLAstempistiche, ecc.)
Come devo configurare i timeout operativi?
Proprio come la domanda precedente, dipende. Gli elementi da considerare qui includono quanto segue:
-
Tutti i fattori sopra indicati relativi alla configurazione del client HTTP
-
vincoli relativi alla tempistica delle applicazioni o agli SLA (ad esempio se sei tu stesso a fornire traffico ad altri consumatori)
La risposta a questa domanda non dovrebbe quasi MAI basarsi sulla pura osservazione empirica del comportamento a monte, ad esempio «Ho effettuato 1000 chiamate per questa operazione, ci sono voluti al massimo 5 secondi, quindi imposterò il timeout in base a quello con un fattore di sicurezza compreso tra 2 e 10 secondi». Le condizioni ambientali possono cambiare, i servizi possono peggiorare temporaneamente e questi tipi di ipotesi possono diventare errate senza preavviso.
Le richieste effettuate dall'SDK scadono o impiegano troppo tempo. Come posso risolvere il problema?
Non siamo in grado di fornire assistenza in caso di chiamate operative prolungate o scadute a causa del prolungato tempo trascorso in rete. Il «tempo di trasmissione» nell'SDK è definito come uno dei seguenti:
-
Tempo impiegato nel metodo di un client SDK
HTTPClient.Do() -
Tempo trascorso in
Read()s su un corpo di risposta HTTP che è stato inoltrato al chiamante (ad es.)GetObject
In caso di problemi dovuti alla latenza o ai timeout delle operazioni, la prima cosa da fare è ottenere la telemetria del ciclo di vita delle operazioni dell'SDK per determinare la ripartizione temporale tra il tempo trascorso sul cavo e il sovraccarico circostante dell'operazione. Consulta la guida sulla temporizzazione delle operazioni dell'SDK, che contiene un frammento di codice riutilizzabile per raggiungere questo obiettivo.
Come posso correggere un errore? read: connection reset
Per impostazione predefinita, l'SDK riprova qualsiasi errore corrispondente al connection reset pattern. Ciò riguarderà la gestione degli errori per la maggior parte delle operazioni, in cui la risposta HTTP dell'operazione viene completamente utilizzata e deserializzata nel tipo di risultato modellato.
Tuttavia, questo errore può ancora verificarsi in un contesto al di fuori del ciclo di ripetizione: alcune operazioni di servizio inoltrano direttamente il corpo della risposta HTTP dell'API al chiamante per essere utilizzato direttamente dal cavo io.ReadCloser (ad esempioGetObject, il payload dell'oggetto). È possibile che si verifichi questo errore quando si esegue un comando Read sul corpo della risposta.
Questo errore indica che l'host, il servizio o qualsiasi intermediario (ad esempio gateway NAT, proxy, sistemi di bilanciamento del carico) ha chiuso la connessione durante il tentativo di leggere la risposta.
Questo può verificarsi per diversi motivi:
-
Il corpo della risposta non è stato utilizzato per qualche tempo dopo la ricezione della risposta stessa (dopo la chiamata dell'operazione di servizio). Ti consigliamo di utilizzare il corpo della risposta HTTP il prima possibile per questi tipi di operazioni.
-
Non hai chiuso un corpo di risposta ricevuto in precedenza. Ciò può causare il ripristino della connessione su determinate piattaforme. È NECESSARIO chiudere tutte
io.ReadCloserle istanze fornite nella risposta di un'operazione, indipendentemente dal fatto che se ne utilizzi o meno il contenuto.
Oltre a ciò, prova a eseguire una tcpdump connessione interessata ai margini della rete (ad esempio dopo tutti i proxy che controlli). Se notate che l' AWS endpoint sembra inviare un RST TCP, dovreste usare la console di AWS supporto per avviare una causa contro il servizio incriminato. Preparati a fornire richieste IDs e orari specifici in cui si è verificato il problema.
Perché ricevo errori di «firma non valida» quando utilizzo un proxy HTTP con l'SDK?
L'algoritmo di firma per AWS i servizi (generalmente sigv4) è legato alle intestazioni della richiesta serializzata, in particolare alla maggior parte delle intestazioni con il prefisso. X- I proxy tendono a modificare la richiesta in uscita aggiungendo ulteriori informazioni di inoltro (spesso tramite un'intestazione), il che di fatto infrange la firma calcolata dall'SDK. X-Forwarded-For
Se utilizzi un proxy HTTP e riscontri errori di firma, dovresti cercare di acquisire la richiesta così come appare in uscita dal proxy e determinare se è diversa.
