Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Preguntas frecuentes
¿Cómo se configura el cliente HTTP de mi SDK? ¿Existen directrices o prácticas recomendadas?
No podemos proporcionar instrucciones a los clientes sobre cómo configurar su flujo de trabajo HTTP de una forma que resulte más eficaz para su carga de trabajo concreta. La respuesta a esto es el producto de una ecuación multivariante, con factores de entrada que incluyen, entre otras cosas, lo siguiente:
-
la huella de red de la aplicación (TPS, rendimiento, etc.)
-
los servicios que se utilizan
-
las características de computación de la implementación
-
la naturaleza geográfica de la implementación
-
el comportamiento deseado de la aplicación o las necesidades de esta (acuerdos de nivel de servicio [SLA], tiempos, etc.)
¿Cómo se configuran los tiempos de espera de las operaciones?
Al igual que en la pregunta anterior, depende. Entre los elementos que deben tenerse en cuenta a este respecto se incluyen los siguientes:
-
Todos los factores anteriores relacionados con la configuración del cliente HTTP
-
Las restricciones de tiempo o SLA de la propia aplicación (por ejemplo, si usted mismo envía el tráfico a otros consumidores)
La respuesta a esta pregunta casi NUNCA debe basarse en una observación empírica pura de un comportamiento previo (por ejemplo: “He realizado mil llamadas a esta operación en cinco segundos como máximo, de modo que tendré esto en cuenta para establecer el tiempo de espera con un factor de seguridad del doble, es decir, diez segundos”). Las condiciones del entorno pueden cambiar, los servicios pueden degradarse temporalmente y estos tipos de suposiciones pueden dejar de ser válidas en cualquier momento.
Las solicitudes que realiza el SDK agotan el tiempo de espera o tardan demasiado, ¿cómo lo soluciono?
No podemos ayudar con las llamadas a operaciones que se prolongan o cuyo tiempo de espera se ha agotado debido a un tiempo de transmisión prolongado. En el SDK, el “tiempo de transmisión” se define de cualquiera de las siguientes formas:
-
Tiempo dedicado al método
HTTPClient.Do()del cliente del SDK -
Tiempo dedicado a las funciones
Read()en un cuerpo de respuesta HTTP que se ha reenviado al intermediario (por ejemplo,GetObject)
Si tiene problemas debido a la latencia o los tiempos de espera de las operaciones, lo primero que debe hacer es obtener la telemetría del ciclo de vida de la operación del SDK para determinar el desglose temporal entre el tiempo de transmisión y la sobrecarga asociada a la operación. Consulte la sección de la guía Tiempos de las operaciones del SDK, que contiene un fragmento de código reutilizable que puede realizar esta tarea.
¿Cómo puedo solucionar un error read: connection reset?
El SDK reintenta cualquier error que coincida con el patrón connection reset de forma predeterminada. Esto cubrirá la gestión de errores en la mayoría de las operaciones, en las que la respuesta HTTP de la operación se consume por completo y se deserializa en su tipo de resultado modelado.
Sin embargo, este error puede seguir produciéndose en un contexto externo al bucle de reintentos: determinadas operaciones del servicio reenvían directamente el cuerpo de respuesta HTTP de la API al intermediario para que se consuma de forma directa desde la red a través de io.ReadCloser (por ejemplo, carga útil de objeto de GetObject). Este error puede producirse al realizar una operación Read en el cuerpo de respuesta.
El error indica que el host, el servicio o cualquier intermediario (por ejemplo, puertas de enlace de NAT, proxies, equilibradores de carga) cerró la conexión mientras se intentaba leer la respuesta.
Esto se puede producir por varios motivos:
-
No ha consumido el cuerpo de la respuesta durante algún tiempo tras la recepción de la respuesta en sí (después de la llamada a la operación de servicio). Recomendamos que consuma el cuerpo de respuesta HTTP lo antes posible para estos tipos de operaciones.
-
No ha cerrado un cuerpo de respuesta recibido anteriormente. Esto puede hacer que se restablezca la conexión en determinadas plataformas. DEBE cerrar cualquier instancia de
io.ReadCloserproporcionada en la respuesta de una operación, independientemente de si consume su contenido.
Aparte de esto, pruebe a ejecutar tcpdump para una conexión afectada en la periferia de su red (por ejemplo, más allá de cualquier proxy bajo su control). Si considera que el punto de conexión de AWS parece enviar una operación RST de TCP, debe utilizar la consola de soporte de AWS para abrir un caso contra el servicio infractor. Prepárese para proporcionar los identificadores de solicitud y las marcas de tiempo específicas del momento en que se produjo el problema.
¿Por qué recibo errores de “firma no válida” al usar un proxy HTTP con el SDK?
El algoritmo de firma para los servicios de AWS (generalmente sigv4) está vinculado a los encabezados de la solicitud serializada, más específicamente a la mayoría de los encabezados con el prefijo X-. Los proxies tienden a modificar la solicitud saliente añadiendo información de reenvío adicional (a menudo con un encabezado X-Forwarded-For), lo que invalida la eficacia de la firma calculada por el SDK.
Si utiliza un proxy HTTP y experimenta errores de firma, debe tratar de capturar la solicitud tal y como aparece al salir del proxy y determinar si es diferente.
