As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Perguntas frequentes

Como configurar o cliente HTTP do SDK? Há alguma diretriz ou prática recomendada?

Não podemos fornecer orientação aos clientes sobre como configurar o fluxo de trabalho HTTP da maneira mais eficaz para sua workload específica. A resposta para isso é o produto de uma equação multivariada, com fatores de entrada incluindo, dentre outros:

Como configurar os tempos limite de operação?

Assim como na pergunta anterior, isso depende. Os elementos a considerar aqui incluem o seguinte:

A resposta a essa pergunta quase NUNCA deve ser baseada na observação empírica pura do comportamento inicial: por exemplo, “Fiz mil chamadas para essa operação, demorou no máximo cinco segundos, então vou definir o tempo limite com base nisso com um fator de segurança de duas vezes, para 10 segundos”. As condições do ambiente podem mudar, os serviços podem sofrer degradações temporárias, e esse tipo de suposição pode se tornar incorreta sem aviso.

As solicitações feitas pelo SDK estão atingindo o tempo limite ou demorando demais. Como corrigir isso?

Não podemos ajudar com chamadas de operação estendidas ou que atingiram o tempo limite devido ao tempo prolongado gasto na conexão de rede. O “tempo de conexão de rede” no SDK é definido como qualquer um dos seguintes:

Se você está enfrentando problemas devido à latência da operação ou ao tempo limite, sua primeira ação deve ser obter a telemetria do ciclo de vida da operação do SDK para determinar a divisão do tempo entre o que foi gasto na conexão de rede e a sobrecarga da operação ao redor. Consulte o guia sobre como medir o tempo de operações do SDK, que contém um trecho de código reutilizável que permite fazer isso.

Como corrigir um erro read: connection reset?

Por padrão, o SDK faz novas tentativas de qualquer erro que corresponda ao padrão connection reset. Isso abrange o gerenciamento de erros na maioria das operações, em que a resposta HTTP da operação é totalmente consumida e desserializada no tipo de resultado modelado.

No entanto, esse erro ainda pode ocorrer em um contexto fora do loop de novas tentativas: certas operações de serviço encaminham diretamente o corpo da resposta HTTP da API para o chamador, para ser consumido diretamente da conexão de rede via io.ReadCloser (por exemplo, carga útil do objeto de GetObject). Você pode encontrar esse erro ao executar um Read no corpo da resposta.

Esse erro indica que o host, o serviço ou qualquer intermediário (por exemplo, gateways NAT, proxies, balanceadores de carga) fechou a conexão ao tentar ler a resposta.

Esse erro pode ocorrer por vários motivos.

Além disso, tente executar um tcpdump para uma conexão afetada na borda da rede (por exemplo, depois de qualquer proxy que você controla). Se você perceber que o endpoint AWS parece estar enviando um TCP RST, use o console de suporte da AWS para abrir um caso contra o serviço responsável. Você deve fornecer os IDs de solicitação e os carimbos de data e hora específicos de quando o problema ocorreu.

Por que recebo erros de “assinatura inválida” ao usar um proxy HTTP com o SDK?

O algoritmo de assinatura para serviços da AWS (geralmente SigV4) está vinculado aos cabeçalhos da solicitação serializada, mais especificamente à maioria dos cabeçalhos com o prefixo X-. Os proxies tendem a modificar a solicitação de saída adicionando outras informações de encaminhamento (geralmente por meio de um cabeçalho X-Forwarded-For), o que invalida a assinatura que o SDK calculou de forma efetiva.

Se você estiver usando um proxy HTTP e ocorrerem erros de assinatura, capture a solicitação conforme ela sai do proxy e determine se ela é diferente.