Ottimizzare il carico di lavoro del tuo server web 4D è ora un gioco da ragazzi. A partire dalla versione 4D 21 R5, il tuo server web non è più esposto a sovraccarichi involontari, che si tratti di un volume eccessivo di dati richiesti, di un numero troppo elevato di richieste in entrata o di un’esplosione di sessioni degli utenti.
Continua a leggere per scoprire tutto ciò che ti serve per creare un sistema di limitazione della frequenza completamente personalizzato per il tuo server di applicazioni web.
In un precedente post sul blog dedicato a 4D 21 R4, abbiamo presentato un metodo per limitare il numero di insiemi di entità in una sessione REST: era solo il primo capitolo di una storia molto più ampia. Oggi, quella storia raggiunge un traguardo importante (seppur non definitivo).
Con 4D 21 R5, il tuo 4D Web Server può essere ottimizzato per tenere sotto controllo il traffico in entrata e in uscita, grazie alle quote.
Questa nuova funzionalità non modifica il comportamento predefinito del vostro server web: di default, non viene applicata alcuna quota. A seconda delle vostre esigenze, potete attingere da una gamma completa di quote: utilizzarne solo una, utilizzarle tutte, la granularità dipende interamente da voi.
HDI_WebServer_RateLimitingQuotas
Aggiungere intelligenza applicativa alla protezione web classica
Questa funzionalità integra, anziché sostituire, i proxy inversi, i WAF, i firewall e altri servizi. Queste tecnologie proteggono il perimetro di rete e filtrano il traffico ostile, mentre 4D garantisce la regolazione del carico di lavoro a livello di applicazione all’interno del server web.
Il suo valore aggiunto risiede nella consapevolezza delle sessioni 4D e del contesto applicativo: gli sviluppatori possono definire quote globali e a livello di sessione per richieste, volumi di dati, sessioni e insiemi di entità. Ciò consente di controllare direttamente all’interno dell’applicazione gli utilizzi non corretti o eccessivi, il traffico MCP e i flussi di lavoro specifici dell’azienda.
Quote a livello di server e di sessione
Prima di addentrarci nei dettagli: per un controllo più preciso, la maggior parte delle quote può essere impostata su due livelli:
- Livello del server: limita l’attività dell’intero server
- Livello di sessione: si applica individualmente a ciascuna sessione appena creata
È possibile affidarsi esclusivamente alle quote a livello di server, esclusivamente a quelle a livello di sessione oppure combinare entrambe.
Vantaggio: le quote a livello di sessione mettono tutti gli utenti su un piano di parità, impedendo che un singolo utente monopolizzi le risorse del server web.
Cosa è possibile regolare con le quote
Le quote consentono di tenere sotto controllo:
- Traffico in entrata: numero di byte ricevuti, numero di richieste accettate
- Traffico in uscita: numero di byte inviati
- Sessioni: il numero massimo di sessioni attive
- Sessioni ospite: il numero massimo di sessioni non ancora autenticate tramite setPrivileges().
- Insiemi di entità: il numero massimo di insiemi di entità consentiti per impostazione predefinita per ogni sessione REST appena creata
Il principio fondamentale: una volta superata una quota, il server risponde con un codice di stato HTTP 429 – Too Many Requests.
Vantaggio: vengono coperti tutti gli aspetti che potrebbero sovraccaricare il server web: non solo i byte in entrata e in uscita, ma anche le richieste. È possibile limitare sia le sessioni ospite inattive sia il numero di sessioni utente simultanee.
Le quote regolano l’utilizzo del server web in modo fluido, comunicando agli utenti che il server non è inattivo né si è bloccato, ma sta semplicemente svolgendo il proprio lavoro, moderando il carico per garantire una disponibilità affidabile.
Dietro le quinte: due tipi di quote
Le quote si dividono in due tipologie:
- Quote di limitazione della velocità
- Quote di simultaneità
Quote di limitazione della velocità
Queste riguardano:
- Numero di byte ricevuti
- Numero di richieste accettate
- Numero di byte inviati
Si basano su un sistema a finestre temporali, sia a livello di minuto che di ora, in modo da poter definire il numero massimo di byte (o richieste) che il server web e/o le sue sessioni possono gestire all’interno di una finestra di un minuto o di un’ora.
Una volta superata una quota all’interno di una finestra temporale, il server restituisce un codice di stato HTTP 429 fino all’apertura della finestra successiva.
Queste quote possono essere configurate sia a livello globale del server che a livello di sessione.
Vantaggio: la combinazione di finestre di un minuto e di un’ora offre un controllo molto granulare, livellando i picchi minuto per minuto pur mantenendo un limite massimo orario.
Applicando la stessa logica a livello di sessione, è possibile regolare l’attività di ciascun utente individualmente, impedendo che uno di essi consumi tutta la larghezza di banda.
Quote simultanee
Queste riguardano:
- Numero massimo di sessioni
- Numero massimo di sessioni ospite
- Numero massimo di insiemi di entità consentiti per impostazione predefinita per ogni nuova sessione REST creata
Si tratta di contatori assoluti: una volta superata una quota, il server restituisce un codice di stato HTTP 429 finché il contatore non si azzera. Ad esempio, quando una sessione viene chiusa, liberando spazio per una nuova.
Vantaggio: ciò integra efficacemente le quote di limitazione della frequenza, regolando anche il numero di utenti, non solo il loro traffico.
Configurazione delle quote
L’ WEB Server oggetto espone una proprietà `quotas `, un oggetto che, più precisamente, è un’istanza della 4D.QuotaManager classe.
Esistono tre modi per configurare le quote: scegliete quello più adatto alla vostra architettura:
1- Aggiornare l’oggettoquotas al volo, una volta che il server web è già in esecuzione:
var $quotas : 4D.QuotaManager
$quotas:=WEB Server().quotas
$quotas.inBytesPerMin:=10000000
2- Passare un oggetto `quotas` all’avvio del server web:
var $quotas:={}
$quotas.inBytesPerMin:=20000000
WEB Server().start({quotas: $quotas})
3- Utilizzare un file di configurazione HTTPQuotas.json, letto automaticamente all’avvio:
{
"inBytesPerMin": 10000
}
Vantaggio: flessibilità totale. Qualunque sia la vostra configurazione, una di queste opzioni sarà adatta.
Un esempio 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})
Ecco cosa vedrai nel debugger:

Nota:
nbRequestPerHour non è semplicemente nbRequestPerMin × 60 (che sarebbe 30.000). È stato deliberatamente impostato su un valore inferiore, ovvero 20.000. In questo modo, anche un carico di lavoro che raggiunga il limite massimo della quota al minuto per diversi minuti consecutivi non potrà comunque mantenere quel ritmo per quasi un’ora, garantendoti un vero e proprio limite orario anziché una semplice quota al minuto riformulata.
Mentre gli utenti utilizzano l’applicazione, ogni volta che viene superata una quota, il server restituisce un codice di stato HTTP 429 – Too Many Requests.
Se pertinente, l’intestazione di risposta Retry-After indica al client esattamente quanti secondi attendere prima di riprovare:

Provalo tu stesso con l’HDI dettagliato, approfondisci tutti i dettagli nella documentazione e sentiti libero di condividere la tua esperienza sul forum.
Dimenticate i rallentamenti causati dal sovraccarico del server. Sfruttate oggi stesso le massime prestazioni del vostro server web.
Al momento non è possibile lasciare commenti su questo post.