Un servidor web 4D que sabe cuándo decir no

Ajustar la carga de trabajo de su servidor web 4D es ahora muy fácil. A partir de la versión 4D 21 R5, su servidor web ya no está expuesto a sobrecargas involuntarias, ya sea por un volumen excesivo de datos solicitados, un número demasiado elevado de solicitudes entrantes o un aumento repentino de sesiones de usuarios invitados.

Siga leyendo para descubrir todo lo que necesita para crear un sistema de limitación de tasa totalmente personalizado para su servidor de aplicaciones web.

En una entrada anterior del blog sobre 4D 21 R4, presentamos una forma de limitar el número de conjuntos de entidades en una sesión REST, lo que supuso el primer capítulo de una historia mucho más amplia. Hoy, esa historia alcanza un hito importante (aunque no definitivo).

Con 4D 21 R5, su 4D Web Server puede ajustarse con precisión para mantener bajo control el tráfico entrante y saliente, gracias a las cuotas.

Esta nueva función no modifica el comportamiento predeterminado de su servidor web: de serie, no se aplica ningún límite. En función de sus necesidades, puede recurrir a una amplia gama de límites: utilice solo uno, utilícelos todos; la granularidad depende totalmente de usted.

HDI_WebServer_RateLimitingQuotas

Añadiendo inteligencia de aplicaciones a la protección web clásica

Esta función complementa, en lugar de sustituir, a los proxies inversos, los WAF, los cortafuegos… y otros servicios. Estas tecnologías protegen el perímetro de la red y filtran el tráfico hostil, mientras que 4D ofrece una regulación de la carga de trabajo a nivel de aplicación dentro del servidor web.

Su valor añadido radica en su conocimiento de las sesiones de 4D y del contexto de la aplicación: los desarrolladores pueden definir cuotas globales y a nivel de sesión para solicitudes, volúmenes de datos, sesiones y conjuntos de entidades. Esto permite controlar el uso malformado o excesivo, el tráfico MCP y los flujos de trabajo específicos de la empresa directamente desde la aplicación.

Cuotas a nivel de servidor y de sesión

Antes de entrar en detalles: para un control más preciso, la mayoría de las cuotas se pueden establecer en dos niveles:

• Nivel de servidor: limita la actividad de todo el servidor
• Nivel de sesión: se aplica individualmente a cada sesión recién creada

Puede recurrir únicamente a las cuotas a nivel de servidor, únicamente a las cuotas a nivel de sesión o combinar ambas.

Ventaja: las cuotas a nivel de sesión ponen a todos los usuarios en igualdad de condiciones, evitando que un solo usuario acapare los recursos de su servidor web.

Qué pueden regular las cuotas

Las cuotas le permiten controlar:

• Tráfico entrante: número de bytes recibidos, número de solicitudes aceptadas
• Tráfico saliente: número de bytes enviados
• Sesiones: el número máximo de sesiones activas
• Sesiones de invitado: el número máximo de sesiones que aún no se han autenticado mediante setPrivileges().
• Conjuntos de entidades: el número máximo de conjuntos de entidades permitidos por defecto para cada sesión REST recién creada

El principio fundamental: una vez que se supera una cuota, el servidor responde con un código de estado HTTP 429 – Too Many Requests.

Ventaja: se cubren todos los aspectos que podrían sobrecargar su servidor web: no solo los bytes entrantes y salientes, sino también las solicitudes. Puede limitar tanto las sesiones de invitado inactivas como el número de sesiones de usuario simultáneas.

Las cuotas regulan el uso de su servidor web de forma fluida, indicando a los usuarios que el servidor no está caído ni se ha bloqueado, sino que simplemente está haciendo su trabajo, moderando la carga para mantener una disponibilidad fiable.

En detalle: dos tipos de cuotas

Las cuotas pueden ser de dos tipos:

• Cuotas de limitación de tasa
• Cuotas de concurrencia

Cuotas de limitación de tasa

Estas abarcan:

• Número de bytes recibidos
• Número de solicitudes aceptadas
• Número de bytes enviados

Se basan en un sistema de ventanas temporales, tanto a nivel de minutos como de horas, por lo que puede definir el número máximo de bytes (o solicitudes) que su servidor web, y/o sus sesiones, pueden gestionar en una ventana de un minuto o una hora.

Una vez que se supera una cuota dentro de una ventana de tiempo, el servidor devuelve un código de estado HTTP 429 hasta que se abre la siguiente ventana.

Estas cuotas se pueden configurar tanto a nivel global del servidor como a nivel de sesión.

Ventaja: la combinación de ventanas de un minuto y de una hora te ofrece un control muy preciso, suavizando los picos minuto a minuto sin dejar de aplicar un límite máximo por hora.

Si se aplica la misma lógica a nivel de sesión, se regula la actividad de cada usuario de forma individual, evitando que cualquiera de ellos acapare todo el ancho de banda.

Cuotas simultáneas

Estas abarcan:

• Número máximo de sesiones
• Número máximo de sesiones de invitado
• Número máximo de conjuntos de entidades permitidos por defecto para cada sesión REST recién creada

Se trata de contadores absolutos: una vez que se supera una cuota, el servidor devuelve un código de estado HTTP 429 hasta que el contador se reduzca. Por ejemplo, cuando se cierra una sesión, lo que libera espacio para una nueva.

Ventaja: esto complementa muy bien las cuotas de limitación de tasa, ya que también regula el número de usuarios, no solo su tráfico.

Configuración de cuotas

El objeto WEB Server expone una propiedad `quotas `, un objeto que es, más concretamente, una instancia de la clase 4D.QuotaManager.

Hay tres formas de configurar las cuotas: elija la que mejor se adapte a su arquitectura:

1- Actualice el objeto `quotas` sobre la marcha, una vez que el servidor web ya esté en funcionamiento:

var $quotas : 4D.QuotaManager

$quotas:=WEB Server().quotas

$quotas.inBytesPerMin:=10000000

2- Pasar un objeto quotas al iniciar el servidor web:

var $quotas:={}

$quotas.inBytesPerMin:=20000000

WEB Server().start({quotas: $quotas})

3- Utilizar un archivo de configuración HTTPQuotas.json, que se lee automáticamente al iniciar el servidor:

  {
    "inBytesPerMin": 10000
  }

Ventaja: flexibilidad total. Sea cual sea su entorno de implementación, una de estas opciones se adaptará a él.

Un ejemplo concreto

var $quotas:={}

// Maximum number of input bytes accepted in a one-minute time window on the web server
$quotas.inBytesPerMin:=20000000

// Maximum number of sent bytes in a one-minute time window in a session
$quotas.outBytesPerMinPerSession:=10000000

// Maximum number of allowed sessions on the web server
$quotas.nbSessions:=50

// Maximum number of not authenticated sessions on the web server
$quotas.nbGuestSessions:=10

// Maximum number of accepted requests in a one-minute time window on the web server
$quotas.nbRequestsPerMin:=500

// Maximum number of accepted requests in a one-hour time window on the web server
$quotas.nbRequestsPerHour:=20000

WEB Server().start({quotas: $quotas})

Nota:

nbRequestsPerHour no es simplemente nbRequestsPerMin × 60 (lo que daría 30 000). Se ha fijado deliberadamente en un valor inferior, concretamente en 20 000. De esta forma, incluso una carga de trabajo que agote la cuota por minuto durante varios minutos sueltos no podrá mantener ese ritmo durante casi una hora, lo que le proporciona un auténtico límite máximo por hora en lugar de una simple cuota por minuto reformulada.

Mientras los usuarios trabajan con la aplicación, cada vez que se supera una cuota, el servidor devuelve un código de estado HTTP 429 – Too Many Requests.

Cuando procede, el encabezado de respuesta Retry-After indica al cliente exactamente cuántos segundos debe esperar antes de volver a intentarlo:

Pruébelo usted mismo con el HDI detallado, profundice en todos los detalles de la documentación y no dude en compartir su experiencia en el foro.

Olvídese de que el servidor se ralentice por sobrecarga. Aproveche hoy mismo el máximo rendimiento de su servidor web.