Основы дизайна систем: защита выходных точек (Endpoint Protection)

Когда вы строите крупномасштабные системы, становится важным защитить вашу систему от слишком большого количества операций, когда такие операции фактически не нужны для использования системы. Это звучит очень абстрактно. Но подумайте об этом - сколько раз вы яростно нажимали кнопку, думая, что это сделает систему более отзывчивой? Представьте, если бы каждое из этих нажатий кнопки отправляло пинг на сервер, и сервер пытался обработать их все! Если пропускная способность системы по какой-то причине низкая (скажем, сервер испытывал необычную нагрузку), то каждый из этих щелчков делал бы систему еще медленнее, потому что ей приходилось обрабатывать их все!

Иногда дело даже не в защите системы. Иногда вы хотите ограничить операции, потому что это часть вашей службы. Например, вы могли использовать бесплатные уровни для сторонних служб API, где вам разрешено делать только 20 запросов за 30-минутный интервал. Если вы сделаете 21 или 300 запросов в 30-минутном интервале, после первых 20, этот сервер перестанет обрабатывать ваши запросы.

Это называется ограничением скорости (rate-limiting). Используя ограничение скорости, сервер может ограничить количество операций, предпринимаемых клиентом в заданный промежуток времени. Предел скорости может быть рассчитан для пользователей, запросов, времени, полезной нагрузки или других вещей. Обычно при превышении лимита во временном окне для оставшейся части этого окна сервер возвращает ошибку.

Хорошо, теперь вы можете подумать, что «защита» конечных точек - это преувеличение. Вы просто ограничиваете возможность пользователей получить что-то из конечной точки. Верно, но это также защита, когда пользователь (клиент) является злоумышленником, например, ботом, который разбивает вашу конечную точку. Почему так могло случиться? Потому что заполнение сервера большим количеством запросов, чем он может обработать, - это стратегия, используемая злоумышленниками для остановки этого сервера, что фактически приводит к остановке этой службы. Именно это и есть атака отказа в обслуживании (DoS, Denial-of-Service).

Хотя таким образом можно защитить от DoS-атак, ограничение скорости само по себе не защитит вас от сложной версии DoS-атаки - распределенной DoS-атаки. Здесь распределенная просто означает, что атака исходит от нескольких клиентов, которые кажутся не связанными друг с другом, и нет реального способа идентифицировать их как контролируемых одним вредоносным агентом. Для защиты от таких скоординированных распределенных атак необходимо использовать другие методы.

Но ограничение скорости в любом случае полезно и популярно для менее пугающих случаев использования, таких как ограничение API. Учитывая, как работает ограничение скорости, поскольку сервер должен сначала проверить условия ограничения и при необходимости обеспечить их соблюдение, вам нужно подумать о том, какую структуру данных и базу данных вы хотите использовать, чтобы сделать эти проверки сверхбыстрыми, чтобы вы не замедляли обработку запроса, если он находится в допустимых пределах. Кроме того, если у вас есть это в памяти на самом сервере, вы должны иметь возможность гарантировать, что все запросы от данного клиента будут приходить на этот сервер, чтобы он мог должным образом применять ограничения. Для обработки подобных ситуаций часто используется отдельная служба Redis, которая находится вне сервера, но хранит данные пользователя в памяти и может быстро определить, находится ли пользователь в допустимых пределах.

Ограничение скорости может быть таким же сложным, как и правила, которые вы хотите обеспечить.

---

Читайте также:

• Основы дизайна систем: базы данных
• Основы дизайна систем: выборы лидера
• Основы дизайна систем: опрос, потоковая передача, сокеты