La comunicación por socket se utiliza generalmente para
Caso de estudio:
El personal de soporte de aplicaciones de un determinado sistema informó que el puerto 14029 del servicio de transferencia de archivos era anormal y el servicio había sido bloqueado. Iniciamos sesión en el sistema para verificar y descubrimos que, excepto por el lento procesamiento de transacciones del servicio de transferencia de archivos, otros tipos de transacciones no se vieron afectados. Esto muestra que el servidor tiene múltiples puertos de servicios externos y solo un puerto es anormal. Después de comunicarse con los desarrolladores de la aplicación, los comentarios fueron que no se implementaron cambios en la aplicación. Al mismo tiempo, los desarrolladores de aplicaciones informaron que se accedía a estos servicios desde la red pública. Iniciamos sesión en el dispositivo F5. Después de reducir gradualmente el servicio de acceso a la red pública, la cantidad de solicitudes de transacciones simultáneas disminuyó y el bloqueo del puerto del servicio de transferencia de archivos se alivió gradualmente. Sin embargo, después de que restauramos gradualmente el servicio de red pública desde el dispositivo F5. , el problema volvió a ocurrir.
Al analizar los datos recopilados cuando ocurrió la excepción, había aproximadamente 3000 conexiones en el puerto de servicio 14029, la mayoría de las cuales estaban en los estados CLOSE_WAIT y LAST_ACK. Tantos CLOSE_WAIT y LAST_ACK indican que la etapa de comunicación debe ser anormal. Al ver esto, todos sospechan que el problema ocurre en el nivel de red. No lo responderé aquí primero. Pensemos en ello basándonos en CLOSE_WAIT y LAST_ACK en TCP. Principio presentado anteriormente Bueno, el problema actual solo refleja una gran cantidad de CLOSE_WAIT y LAST_ACK, y la fase de establecimiento de conexión no aparece. ACK, no hay excepción durante la fase de establecimiento de la conexión, ¿qué significa esto? Continúe viendo los mensajes de comunicación de la red. Los mensajes de red durante el período de tiempo anormal son los siguientes:
De los mensajes de red, la conexión es generalmente normal antes del lanzamiento. ¿Por qué se dice que es generalmente normal? El CLIENTE y el SERVIDOR van y vienen. no hay anormalidades como retransmisiones, pero la interacción a menudo excede los 20 segundos a la vez, lo que solo se puede decir que es más o menos normal. Una vez completada una transacción, la conexión comienza a desconectarse y ocurre un problema. El cliente envía un paquete FIN y el servidor responde inmediatamente con ACK. Luego, después de esperar más de 20 segundos, envía datos con una longitud de 7. , luego responde con un paquete FIN y luego la red retransmite el paquete FIN.
En cuanto a la retransmisión de la red, a primera vista pensé que se trataba de una pérdida de paquetes de comunicación de la red, pero después de una cuidadosa consideración, no hubo pérdida de paquetes en otros momentos, por qué el paquete solo se perdió durante la fase de liberación de la conexión. no tenía sentido. En este sentido, nos comunicamos con expertos en tecnología de redes y la respuesta que obtuvimos es: durante la etapa de comunicación, el cliente tiene una gran cantidad de solicitudes de cierre de conexión con tiempo de espera agotado, es decir, el cliente envía paquetes FIN y el servidor- El proceso de servicio secundario se agota y no responde a tiempo para cerrar la conexión. La solicitud excede los 10 segundos y activa el mecanismo de protección de seguridad del firewall. El firewall descarta el paquete de respuesta de cierre de conexión (FIN), lo que genera una gran cantidad de FIN. paquetes. El firewall descarta el paquete FIN, por lo que se retransmitirá una gran cantidad de paquetes FIN. La respuesta es que no hay ningún problema con la red, es la aplicación la que caduca.
Se ha eliminado el problema de pérdida de paquetes de red, por lo que el problema puede estar en la aplicación, pero ¿dónde está exactamente el problema en la aplicación? Hemos revisado todo el proceso de análisis y encontramos dos dudas relacionadas con la aplicación. En primer lugar, el retraso de interacción entre el cliente y el servidor en el mensaje de comunicación es muy grande, produciéndose a menudo una diferencia de tiempo de más de 20 segundos; Hay una gran cantidad de clientes. Emite una solicitud de desconexión del enlace. Ante nuestras dudas, nos comunicamos con el desarrollador de la aplicación para comprender mejor todo el proceso de la transacción. Pronto la segunda pregunta quedó clara. En circunstancias normales, la transacción la cierra el Banco Agrícola de China, no el cliente de la red pública, a menos que sea la transacción. tiempo de espera, a juzgar por el fenómeno, debe ser que se ha producido una gran cantidad de tiempos de espera de transacciones de clientes. Al mismo tiempo, a partir del análisis del proceso de transacción proporcionado por el desarrollador de la aplicación, cada transacción genera registros 8 veces, lo que significa que una transacción registra 8 registros y opera el archivo de registro 8 veces. Dado que la aplicación registra los registros paso a paso, el registro definitivamente puede reflejar la diferencia de tiempo entre cada paso de la transacción, lo que significa que el estado del tiempo de espera de la transacción del registro de la aplicación se puede ver directamente. Abra el archivo de registro y descubra que es casi difícil ver registros completos y secuenciales en el archivo de registro. Esto se debe a que varios procesos en el grupo de procesos de la aplicación escriben registros en paralelo. ¿Cómo podríamos simplemente renunciar a una pista tan importante? Con este fin, escribimos especialmente un script basado en las marcas de tiempo y los números de proceso en los registros, que fue responsable de recorrer y ordenar los registros de la aplicación de la semana pasada. Después de unas horas, aparecieron resultados interesantes. El registro de tiempo de cada transacción es muy detallado. La mayoría de las veces, cada transacción se completa en un segundo. Durante el período pico de transacciones, el tiempo de transacción comienza a retrasarse. El retraso es de 2 a 3 segundos y el retraso es largo. Decenas de segundos o incluso más Cientos de segundos, se puede inferir del registro que este problema siempre ha existido, pero la gravedad es diferente.
Después de analizar este punto, todos deberían saber que hay un problema con la aplicación, pero ¿cuál es exactamente el problema con la aplicación? A medida que activamos el seguimiento de truss para el proceso de solicitud en la dirección pico del negocio, un registro muy detallado del proceso de transacción y las llamadas subyacentes en el truss es el siguiente:
La transacción *** tiene 8 escribe en el registro. Un proceso de operación de archivo de registro (kopen-kwrite-close) es un ejemplo. Tarda más de 1,1 segundos. Una vez completada una transacción, básicamente lleva más de 10 segundos. Al mismo tiempo, hay muchos otros procesos relacionados con el puerto 14029 que operan simultáneamente en este registro, lo que provoca la mayoría de las operaciones en todo el archivo de registro. Como puede ver en los mensajes de Truss, el registro de apertura de transacciones aún se está sincronizando.
35782920: 48955803: 0.1007: kfork() = 18874542
18874542: kfork() (regresando como hijo...) = 0
18874542: 31785117 : 0.1086: _getpid() = 18874542
35782920: 48955803: 0.1088: semget(1674622889, 1, 0)18874542: 31785117: 0.1088: thread_setmystate(0x00000000, x2FF21920) = 300942464 = 0
18874542: 31785117: 0.1091: _thread_self() = 31785117
18874542.31785117: 0.1094: thread_setmystate(0x2FF21608, 0x2FF21910) = 0
18874542: 785117: 0.1096: thread_setmymask_fast(0x00000000, 0x00000000 , 0x00000000, 0xD051C880, 0x00000000, 0x11E5009D, 0x11E5009D, 0xF0256118) = 0x0000
0000
18874542: 31785117: 4 thread_unlock(0x2003F750) = 0
18874542 : 31785117: 8.0003: kopen("/ho22938062: 44761355: 8.0009: kopen("/home/beics/log/Fil = 83997862.75104323: 8.0018: kopen
= 0 = 8 = 91717 0888: 63 897901: 8.0034: close(9)16849568808:53805667: 8.0037: kopen("/home/beics/log/ FileSvr.20140604", O_RDWR|O_SYNC|O_APPEND
= 0 = 9 = 932965182:51970655: 8.0039: kopen( "/home/beics/log/FileSvr.20140604", O_RDWR|O_SYNC |O_APPEND) 35521118: 45220353: 8.0065: kopen("/home/b
eics/log/FileSvr.20140604", O_RDWR| O_SYNC|O_APPEND) = 8 = 98454202: 21954581.8.0049: kopen("/home/beics/log/FileSvr.20140604", O_RDWR|O_SYNC|O_APPEND) = 91
5991212: 14877101: 8.0080 : _erec v (7, 0x2FF21630, 7, 256, 0x00000000) = 76488658: 81134209: kwrite(8, 0x2FF208C4, 56) =
56
18874542: 31785117: kwrite(8, 0x2FF20B14, 53) = 53
18874542: [ 1 6 : 2 3 : 0 4 | 2 | ] [ 1 0 .
18874542: *. Q U I T\n
En este punto del análisis, creo que todos saben lo que está sucediendo. Varios subprocesos en el truss se ejecutan en paralelo, lo que provoca retrasos e información confusa. Por lo tanto, la conclusión extraída después del análisis final es la siguiente: debido a que las transacciones son demasiado frecuentes y un archivo de registro se abre y escribe de manera sincrónica, y todas estas operaciones de archivo son operaciones en serie, las transacciones compiten entre sí para registrar registros. lo que resulta en procesamiento de transacciones El tiempo se extiende y la eficiencia del procesamiento se reduce. En cuanto a la gran cantidad de CLOSE_WAIT y LAST_ACK que se ven a nivel del sistema durante las excepciones, debería entenderse mejor. Debido a que el proceso de transacción se ralentiza, el servidor sigue enviando datos (en respuesta a la solicitud anterior) después de recibir el paquete FIN enviado. Por lo tanto, puede ver una gran cantidad de CLOSE_WAIT; y el estado LAST_ACK, que se debe al tiempo de espera de la transacción. El estado LAST_ACK se debe al tiempo de espera de la transacción, lo que activa el mecanismo de seguridad del firewall y el FIN respondido por el servidor. .
Soluciones y sugerencias:
El desarrollador de la aplicación optimizó la aplicación según nuestras sugerencias, cambió el método de apertura de archivos al modo asíncrono y mejoró el método de registro paso a paso. El método de registro de transacciones secundarias se cambia a un método de registro único, es decir, la transacción se almacena en el búfer primero y luego se registra una vez completada la transacción, lo que reduce la frecuencia de operación de archivos de registro y reduce la competencia en las operaciones de archivos. Una vez completada la optimización, el problema se resuelve por completo.
Es difícil investigar y tratar problemas anormales de comunicación de socket, y es difícil tanto para la capa del sistema como para la capa de aplicación manejar rápidamente las emergencias. Se recomienda que la arquitectura adopte el modo de clúster tanto como sea posible para lograr el equilibrio de carga de la aplicación, evitar eficazmente los riesgos de "punto único" de la aplicación y mejorar la alta disponibilidad de la aplicación.
Para un sistema de comunicación de socket de desarrollo propio, el programa de aplicación está estrechamente relacionado con la comunicación TCP y el mecanismo de manejo de excepciones depende del programa de aplicación. Se deben considerar cuidadosamente varias excepciones complejas en el entorno externo. De hecho, es algo muy difícil, como dijeron algunos desarrolladores experimentados en la industria, el programa de comunicación de socket estándar tiene 3 puntos de código de función y 7 puntos de manejo de excepciones, se recomienda utilizar productos intermedios de comunicación más maduros. para implementar el procesamiento de la comunicación.