Cos'è il rate limiting?
Le organizzazioni usano il rate limiting per assicurare l'uso equo dei loro servizi basati su API e di altri servizi e risorse web da parte dei clienti. Regola il numero di volte che un utente può richiedere un particolare servizio basato su API in un determinato lasso di tempo.
Quando migliaia di utenti condividono un servizio, il rate limiting aiuta il sistema ad essere disponibile per tutti i suoi clienti. Il rate limiting protegge anche un sistema da attacchi di diniego di servizio (DoS). In un attacco DoS, un utente malintenzionato potrebbe avviare un numero enorme di richieste di servizio in un breve periodo. Questo provoca l'esaurimento delle risorse. Ciò significa che il sistema diventa indisponibile per gli utenti legittimi. In alcuni casi, un servizio web, un'API o altre risorse potrebbero ricevere numerose richieste a causa di un errore nel lato client o utente. Il rate limiting è un approccio pratico che le organizzazioni utilizzano per evitare tali scenari.
I limiti sulla messaggistica dei social media sono un tipico esempio di rate limiting che incontra la maggior parte degli utenti di Internet. I siti di social media come Facebook, LinkedIn o Instagram spesso pongono un limite al numero di messaggi diretti che gli utenti possono inviare in un giorno. Per esempio, se un utente decide di inoltrare un messaggio a migliaia di contatti, si attiva la logica di rate limiting del servizio di social media, che può impedire all'utente di inviare altri messaggi per un certo periodo.
Perché le organizzazioni hanno bisogno del rate limiting?
Nell'era digitale, le organizzazioni forniscono la maggior parte dei servizi attraverso le API. Questi servizi basati su API consentono alle organizzazioni di avere un ottimo controllo dei propri sistemi. Tuttavia, ospitare le API e il database di back-end appesantisce le loro risorse. Le organizzazioni dovrebbero usare il rate limiting per assicurare un uso equo delle API ed evitare che alcuni utenti prosciughino le loro risorse. Quando un'API diventa popolare, il numero di utenti raggiunge rapidamente il picco. In questi scenari, le organizzazioni hanno bisogno di garantire che tutti i propri servizi siano disponibili e non sovraccarichi. Il rate limiting aiuta anche le organizzazioni a proteggere, governare e monetizzare i servizi.
Quali sono i principali tipi di rate limiting?
Esistono diversi tipi principali di modelli di rate limiting tra cui un'azienda può scegliere, a seconda di quale offre la soluzione migliore per un'attività basata sulla natura dei servizi web offerti, come scopriremo più in dettaglio di seguito.
Rate limiting al livello di utente
Nei casi in cui un sistema può identificare univocamente un utente, può limitare il numero di richieste API che un utente effettua in un periodo di tempo. Per esempio, se l'utente è autorizzato a effettuare solo due richieste al secondo, il sistema nega la terza richiesta dell'utente effettuata nello stesso secondo. Il rate limiting al livello di utente assicura un uso equo. Tuttavia, mantenere le statistiche di utilizzo di ogni utente può creare un overhead al sistema che, se non richiesto per altre ragioni, potrebbe essere uno spreco di risorse.
Rate limiting al livello di server
La maggior parte dei servizi basati su API sono di natura distribuita. Ciò significa che quando un utente invia una richiesta, questa potrebbe essere servita da uno qualsiasi dei tanti server. Nei sistemi distribuiti, il rate limiting può essere usato per la condivisione del carico tra i server. Per esempio, se un server riceve una grande quantità di richieste su dieci server in un sistema distribuito e gli altri sono perlopiù inattivi, il sistema non è pienamente utilizzato. Ci sarà una restrizione sul numero di richieste di servizio che un particolare server può gestire nel rate limiting al livello di server. Se un server riceve richieste che superano questo limite impostato, esse vengono abbandonate o indirizzate ad un altro server. Il rate limiting al livello di server assicura la disponibilità del sistema e previene gli attacchi di diniego di servizio mirati a un particolare server.
Rate limiting basato sulla geografia
La maggior parte dei servizi basati su API dispone di server sparsi in tutto il mondo. Quando un utente emette una richiesta API, un server vicino alla posizione geografica dell'utente la soddisfa. Le organizzazioni implementano il rate limiting basato sulla geografia per limitare il numero di richieste di servizio da una particolare area geografica. Ciò può essere effettuato anche in base alla tempistica. Per esempio, se il numero di richieste provenienti da una particolare posizione geografica è piccolo dalle 1:00 alle 6:00 del mattino, allora un server web può avere una regola di rate limiting per questo particolare periodo. Se avviene un attacco al server durante queste ore, il numero di richieste avrà un picco. In caso di picco, il meccanismo di rate limiting farà scattare un allarme e l'organizzazione potrà rispondere rapidamente a tale attacco.
Quali sono gli algoritmi utilizzati per il rate limiting?
Rate limiting a finestra fissa
Il rate limiting a finestra fissa limita il numero di richieste API in un momento specifico. Per esempio, un server può avere un componente di rate limiting che implementa un algoritmo a finestra fissa che accetta solo 100 richieste al minuto. L'intervallo di tempo è fisso e inizia in un momento specifico. Per esempio, il server servirà solo 100 richieste tra le 10:00 e le 10:01. Alle 10:01, la finestra si azzera. Gli algoritmi a finestra fissa possono essere implementati al livello utente o al livello server. Se è implementato al livello utente, ogni utente può effettuare 100 richieste al minuto. Se è al livello server, allora tutti gli utenti possono effettuare collettivamente 100 richieste al minuto.
Il diagramma seguente mostra il flusso di lavoro dell'algoritmo a finestra fissa con rate limiting al livello utente. In questo flusso di lavoro, ad un utente viene assegnata una chiave per l'identificazione unica e c'è un contatore collegato ad ogni utente unico; quando l'utente fa una richiesta entro un periodo di tempo, il contatore aumenta.
Vantaggi e svantaggi dell'algoritmo a finestra fissa
L'algoritmo a finestra fissa è facile da implementare poiché è basato su un intervallo di tempo fisso. Dato che il conteggio delle richieste si rinnova all'inizio di ogni intervallo, l'algoritmo a finestra fissa non causa un'inedia delle richieste più recenti. Uno svantaggio di un algoritmo a finestra fissa, d'altra parte, è che comporta una corsa alle richieste, specialmente all'inizio della finestra temporale. Ad esempio, se un server autorizza 1000 richieste al secondo, tutte le 1000 richieste possono avvenire in simultanea, potenzialmente sovraccaricando il server. Il problema può sorgere in quanto non vi è alcuna restrizione sull'intervallo di tempo minimo tra le due richieste.
Rate limiting con leaky bucket
A differenza dell'algoritmo a finestra fissa, l'algoritmo leaky bucket non si basa su finestre temporali. Ha invece una coda di lunghezza fissa che non dipende dal tempo. Il server web serve la richiesta in base all'ordine di arrivo. Ogni nuova richiesta viene aggiunta alla fine della coda. Se la coda è piena quando arriva una nuova richiesta, il server lascia cadere la richiesta.
Vantaggi e svantaggi dell'algoritmo leaky bucket
Uno dei principali vantaggi dell'algoritmo leaky bucket è che, essendo basato su una coda, è facile da implementare. Inoltre, presenta richieste API al server a un ritmo costante. A differenza dell'algoritmo a finestra fissa, non vi sarà un'esplosione nel numero di richieste in qualsiasi momento particolare. Tuttavia, poiché l'algoritmo leaky bucket è basato su una coda statica, vi è una possibilità di inedia, il che significa che le richieste più recenti potrebbero non essere servite affatto. Questo problema non è presente in una finestra fissa, poiché la finestra temporale viene periodicamente aggiornata per accettare nuove richieste.
Algoritmo di rate limiting a finestra scorrevole
L'algoritmo a finestra scorrevole è abbastanza simile all'algoritmo a finestra fissa, tranne che per il punto di partenza della finestra temporale. Nella finestra scorrevole, la finestra temporale inizia solo quando viene effettuata una nuova richiesta. Per esempio, se la prima richiesta viene effettuata alle 10:02, e il server autorizza due richieste al minuto, la finestra temporale è dalle 10:02 alle 10:03.
L'algoritmo a finestra scorrevole risolve efficacemente il problema del burst nelle richieste che affligge l'algoritmo a finestra fissa. Affronta anche il problema dell'inedia che riguarda gli algoritmi leaky bucket.
Quali sono gli usi principali del rate limiting?
Lo scopo principale del rate limiting è garantire un uso equo delle risorse condivise. Oltre a questo, il rate limiting è una tecnica versatile che le organizzazioni possono utilizzare per un'ampia varietà di motivi.
Il rate limiting offre maggiore sicurezza
Il rate limiting previene attacchi di diniego di servizio (DoS). In un attacco DoS, un utente malintenzionato avvia un massiccio numero di richieste di servizio per far cadere il sistema. Per esempio, se un promotore di concerti e sito di vendita di biglietti riceve un milione di richieste in un secondo non appena un concerto è in vendita, il sistema verrà soffocato e il webserver e il database potrebbero diventare non disponibili. Con il rate limiting, il sito web può prevenire qualsiasi tentativo del genere. Un attacco di diniego di servizio può avvenire anche se il cliente non ha alcun intento scorretto. Succede quando vi è un errore nel sistema che emette la richiesta (lato client). Il rate limiting previene anche questi attacchi involontari.
Controllo dell'accesso
Il rate limiting non si occupa solo di limitare il numero di richieste, ma può essere modificato per limitare anche il livello di accesso. Per esempio, se c'è un servizio basato su API per visualizzare e modificare i dettagli personali di un utente, l'algoritmo di rate-limiting può implementare diversi livelli di accesso. Un insieme di utenti può solo visualizzare i dettagli personali, mentre il secondo può sia visualizzare sia modificare i dettagli.
Misurazione per le API
Nei modelli di business API, il rate limiting può essere usato per misurare l'utilizzo. Per esempio, se un utente ha sottoscritto un piano che consente 1000 richieste API all'ora, la logica di rate limiting limiterà qualsiasi richiesta API oltre il limite. Inoltre, l'algoritmo di rate limiting può consentire in modo dinamico all'utente di acquistare più richieste al secondo.
Garantisce le prestazioni
Un obiettivo chiave dell'implementazione della logica di rate limiting è garantire le prestazioni di un'API. Quando il sistema consente richieste illimitate, le prestazioni del server peggiorano e rallentano l'API. In casi estremi, il server potrebbe non riuscire ad accogliere alcuna richiesta. Questo può provocare guasti a cascata in un sistema distribuito, in cui il carico del server non funzionante viene distribuito agli altri server e li sovraccarica gradualmente. Il rate limiting previene questa condizione limitando le richieste al livello di utente o di server.
Assicura la disponibilità
Uno dei principali requisiti dei servizi basati su API è la loro disponibilità 24/7. Ogni secondo, migliaia di utenti accedono a un'API. Anche pochi secondi di interruzione possono comportare una perdita enorme per l'organizzazione. Pertanto, è nel migliore interesse di ogni organizzazione adoperarsi per ridurre a zero i tempi di inattività. Il rate limiting e altre tecniche come la condivisione del carico permettono alle organizzazioni di limitare le improvvise esplosioni di richieste API e garantire la disponibilità del sistema.
Rate limiting dai lati client e server
Rate limiting lato server
Limitare le richieste degli utenti sul lato server è un metodo ampiamente praticato per il rate limiting. È nell'interesse del fornitore di servizi ridurre le richieste illimitate degli utenti per garantire le prestazioni e la disponibilità. Come abbiamo visto nella sezione precedente, le organizzazioni usano il rate limiting lato server per vari scopi.
Rate limiting lato client
Potrebbe sembrare che il rate limiting sia solo nell'interesse dei fornitori di API. In pratica, anche gli utenti o i clienti del servizio potrebbero beneficiare del rate limiting. I clienti che aderiscono alle restrizioni d'uso possono essere sempre sicuri che il fornitore di servizi soddisferà le loro richieste. Se l'utente non tiene conto del rate limiting, potrebbe trovarsi di fronte a qualche rifiuto improvviso o inaspettato delle sue richieste, che può influenzare la funzionalità delle sue soluzioni.
Per esempio, un'applicazione mobile potrebbe essere costruita sull'API di messaggistica di Facebook. Quando le persone usano questa applicazione, stanno effettivamente utilizzando la messaggistica di Facebook in background. In questo caso, è il cliente che deve prendere provvedimenti per garantire che l'applicazione aderisca alle norme di rate limiting. Se il rate limiting è trascurato sul lato client, gli utenti di questa applicazione mobile potrebbero trovarsi di fronte a errori imprevisti. È nel miglior interesse degli utenti API far rispettare il rate limiting sul lato client.
Quali sono le sfide nell'implementazione del rate limiting?
Sistemi distribuiti
Implementare la logica del rate limiting in un sistema con server distribuiti è una sfida. Quando un utente richiede un servizio basato su API da un sistema distribuito, il componente di rate limiting in ciascuno dei server dovrebbe sincronizzarsi con gli altri. Per esempio, supponendo che un utente abbia già utilizzato quattro delle cinque richieste al minuto ed emetta altre due richieste, queste due richieste andrebbero a due server diversi. Ognuno dei server estrae il conteggio delle richieste dell'utente e pensa che l'utente abbia emesso solo quattro richieste. Quindi entrambi i server autorizzano la richiesta di servizio. Così invece delle originali cinque richieste al minuto, l'utente ottiene sei richieste al minuto. Molti di questi problemi di sincronizzazione e di queste condizioni di gara potrebbero verificarsi quando il rate limiting è implementato in sistemi distribuiti.
Ci sono molteplici soluzioni alle incoerenze di rate limiting nei sistemi distribuiti. I server che usano software lock per proteggere il contatore delle richieste degli utenti è una soluzione. Con questo metodo, solo un server accede al contatore, che memorizza il numero di richieste effettuate in una finestra temporale. Un'altra soluzione semplice ma meno elegante sono le sessioni appiccicose in cui un singolo server serve sempre l'utente. Questo, tuttavia, respinge l'idea stessa di sistemi distribuiti.
Overhead computazionali
L'aggiunta di un ulteriore livello di logica in un'ottica di rate limiting aumenta l'overhead computazionale di un server. Se il sistema è già sovraccarico, l'aggiunta della logica di rate limiting rallenterebbe ulteriormente il sistema e gli utenti potrebbero sperimentare ritardi.
Invece di implementare la logica di rate limiting all'interno dello stesso server, potrebbe essere incorporata come componente esterno. Ogni volta che un utente richiede un'API, la richiesta viene prima instradata attraverso questo componente esterno che decide di autorizzare o rifiutare la richiesta.
Malfunzionamento nei componenti di rate limiting
L'aggiunta di un ulteriore livello di complessità per il rate limiting aggiunge una nuova possibilità di malfunzionamenti. Anche se l'API è attiva e funzionante, un errore nel componente di rate limiting comporterà il rifiuto delle richieste.
Una buona implementazione di rate limiting dovrebbe essere in grado di ripristinare rapidamente il sistema dopo un malfunzionamento. Può essere sotto forma di hard reset quando si verificano dei malfunzionamenti. Inoltre, proprio come i server di backup nei servizi basati su API, un duplicato del componente di rate limiting potrebbe assumere il ruolo se il componente originale fallisce.