Realmente solo necesito ayuda para entender la siguiente imagen, pero daré los antecedentes para contextualizarla.
Tenemos una aplicación que está configurada para usar un proxy en el puerto 8080 y requiere acceso a Internet. En momentos aleatorios durante el día, la aplicación no logra conectarse y simplemente muere. Estamos tratando de descubrir la causa. Hemos descartado las reglas de URL de proxy y FW (siempre accede a la misma URL cuando funciona y falla de todos modos). Creo que el problema está relacionado con la red por un problema de rendimiento en el propio proxy. Para llegar al fondo del asunto, he estado tomando capturas de red cuando sucede.
Si observa la siguiente imagen, es un fragmento sin los detalles de IP. La primera línea con la fuente "42" es la máquina cliente que realiza una solicitud TLS a través del proxy (IP 35) en el puerto 8080. NOTA: Generalmente funciona y solicita la misma URL/IP, pero esta es una de las veces que falló. La ventana inferior son los detalles de la primera línea verde.
La parte resaltada "Siguiente número de secuencia" coincide con el ACK del último paquete devuelto de 35 (de la segunda a la última línea). Básicamente, se trata de responder al cliente indicando que ha recibido todos los datos que se le enviaron (esto significa que el dispositivo está activo ya que reconoce la recepción de los datos (lo que significa que no hay problemas de FW o de red)). Tenga en cuenta que no envía ningún dato. Inmediatamente después de esto, el cliente emite un TCP RST. Aquí está mi interpretación, pero me gustaría que alguien la verificara, ya que mis habilidades TCP están un poco oxidadas.
El cliente envía algún tipo de solicitud al proxy, pero por alguna razón el proxy no responde (en la capa de aplicación). Dado que el proxy SÍ responde con TCP ACK, esto significa que en la capa de red todo está bien. Esto implicaría que cuando los datos pasan por la pila de red al propio proxy, es el proxy el que interrumpe la conexión. Por qué sucede eso, aún no lo sé, pero estoy buscando una aclaración para poder hablar con el equipo de proxy y decirles que necesitan investigar esto (no creen que sea el proxy).
Otra evidencia que respalda mi caso es que las 4 primeras líneas que ves en la imagen antes del RST se repiten muchas veces. Nuevamente, esto implica que el cliente vuelve a enviar cualquier solicitud que tenga pero nunca obtiene una respuesta; y finalmente se da por vencido y emite un reinicio.
Aparentemente hay un equilibrador de carga que se encuentra frente al proxy, y el proxy en realidad son varias máquinas. Tengo la sensación de que hay un problema con uno de ellos en el backend y el LB no elimina el nodo del grupo y, por lo tanto, potencialmente envía los datos a un agujero negro.
Estoy buscando una segunda opinión. ¿Este resumen que tengo arriba parece preciso según la captura?
Respuesta1
Inmediatamente después de esto, el cliente emite un TCP RST.
No inmediatamente. El cliente envía el RST 30 segundos después de que el servidor envió el último ACK.
... las 4 primeras líneas que ves en la imagen antes del RST se repiten muchas veces
Estas no son las mismas líneas. Tienen un valor diferente para ACK.
Mi interpretación aquí es que el cliente está enviando una solicitud con una carga útil mayor (de ahí los múltiples ACK del servidor para reconocer esto) y luego espera que el proxy envíe la respuesta. Después de 30 segundos sin respuesta el cliente se da por vencido y cierra la conexión con RST.
No está claro por qué el proxy no envía una respuesta. Podría ser un problema del proxy. Pero también podría ser un problema del servidor ascendente y el servidor simplemente propaga el problema al cliente.
Sin embargo, tenga en cuenta que la interpretación podría ser incorrecta. No se proporciona mucho contexto ni captura de paquetes, por lo que es más una suposición fundamentada.