SCTP: problema de retraso atascado en la grabación de un mensaje de Diámetro
1. Antecedentes
Cliente: 5 máquinas de interfaz
Servidor: 2 simuladores (simulando HSS, un servidor Diámetro)
Las direcciones de los 5 clientes son:
- 10.212.27.29
- 10.212.27.55
- 10.212.24.17
- 10.212.24.101
- 10.212.24.39
Las direcciones de los 2 servidores son:
- 10.212.27.10
- 10.212.27.176
El cliente se conecta activamente al servidor a través del protocolo SCTP.
El servidor escucha los puertos SCTP: 5868, 5869, 5870, 5871.
2. Fenómeno
En el lado del cliente, se descubrió que varios mensajes UDR/UDA de diámetro por segundo estaban bloqueados:
desde el momento en que se envió la UDR del cliente al servidor hasta el momento en que el cliente recibió la respuesta UDA del servidor, había varios mensajes. eso tomó más de 100 ms.
Después de capturar paquetes en ambos lados del cliente y del servidor, descubrimos que la diferencia de tiempo entre el servidor que recibe UDR y envía UDA es de hecho de más de 100 ms.
Según la captura de paquetes SCTP en el servidor y el filtrado por el ID de sesión del mensaje de Diámetro, se puede ver que efectivamente es lento.
3. Razón
Al principio, se especuló que el procesamiento comercial UDR/UDA en el servidor era lento o que había un problema con el módulo Diámetro en el servidor.
Sin embargo, agregue intervalos de cálculo de marca de tiempo en todas partes del módulo Diámetro del lado del servidor, especialmente:
- El tiempo T1 SCTP/Diámetro/UDR se recibe en el módulo Diámetro del servidor;
- Escriba SCTP/Diámetro/UDA hora T2 en el módulo Diámetro del servidor;
T2-T1 tampoco llega a los 100ms.
Se puede ver que no es el módulo Diámetro del lado del servidor el que tiene un retraso, ni el retraso del proceso de procesamiento UDR/UDA del lado del servidor.
Por supuesto, también es posible que el módulo Diámetro del lado del servidor lea lentamente. . .
Finalmente, encontrado a través de netstat:
1) Lado del servidor
netstat-anp | grep scp | Agarre 58
Se puede ver que hay una gran cantidad de mensajes SCTP acumulados en el enlace SCTP del servidor al cliente.
Teóricamente, uno de mis UDR/UDA tiene aproximadamente 300-800B, es decir, hay un total de 10-5 mensajes de Diámetro acumulados en un enlace SCTP.
¿Es porque el módulo de diámetro del cliente tarda en leer SCTP?
2) Cliente
netstat-anp | grep scp | grep -E “10.212.27.10|10.212.27.176”
Desde el lado del cliente, se encuentra que los buffers de lectura SCTP del módulo Diámetro del cliente y del módulo Diámetro del servidor están vacíos y no hay acumulación, no es que el módulo Diámetro del cliente sea lento en lectura.
analizar:
- Visto desde el lado del cliente, no hay acumulación en el búfer de recepción SCTP;
- Mirando el lado del servidor, hay acumulación en el búfer de envío SCTP;
El servidor es 27.10, 27.176, que son 27 segmentos de red;
el cliente es 27.29, 27.55, 24.17, 24.101, 24.39, hay 27 segmentos de red y también hay 24 segmentos de red;
observe más de cerca la captura de pantalla de netstat en la página servidor:
puede encontrar:
El servidor (segmento de red 27) se está comunicando con el cliente (segmento de red 27) y la acumulación del búfer de envío es 0; el
servidor (segmento de red 27) se está comunicando con el cliente (segmento de red 24) y la acumulación del buffer de envío siempre es distinta de 0. ;
Después de consultar al colega a cargo de la red en el laboratorio, dijo:
El laboratorio tiene serios problemas de red, como la pérdida de paquetes entre segmentos de la red.
Hasta este punto, el problema ha sido relativamente claro:
debido a que el cliente y el servidor están en diferentes segmentos de la red, los problemas de la red han provocado la acumulación de enlaces SCTP.
Debido a que el enlace SCTP tiene un búfer de lectura y escritura del kernel, los mensajes en el enlace SCTP se retrasan y la aplicación (servidor) no puede percibirlos: la aplicación
llama al sistema de socket subyacente para escribir datos SCTP y regresa inmediatamente.
Lo que la aplicación puede ver es que escribir datos SCTP en SCTP conn es muy rápido y regresa inmediatamente sin demora.
Después de ajustar el cliente y el servidor al mismo segmento de red, el problema se resolvió, no hubo más acumulación y el retraso desapareció.