Rate limiting (limitação de taxa) é uma técnica de segurança e controle de tráfego que restringe o número de requisições que um usuário, IP ou aplicação pode fazer a uma API dentro de um período de tempo específico. Ele atua como um gargalo intencional para evitar sobrecargas de servidor, bloquear ataques de negação de serviço (DDoS) e garantir que os recursos do sistema sejam distribuídos de forma justa entre todos os clientes.
Principais Aprendizados
- O rate limiting previne a exaustão de recursos e protege contra ataques maliciosos como DDoS e força bruta.
- Quando o limite é atingido, a API retorna o status code HTTP 429 (Too Many Requests).
- Existem diferentes algoritmos para implementá-lo, sendo o Token Bucket e o Leaky Bucket os mais utilizados pela indústria.
Como o Rate Limiting Funciona na Prática?
Para entender a limitação de taxa, primeiro é preciso compreender o que é uma API: uma ponte que permite que sistemas conversem. Quando você expõe essa ponte para a internet, qualquer pessoa ou robô pode tentar atravessá-la milhões de vezes por segundo. O rate limiting funciona como um pedágio inteligente que conta quantos carros (requisições) de uma mesma placa (IP ou Token) passaram no último minuto.
Se um cliente exceder a cota permitida (por exemplo, mais de 100 requisições por minuto), o servidor rejeitará as conexões subsequentes até que a janela de tempo seja reiniciada. Essa validação geralmente ocorre antes mesmo da requisição chegar ao banco de dados, sendo processada por um API Gateway ou por um proxy reverso.
O papel do Status Code 429
Quando o limite é ultrapassado, o servidor não simplesmente ignora o usuário silenciosamente. Ele responde utilizando um dos status codes HTTP específicos para esse cenário. Conforme definido pela IETF na RFC 6585, o código oficial para limitação de taxa é o 429 Too Many Requests.
Junto com esse código, uma boa API costuma enviar cabeçalhos HTTP adicionais, como o X-RateLimit-Limit (limite total), X-RateLimit-Remaining (quantas requisições restam) e o X-RateLimit-Reset (quando o limite será zerado). Isso permite que a aplicação cliente pause suas requisições automaticamente.
Por Que Sua API Precisa de Rate Limiting?
A falta de limitação de taxa não é apenas um problema de performance, é uma falha crítica de segurança. A OWASP (Open Worldwide Application Security Project), maior autoridade global em segurança de aplicações, classifica o consumo irrestrito de recursos (API4:2023) como uma das 10 maiores vulnerabilidades de APIs no mundo.
Prevenção contra Ataques de Força Bruta e DDoS
Sem limites, um invasor pode criar um script para testar milhões de combinações de senhas na sua rota de login (força bruta) ou inundar seu servidor com requisições pesadas até que ele trave (DDoS). O rate limiting mitiga isso exigindo pausas. Frequentemente, um analista de SOC utiliza os logs gerados por esses bloqueios para identificar e banir IPs maliciosos permanentemente.
Controle de Custos em Infraestrutura Cloud
Na era da computação em nuvem (AWS, Azure, Google Cloud), você paga pelo processamento e pela banda que consome. Se uma API pública não tiver limites, um erro no código de um cliente (como um loop infinito fazendo chamadas) pode gerar uma conta de milhares de dólares no fim do mês. O rate limiting garante previsibilidade financeira.
Principais Algoritmos de Limitação de Taxa
Existem diferentes lógicas matemáticas para aplicar esses limites. A escolha do algoritmo afeta diretamente a experiência do usuário e o consumo de memória do servidor.
Token Bucket e Leaky Bucket
O Token Bucket (Balde de Fichas) é o algoritmo mais comum. Imagine um balde que armazena fichas. A cada segundo, novas fichas são adicionadas. Cada requisição consome uma ficha. Se o balde esvaziar, as requisições são bloqueadas. Ele permite pequenos picos repentinos de tráfego (bursts), desde que haja fichas acumuladas.
Já o Leaky Bucket (Balde Furado) funciona como uma fila com taxa de saída constante. As requisições entram no balde e vazam pelo fundo em uma velocidade fixa. Se a água (requisições) entrar mais rápido do que vaza, o balde transborda e as novas requisições são descartadas. É ideal para proteger bancos de dados que só aguentam um volume estrito de operações por segundo.
Fixed Window vs Sliding Window
A Fixed Window (Janela Fixa) reseta o contador em intervalos exatos (ex: no minuto 12:00, depois no 12:01). O problema é que um usuário pode fazer 100 requisições às 12:00:59 e mais 100 às 12:01:01, sobrecarregando o servidor em apenas dois segundos. Para corrigir isso, usa-se a Sliding Window Log (Janela Deslizante), que avalia o tempo exato das últimas requisições nos últimos 60 segundos contínuos, oferecendo um controle muito mais preciso, embora consuma mais memória.
Perguntas Frequentes
O que significa o erro HTTP 429?
O erro HTTP 429 significa 'Too Many Requests' (Muitas Requisições). Ele é retornado pelo servidor quando o usuário enviou mais requisições do que o permitido pelas regras de rate limiting em um determinado período de tempo.
Qual a diferença entre Rate Limiting e Throttling?
Embora usados como sinônimos, o rate limiting geralmente bloqueia completamente o acesso (retornando erro 429) quando o limite é atingido. Já o throttling reduz intencionalmente a velocidade da conexão ou a prioridade do usuário, permitindo que a requisição seja processada, mas de forma muito mais lenta.
Onde o Rate Limiting deve ser implementado?
A melhor prática é implementá-lo na borda da rede (Edge), utilizando serviços de CDN, WAF (Web Application Firewall) ou em um API Gateway. Implementar rate limiting diretamente no código da aplicação consome recursos desnecessários do servidor de aplicação.
0 Comentários