Limitazione avanzata delle richieste con Gestione API di Azure

SI APPLICA A: Tutti i livelli di Gestione API

La possibilità di limitare le richieste in ingresso è uno dei ruoli fondamentali di Gestione API di Azure. Tramite il controllo della frequenza delle richieste o del totale delle richieste o dei dati trasferiti, Gestione API consente ai provider di API di proteggere le API da abusi e di aggiungere valore a diversi livelli di prodotto API.

Limiti e quote di frequenza

Le quote e i limiti di frequenza vengono usate per scopi diversi.

Limiti di richieste inviate al bot

I limiti di frequenza vengono in genere usati per proteggere da picchi di volume brevi e intensi. Ad esempio, se si conosce che il servizio back-end ha un collo di bottiglia nel database con un volume di chiamate elevato, è possibile impostare un criterio per non consentire un rate-limit-by-key volume di chiamate elevato usando questa impostazione.

Obiettivi di vendita

Le quote vengono in genere usate per controllare i tassi di chiamata in un periodo di tempo più lungo. Ad esempio, possono impostare il numero totale di chiamate che un determinato sottoscrittore può effettuare in un mese. Per monetizzare l'API, le quote possono essere impostate in modo diverso per le sottoscrizioni basate su livelli. Ad esempio, una sottoscrizione di livello Basic potrebbe effettuare non più di 10.000 chiamate al mese, ma una di livello Premium potrebbe raggiungere 100.000.000 chiamate mensili.

All'interno di Azure Gestione API, i limiti di frequenza vengono in genere propagati più velocemente tra i nodi per proteggersi da picchi. Al contrario, le informazioni sulla quota di utilizzo vengono usate a lungo termine e pertanto l'implementazione è diversa.

Limitazione basata sul prodotto

Le funzionalità di limitazione della frequenza con ambito per una determinata sottoscrizione sono utili per il provider di API per applicare limiti agli sviluppatori che hanno effettuato l'iscrizione per usare l'API. Tuttavia, non è utile, ad esempio, nella limitazione dei singoli utenti finali dell'API. È possibile che un singolo utente dell'applicazione dello sviluppatore usi l'intera quota e quindi impedisca ad altri clienti dello sviluppatore di usare l'applicazione. Inoltre, alcuni clienti possono generare un numero elevato di richieste, limitando l'accesso agli utenti occasionali.

Limitazione personalizzata basata su chiavi

I criteri rate-limit-by-key e quota-by-key offrono una soluzione più flessibile per il controllo del traffico. Questi criteri consentono di definire espressioni per identificare le chiavi usate per tenere traccia dell'utilizzo del traffico. Il modo più semplice per spiegarne il funzionamento è illustrare un esempio.

Limitazione degli indirizzi IP

I seguenti criteri limitano l'indirizzo IP di un singolo client a 10 chiamate al minuto, con un totale di 1.000.000 chiamate e 10.000 KB di larghezza di banda al mese.

<rate-limit-by-key  calls="10"
          renewal-period="60"
          counter-key="@(context.Request.IpAddress)" />

<quota-by-key calls="1000000"
          bandwidth="10000"
          renewal-period="2629800"
          counter-key="@(context.Request.IpAddress)" />

Se tutti i client su Internet usassero un indirizzo IP univoco, sarebbe un metodo efficace per limitare l'utilizzo per utente. È tuttavia probabile che più utenti condividano un singolo indirizzo IP pubblico, in quanto accedono a Internet tramite un dispositivo NAT. Nonostante ciò, per le API che consentono l'accesso non autenticato, IpAddress può essere la soluzione migliore.

Limitazione dell'identità utente

Se un utente finale viene autenticato, può essere generata una chiave per la limitazione delle richieste in base alle informazioni che identificano in modo univoco l'utente.

<rate-limit-by-key calls="10"
    renewal-period="60"
    counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />

Questo esempio illustra come estrarre l'intestazione dell'autorizzazione, convertirla in un oggetto JWT, identificare l'utente tramite l'oggetto del token e usarlo come chiave per la limitazione della frequenza. Se l'identità dell'utente è archiviata nell'oggetto JWT come una delle altre attestazioni, è possibile sostituirla con quel valore.

Criteri combinati

Sebbene i criteri di limitazione basati sull'utente forniscano un maggiore controllo rispetto ai criteri di limitazione basata su sottoscrizione, esiste comunque un valore che combina entrambe le funzionalità. La limitazione per chiave di sottoscrizione del prodotto (Limit call rate by subscription (Limitare la frequenza delle chiamate per sottoscrizione) e Set usage quota by subscription (Impostare la quota di utilizzo per sottoscrizione)) è un ottimo metodo per monetizzare un'API effettuando gli addebiti in base ai livelli di utilizzo. Il controllo con granularità maggiore per impostare la limitazione per utente è complementare e impedisce che il comportamento di un utente comprometta l'esperienza di un altro utente.

Limitazione basata su client

Quando la chiave per la limitazione viene definita mediante un' espressione di criteri, è il provider di API a scegliere l'ambito della limitazione. Uno sviluppatore può tuttavia voler controllare la modalità di limitazione della frequenza per i propri clienti. Il provider di API può abilitare questa opzione introducendo un'intestazione personalizzata per consentire all'applicazione client dello sviluppatore di comunicare la chiave all'API.

<rate-limit-by-key calls="100"
          renewal-period="60"
          counter-key="@(request.Headers.GetValueOrDefault("Rate-Key",""))"/>

In questo modo l'applicazione client dello sviluppatore è in grado di scegliere la modalità di creazione della chiave di limitazione della frequenza. Gli sviluppatori di client possono creare i propri livelli di frequenza allocando set di chiavi agli utenti e ruotando l'utilizzo delle chiavi.

Riepilogo

Gestione API di Azure offre funzionalità di limitazione della frequenza e della quota per proteggere e aggiungere valore al proprio servizio API. I nuovi criteri di limitazione con regole personalizzate di definizione dell'ambito consentono di controllare con granularità maggiore tali criteri per consentire ai clienti di creare applicazioni migliori. Gli esempi in questo articolo illustrano l'uso di questi nuovi criteri tramite la produzione di chiavi per la limitazione della frequenza con gli indirizzi IP del client, l'identità dell'utente e valori generati dal client. È tuttavia possibile usare molte altre parti del messaggio, ad esempio l'agente utente, frammenti del percorso dell'URL e la dimensione del messaggio.

Passaggi successivi

Inviare commenti e suggerimenti come problema di GitHub per questo argomento. Può essere utile individuare altri potenziali valori di chiave che sono utili negli scenari in uso.