Limitação de taxa (rate limiting)

A limitação de taxa (rate limiting), também conhecida como request throttling, é um mecanismo para controlar a velocidade com que um usuário ou serviço pode enviar requisições a uma API ou servidor, evitando abusos, garantindo alocação justa de recursos e mantendo a estabilidade do sistema.

Entendendo a limitação de taxa

A limitação de taxa protege serviços contra volumes excessivos de requisições que poderiam levar à degradação de desempenho, a ataques de negação de serviço (DoS) ou ao esgotamento de recursos. Ela garante que os recursos do sistema fiquem disponíveis para todos os usuários legítimos e impede que uma única entidade monopolize o acesso. Um serviço de proxy costuma ter papel crucial na aplicação desses limites, seja aplicando-os às requisições do cliente antes que elas cheguem aos serviços upstream, seja comunicando de volta aos clientes os limites do upstream.

Por que implementar limitação de taxa?

• Proteção de recursos: impede que os servidores sejam sobrecarregados por requisições em excesso, preservando CPU, memória e largura de banda de rede.
• Prevenção de abuso: mitiga ataques de força bruta, credential stuffing e outras atividades maliciosas ao limitar as tentativas de requisição.
• Uso justo: garante que todos os clientes tenham acesso equitativo aos recursos compartilhados, impedindo que um único cliente monopolize o sistema.
• Controle de custos: em serviços com cobrança baseada em uso, os limites de taxa ajudam a controlar os custos operacionais ao limitar o consumo de recursos.

Algoritmos comuns de limitação de taxa

Diferentes algoritmos são usados para monitorar e aplicar limites de taxa, cada um com características distintas quanto à forma de lidar com rajadas e ao uso de recursos.

Token Bucket (balde de tokens)

O algoritmo Token Bucket modela um balde de capacidade fixa que é reabastecido com tokens a uma taxa constante. Cada requisição consome um token. Se o balde estiver vazio, a requisição é rejeitada ou colocada na fila. Esse algoritmo permite certa rajada, pois as requisições podem consumir vários tokens, se disponíveis, até a capacidade do balde.

Leaky Bucket (balde furado)

O algoritmo Leaky Bucket processa requisições a uma taxa de saída fixa. As requisições são adicionadas a uma fila (o "balde"). Se a fila estiver cheia, novas requisições são rejeitadas. As requisições "vazam" do balde a uma taxa constante, garantindo um fluxo estável de processamento. Esse algoritmo suaviza rajadas, mas introduz latência para as requisições que precisam esperar na fila.

Fixed Window Counter (contador de janela fixa)

No algoritmo Fixed Window Counter, define-se uma janela de tempo (por exemplo, 60 segundos) e um contador registra as requisições dentro dessa janela. Quando a janela expira, o contador é zerado. Requisições que excedem o limite dentro da janela são rejeitadas. Uma desvantagem é o "problema de rajada" nas bordas da janela, em que os clientes podem enviar o dobro das requisições permitidas ao longo de duas janelas consecutivas.

Sliding Window Log (log de janela deslizante)

O algoritmo Sliding Window Log registra um timestamp para cada requisição. Quando uma nova requisição chega, o sistema conta quantos timestamps existem nos últimos N segundos (a janela). Se essa contagem exceder o limite, a requisição é rejeitada. Esse método é preciso, mas pode consumir muita memória por armazenar todos os timestamps.

Sliding Window Counter (contador de janela deslizante)

Este algoritmo combina aspectos do Fixed Window e do Sliding Window Log para mitigar o problema de borda sem o custo de memória de registrar cada requisição. Ele usa duas janelas fixas: a janela atual e a anterior. O timestamp da requisição atual determina sua posição dentro da janela atual. As requisições permitidas são calculadas como uma média ponderada entre a contagem da janela anterior e a da janela atual, com base na fração da janela atual já decorrida.

Comparação entre algoritmos

Como identificar a limitação de taxa

Quando um limite de taxa é excedido, a API ou o serviço normalmente responde com códigos de status HTTP e cabeçalhos específicos.

Código de status HTTP 429 Too Many Requests

O código de status HTTP padrão para limitação de taxa é 429 Too Many Requests. Ele indica que o usuário enviou requisições demais em um determinado intervalo de tempo.

HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json

{
  "error": "Rate limit exceeded. Try again in 30 seconds."
}

Cabeçalhos de resposta

As APIs costumam incluir cabeçalhos específicos que fornecem mais contexto sobre o estado do limite de taxa e sobre como lidar com ele.

• Retry-After: (RFC 7231, Seção 7.1.3) indica quanto tempo o user agent deve aguardar antes de enviar uma nova requisição. O valor pode ser um inteiro representando segundos ou uma data/hora específica.
• X-RateLimit-Limit: o número máximo de requisições permitidas na janela atual do limite de taxa.
• X-RateLimit-Remaining: o número de requisições restantes na janela atual do limite de taxa.
• X-RateLimit-Reset: o momento (normalmente em segundos do epoch Unix) em que a janela atual do limite de taxa é reiniciada.

Esses cabeçalhos X-RateLimit-* são comuns, mas não são padronizados por nenhuma RFC; o nome exato e o comportamento podem variar entre serviços.

Como lidar com limites de taxa

Um tratamento eficaz dos limites de taxa no lado do cliente é essencial para construir aplicações robustas que interagem com serviços externos.

Backoff exponencial com jitter

Esta é a estratégia padrão para repetir requisições que falharam, inclusive as bloqueadas por limitação de taxa.

1. Backoff exponencial: o cliente aguarda um intervalo de tempo que cresce exponencialmente entre as tentativas (por exemplo, 1 segundo, depois 2 segundos, depois 4 segundos, depois 8 segundos).
2. Jitter: um pequeno atraso aleatório é somado ao período de backoff. Isso evita que todos os clientes tentem novamente ao mesmo tempo após o reset do limite, o que poderia disparar outra onda de limitação de taxa.

import time
import random
import requests

def make_request_with_retry(url, max_retries=5):
    retries = 0
    while retries < max_retries:
        try:
            response = requests.get(url)
            if response.status_code == 429:
                retry_after = int(response.headers.get('Retry-After', 1))
                print(f"Rate limited. Retrying after {retry_after} seconds.")
                time.sleep(retry_after)
            elif 200 <= response.status_code < 300:
                return response
            else:
                response.raise_for_status() # Lança uma exceção para outros erros HTTP
        except requests.exceptions.RequestException as e:
            print(f"Request failed: {e}")

        # Backoff exponencial com jitter
        delay = (2 ** retries) + random.uniform(0, 1) # 2^retries + float aleatório entre 0 e 1
        print(f"Retrying in {delay:.2f} seconds...")
        time.sleep(delay)
        retries += 1

    raise Exception(f"Failed to make request after {max_retries} retries.")

# Exemplo de uso:
# response = make_request_with_retry("https://api.example.com/data")
# if response:
#     print("Request successful:", response.json())

Respeite o cabeçalho Retry-After

Se a API fornecer o cabeçalho Retry-After, os clientes devem obedecer a essa diretiva. O valor especifica o tempo mínimo de espera antes de enviar outra requisição ao mesmo endpoint.

Cache no lado do cliente

Armazene em cache as respostas de endpoints acessados com frequência e pouco voláteis. Isso reduz o número de requisições enviadas à API e ajuda indiretamente a permanecer dentro dos limites de taxa.

Agrupamento de requisições

Se a API permitir, combine várias operações menores em uma única requisição maior. Isso reduz o número total de chamadas à API.

Throttling preditivo

Os clientes podem monitorar a própria taxa de requisições e reduzir ou pausar proativamente o envio ao se aproximarem dos limites conhecidos, em vez de esperar por uma resposta 429. Para isso, é preciso conhecer os limites de taxa da API de antemão.

Configuração do serviço de proxy para limitação de taxa

Um serviço de proxy robusto oferece recursos abrangentes para gerenciar limites de taxa, tanto para os clientes que acessam serviços através do proxy quanto para as próprias interações do proxy com APIs upstream.

Aplicação de limites ao tráfego de entrada

O proxy pode aplicar limites de taxa às requisições recebidas dos clientes com base em diversos critérios.

• Endereço IP do cliente: limita as requisições vindas de um único IP.
• Chave/token de API: limita as requisições associadas a uma credencial de autenticação específica.
• ID do usuário: quando o proxy consegue extrair informações do usuário a partir de cabeçalhos ou tokens.
• Caminho/endpoint: limites de taxa diferentes para endpoints diferentes da API (por exemplo, /search pode ter um limite maior que /admin/delete).

# Exemplo: configuração de proxy para limitação de taxa por IP
http:
  routers:
    api-router:
      rule: "Host(`api.example.com`)"
      service: api-service
      middlewares: [rate-limit-ip]
  middlewares:
    rate-limit-ip:
      rateLimit:
        average: 100 # requisições por segundo
        burst: 50    # rajada máxima acima da média
        sourceCriterion: "ipStrategy" # aplica o limite por IP de origem

Gerenciamento do tráfego de saída para serviços upstream

Quando o próprio proxy consome APIs upstream, ele pode implementar sua própria limitação de taxa para não sobrecarregar esses serviços externos. Isso é crítico em cenários de integração nos quais o proxy agrega dados de várias fontes.

• Limites por upstream: configure limites de taxa distintos para cada serviço upstream com o qual o proxy se comunica.
• Circuit breaking: combine a limitação de taxa com padrões de circuit breaker para isolar falhas quando um serviço upstream ficar indisponível ou limitar o proxy de forma persistente.

Personalização e granularidade

Configurações avançadas de proxy permitem controle refinado sobre a limitação de taxa:

• Limites dinâmicos: ajuste os limites conforme a saúde do backend, o horário do dia ou outras métricas operacionais.
• Limites por nível: implemente limites diferentes para diferentes níveis de cliente (por exemplo, usuários gratuitos vs. premium).
• Gestão de cotas: acompanhe o uso em relação a cotas de prazo mais longo (por exemplo, requisições por mês), além dos limites de curto prazo.

Monitoramento e alertas

Um serviço de proxy deve fornecer ferramentas para monitorar as estatísticas de limitação de taxa:

• Contagem de requisições: acompanhe o total de requisições, as bem-sucedidas e as bloqueadas por limite de taxa.
• Violações de limite: alerte quando os limites estiverem sendo alcançados ou excedidos para clientes ou serviços upstream específicos.
• Tendências de uso: visualize os padrões de requisição ao longo do tempo para identificar possíveis gargalos ou abusos.

O monitoramento ajuda as equipes de operações a entender os padrões de tráfego, otimizar as configurações de limite de taxa e resolver problemas de forma proativa, antes que afetem a disponibilidade do serviço.