-
Notifications
You must be signed in to change notification settings - Fork 69
/
Copy path_index.md
112 lines (87 loc) · 6.41 KB
/
_index.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
---
title: "Rate Limiting"
description: ""
---
{{% tts %}} supports rate limiting for all outward facing services. Access to each resource is limited by a unique identifier key, and it is possible to define rate limiting classes for fine-grained control.
<!--more-->
For more details about the algorithm used, read [here](https://en.wikipedia.org/wiki/Generic_cell_rate_algorithm).
## Example configuration
The rate limiting configuration is split into multiple profiles. For each profile, we provide a name, the maximum allowed rate per minute, and optionally a maximum burst rate. Finally, we associate the profile with a number of rate limiting classes. Refer to the [Rate Limited Entities]({{< ref "#rate-limited-entities" >}}) section below for a list of all available rate limiting classes and what they mean.
Enable rate limiting by adding the following configuration to your `ttn-lw-stack.yml`.
The values shown below are only meant as an example. Make sure to adjust them accordingly, depending on the actual traffic of your deployment.
```yaml
rate-limiting:
profiles:
- name: HTTP servers
max-per-min: 30
associations:
- http
- name: User login
max-per-min: 10
associations:
- http:account
- name: Create new users
max-per-min: 10
associations:
- grpc:method:/ttn.lorawan.v3.UserRegistry/Create
- name: Application downlink traffic
max-per-min: 10
associations:
- as:down:web
- as:down:mqtt
- grpc:method:/ttn.v3.lorawan.v3.AppAs/DownlinkQueuePush
- grpc:method:/ttn.v3.lorawan.v3.AppAs/DownlinkQueueReplace
- name: Gateway connections
max-per-min: 5
associations:
- gs:accept:mqtt
- gs:accept:ws
- grpc:stream:accept:/ttn.lorawan.v3.GtwGs/LinkGateway
- name: gRPC API
max-per-min: 60
associations:
- grpc:method
- grpc:stream:accept
- name: Override rate for uplink simulation
max-per-min: 5
associations:
- grpc:method:/ttn.lorawan.v3.AppAs/SimulateUplink
- name: Gateway uplink traffic
max-per-min: 1000
max-burst: 1500
associations:
- gs:up
```
## Rate Limited Entities
This section lists resources of {{% tts %}} on which a maximum rate limit can be enforced.
{{< rate-limiting >}}
{{< note >}} Both gRPC methods and HTTP endpoints support multiple classes. This enables overriding the generic rate limits for specific methods and endpoints. {{</ note >}}
{{< warning >}} When {{% tts %}} HTTP and gRPC endpoints are served behind a reverse proxy, the `X-Forwarded-For` header is respected for the remote IP. The IP address of the reverse proxy must be trusted by {{% tts %}} for this to work, see [HTTP options]({{< ref "/reference/configuration/the-things-stack#http-options" >}}) and [gRPC Options]({{< ref "/reference/configuration/the-things-stack#grpc-options" >}}). {{</ warning >}}
{{< warning >}} When {{% tts %}} MQTT and UDP endpoints are served by a reverse proxy, the remote IP address seen by {{% tts %}} may not be correct. In this case, rate limiting for new MQTT connections (and UDP traffic) should be handled by the reverse proxy and disabled in {{% tts %}}. {{</ warning >}}
## Rate Limiting Actions
The following table describes how {{% tts %}} reacts when the maximum rate limit for a resource is exceeded.
| Resource | Rate Limit Action | Expected Client Action |
| --------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| gRPC Requests | Return an error response of type `ResourceExhausted`, and set rate limiting headers. | The client should wait and then retry the gRPC request. The `X-Rate-Limit-Retry` header from the response can help in this case. |
| HTTP Requests | Return an `HTTP 429 (Too Many Requests)` error response, and set rate limiting headers. | The client should wait and then retry the HTTP request. The `X-Rate-Limit-Retry` header from the response can help in this case. |
| New MQTT Connections | Drop (reject) new connection. | The client should reconnect with a backoff. |
| UDP packets | Drop packet. | The client has no way of knowing whether the sent packet was received and/or processed, which is a limitation of the Legacy UDP packet forwarder. |
| Application Downlinks | Reject downlink message and terminate connection. | The client should reconnect, and reduce the downlink traffic load. |
| Gateway Uplinks | Reject uplink message and terminate connection. | The client should reconnect, and reduce the downlink traffic load. |
## Rate Limiting Headers
When rate limiting is enabled, the following headers are added to all HTTP and gRPC requests:
- `X-Rate-Limit-Limit`: The maximum number of allowed requests for the current time period.
- `X-Rate-Limit-Available`: Number of available requests for the current time period.
- `X-Rate-Limit-Reset`: Seconds until the rate limiter resets.
- `X-Rate-Limit-Retry`: Seconds the client should wait before retrying the request.
## Rate limiting providers
The default rate limiting provider for {{% tts %}} is `memory`. When using this provider the state of rate limiting is stored locally on each instance. The drawback of using it is inconsistent rate limiting state. The `redis` provider eliminates this problem by storing a shared rate limiting state for all instances.
| Provider | State |
| -------- | ------------ |
| `memory` | per instance |
| `redis` | shared |
To enable `redis` rate limiting provider you can set it in rate limiting configuration.
```yaml
rate-limiting:
provider: `redis`
```