All Projects → mholt → caddy-ratelimit

mholt / caddy-ratelimit

Licence: Apache-2.0 License
HTTP rate limiting module for Caddy 2

Programming Languages

go
31211 projects - #10 most used programming language

Projects that are alternatives of or similar to caddy-ratelimit

caddy-json-schema
JSON schema generator for Caddy v2
Stars: ✭ 63 (-12.5%)
Mutual labels:  caddy, caddy-module
caddygit
Git module for Caddy v2
Stars: ✭ 67 (-6.94%)
Mutual labels:  caddy, caddy-module
souin
An HTTP cache system, RFC compliant, compatible with @TykTechnologies, @traefik, @caddyserver, @go-chi, @bnkamalesh, @beego, @devfeel, @labstack, @gofiber, @go-goyave, @gin-gonic, @zalando, @zeromicro, @nginx and @apache
Stars: ✭ 269 (+273.61%)
Mutual labels:  caddy, caddy-module
caddy-authorize
Authorization Plugin for Caddy v2 (JWT/PASETO)
Stars: ✭ 235 (+226.39%)
Mutual labels:  caddy, caddy-module
caddy-exec
Caddy v2 module for running one-off commands
Stars: ✭ 48 (-33.33%)
Mutual labels:  caddy, caddy-module
c2ray step by step
一步一步教你安装 c2ray 服务端(caddy+v2ray)
Stars: ✭ 13 (-81.94%)
Mutual labels:  caddy
yii2-ratelimiter-advanced
Advanced Rate Limiter is a Yii2 filter to enforce or monitor request rate limits.
Stars: ✭ 23 (-68.06%)
Mutual labels:  rate-limiting
throttle
Erlang/OTP application to rate limit resource access
Stars: ✭ 40 (-44.44%)
Mutual labels:  rate-limiting
limitrr-php
Better PHP rate limiting using Redis.
Stars: ✭ 19 (-73.61%)
Mutual labels:  rate-limiting
pandora
Small box of pandora to prototype your app with ready for use backend. This is just my compilation of different solutions occasionally applied in hackathons and challenges
Stars: ✭ 26 (-63.89%)
Mutual labels:  caddy
aiolimiter
An efficient implementation of a rate limiter for asyncio.
Stars: ✭ 121 (+68.06%)
Mutual labels:  rate-limiting
WCMP
WCMP是基于Windows x64平台下的Caddy2 + PHP + MySQL便携软件包。
Stars: ✭ 17 (-76.39%)
Mutual labels:  caddy
pi-hole-cloudflared-docker-compose-ansible-caddy
Example configuration for using Pi-Hole, Cloudflared, Docker Compose, Ansible, and Caddy to over-engineer your home network for privacy and security.
Stars: ✭ 97 (+34.72%)
Mutual labels:  caddy
phi
an api-gateway based on openresty
Stars: ✭ 23 (-68.06%)
Mutual labels:  rate-limiting
caddy-docker
Generate Caddy configuration on-the-fly from currently running Docker containers
Stars: ✭ 72 (+0%)
Mutual labels:  caddy
Huddy
Huddy = Hugo + Caddy docker container
Stars: ✭ 14 (-80.56%)
Mutual labels:  caddy
jarvis
🍿 Simple Home Media Stack
Stars: ✭ 28 (-61.11%)
Mutual labels:  caddy
limio
A rate limiting library for Go centered around intuitive and idiomatic interfaces, and designed to limit silly window syndrome.
Stars: ✭ 51 (-29.17%)
Mutual labels:  rate-limiting
throttle
Throttling Middleware for Martini
Stars: ✭ 63 (-12.5%)
Mutual labels:  rate-limiting
perseverance
Make your functions 💪 resilient and 🚥 fail-fast to 💩 failures or ⌚ delays
Stars: ✭ 12 (-83.33%)
Mutual labels:  rate-limiting

Caddy HTTP Rate Limit Module

This module implements both internal and distributed HTTP rate limiting. Requests can be rejected after a specified rate limit is hit.

WORK IN PROGRESS: Please note that this module is still unfinished and may have bugs. Please try it out and file bug reports - thanks!

Features

  • Multiple rate limit zones
  • Sliding window algorithm
  • Scalable ring buffer implementation
    • Buffer pooling
    • Goroutines: 1 (to clean up old buffers)
    • Memory O(Kn) where:
      • K = events allowed in window (constant, configurable)
      • n = number of rate limits allocated in zone (configured by zone key; constant or dynamic)
  • RL state persisted through config reloads
  • Automatically sets Retry-After header
  • Optional jitter for retry times
  • Configurable memory management
  • Distributed rate limiting across a cluster
  • Caddyfile support

PLANNED:

  • Ability to define matchers in zones with Caddyfile
  • Smoothed estimates of distributed rate limiting
  • RL state persisted in storage for resuming after restarts
  • Admin API endpoints to inspect or modify rate limits

Building

To build Caddy with this module, use xcaddy:

$ xcaddy build --with github.com/mholt/caddy-ratelimit

Overview

The rate_limit HTTP handler module lets you define rate limit zones, which have a unique name of your choosing. A rate limit zone is 1:1 with a rate limit (i.e. events per duration).

A zone also has a key, which is different from its name. Keys associate 1:1 with rate limiters, implemented as ring buffers; i.e. a new key implies allocating a new ring buffer. Keys can be static (no placeholders; same for every request), in which case only one rate limiter will be allocated for the whole zone. Or, keys can contain placeholders which can be different for every request, in which case a zone may contain numerous rate limiters depending on the result of expanding the key.

A zone is synomymous with a rate limit, being a number of events per duration. Both window and max_events are required configuration for a zone. For example: 100 events every 1 minute. Because this module uses a sliding window algorithm, it works by looking back <window> duration and seeing if <max_events> events have already happened in that timeframe. If so, an internal HTTP 429 error is generated and returned, invoking error routes which you have defined (if any). Otherwise, the a reservation is made and the event is allowed through.

Each zone may optionally filter the requests it applies to by specifying request matchers.

Unlike nginx's rate limit module, this one does not require you to set a memory bound. Instead, rate limiters are scanned every so often and expired ones are deleted so their memory can be recovered by the garbage collector: Caddy does not drop rate limiters on the floor and forget events like nginx does.

Distributed rate limiting

With a little bit more CPU, I/O, and a teensy bit more memory overhead, this module distributes its rate limit state across a cluster. A cluster is simply defined as other rate limit modules that are configured to use the same storage.

Distributed RL works by periodically writing its internal RL state to storage, while also periodically reading other instances' RL state from storage, then accounting for their states when making allowance decisions. In order for this to work, all instances in the cluster must have the exact same RL zone configurations.

This synchronization algorithm is inherently approximate, but also eventually consistent (and is similar to what other enterprise-only rate limiters do). Its performance depends heavily on parameter tuning (e.g. how often to read and write), configured rate limit windows and event maximums, and performance characteristics of the underlying storage implementation. (It will be fairly heavy on reads, but writes will be lighter, even if more frequent.)

Syntax

This is an HTTP handler module, so it can be used wherever http.handlers modules are accepted.

JSON config

{
	"handler": "rate_limit",
	"rate_limits": {
		"<name>": {
			"match": [],
			"key": "",
			"window": "",
			"max_events": 0
		},
		"distributed": {
			"write_interval": "",
			"read_interval": ""
		},
		"storage": {},
		"jitter": 0.0,
		"sweep_interval": ""
	}
}

All fields are optional, but to be useful, you'll need to define at least one zone, and a zone requires window and max_events to be set. Keys can be static (no placeholders) or dynamic (with placeholders). Matchers can be used to filter requests that apply to a zone. Replace <name> with your RL zone's name.

To enable distributed RL, set distributed to a non-null object. The default read and write intervals are 5s, but you should tune these for your individual deployments.

Storage customizes the storage module that is used. Like normal Caddy convention, all instances with the same storage configuration are considered to be part of a cluster.

Jitter is an optional percentage that adds random variance to the Retry-After time to avoid stampeding herds.

Sweep interval configures how often to scan for expired rate limiters. The default is 1m.

Caddyfile config

As with all non-standard HTTP handler modules, this directive is not known to the Caddyfile adapter and so it must be "ordered" manually using global options unless it only appears within a route block. This ordering usually works well, but you should use discretion:

{
	order rate_limit before basicauth
}

Here is the syntax. See the JSON config section above for explanations about each property:

rate_limit {
	zone <name> {
		key    <string>
		window <duration>
		events <max_events>
	}
	distributed {
		read_interval  <duration>
		write_interval <duration>
	}
	storage <module...>
	jitter  <percent>
	sweep_interval <duration>
}

Like with the JSON config, all subdirectives are optional and have sensible defaults (but you will obviously want to specify at least one zone).

Multiple zones can be defined. Distributed RL can be enabled just by specifying distributed if you want to use its default settings.

Examples

We'll show an equivalent JSON and Caddyfile example that defines two rate limit zones: static_example and dynamic_example.

In the static_example zone, there is precisely one ring buffer allocated because the key is static (no placeholders), and we also demonstrate defining a matcher set to select which requests the rate limit applies to. Only 100 GET requests will be allowed through every minute, across all clients.

In the dynamic_example zone, the key is dynamic (has a placeholder), and in this case we're using the client's IP address ({http.request.remote.host}). We allow only 2 requests per client IP in the last 5 seconds from any given time.

We also enable distributed rate limiting. By deploying this config to two or more instances sharing the same storage module (which we did not define here, so Caddy's global storage config will be used), they will act approximately as one instance when making rate limiting decisions.

JSON example

{
	"apps": {
		"http": {
			"servers": {
				"demo": {
					"listen": [":80"],
					"routes": [
						{
							"handle": [
								{
									"handler": "rate_limit",
									"rate_limits": {
										"static_example": {
											"match": [
												{"method": ["GET"]}
											],
											"key": "static",
											"window": "1m",
											"max_events": 100
										},
										"dynamic_example": {
											"key": "{http.request.remote.host}",
											"window": "5s",
											"max_events": 2
										}
									},
									"distributed": {}
								},
								{
									"handler": "static_response",
									"body": "I'm behind the rate limiter!"
								}
							]
						}
					]
				}
			}
		}
	}
}

Caddyfile example

(The Caddyfile does not yet support defining matchers for RL zones, so that has been omitted from this example.)

{
	order rate_limit before basicauth
}

:80

rate_limit {
	distributed
	zone static_example {
		key    static
		events 100
		window 1m
	}
	zone dynamic_example {
		key    {remote_host}
		events 2
		window 5s
	}
}

respond "I'm behind the rate limiter!"
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].