💻️️️️️️ Rate Limiting в ASP.NET Core: четыре алгоритма, которые ограничивают нагрузку по-разному.
Антон Мартынюк разобрал их с примерами на C# и сценариями применения.
Fixed Window – фиксированное окно
Например, 100 запросов за минуту. После сброса счётчика лимит доступен заново. Подвох: 100 запросов перед границей окна и ещё 100 сразу после могут пройти почти одновременно.
Sliding Window – скользящее окно
Делит окно на сегменты и постепенно освобождает использованные разрешения. Сглаживает всплески на границах окон; точность зависит от размера сегментов.
Token Bucket – корзина токенов
Каждый запрос расходует токен, запас регулярно пополняется. Позволяет отдельно настроить размер допустимого всплеска и устойчивую интенсивность запросов.
Concurrency Limiter – ограничение параллельности
Например, не больше пяти одновременно выполняющихся экспортов. Новое разрешение появляется после завершения запроса. Число последовательных запросов в минуту этот алгоритм не ограничивает.
В статье есть и практические ловушки:
- Именованная политика сама по себе не создаёт отдельный лимит каждому клиенту. Нужны разделы по IP, пользователю или API-ключу.
- За reverse proxy необходимо корректно настроить доверенные forwarded headers.
- Счётчики хранятся в памяти процесса. Несколько экземпляров приложения не получают общий лимит автоматически.
- Ответ 429 и обработку Retry-After нужно настроить явно.
«Ускорь этот C#-код» — полезнее просить ИИ вместе с инструкцией, как измерять результат.
BlazingFastDotnet — сборник приёмов оптимизации .NET 10 и 11, упакованный в SKILL.md для ИИ-агентов. Его можно читать и как обычный технический справочник.
Внутри:
- Поиск узких мест: dotnet-counters, dotnet-trace, Linux perf и анализ машинного кода JIT.
- Память и многопоточность: аллокации, GC, конкуренция за блокировки и false sharing.
- Настройка выполнения: ThreadPool, сокеты, JIT и параметры NativeAOT.
- Оптимизация C#: SIMD, работа со строками и ASP.NET Core.
Автор предлагает подключать документ по необходимости, когда появилась конкретная задача ускорения.
Порядок работы простой: замерить исходную производительность → найти причину → менять по одному параметру → сохранять только измеримый выигрыш.
Часть рекомендаций рассчитана прежде всего на бенчмарки. Настройки могут обменивать память на скорость или увеличивать нагрузку на CPU, поэтому переносить их в продакшен стоит после проверки на своей нагрузке.
🔐 «Не одобряй собственные расходы» — такое правило нужно проверять на сервере
Тайсир Джуде показывает, как защитить MCP-сервер на ASP.NET Core через Microsoft Entra ID.
На примере приложения для учёта расходов автор разбирает:
• Регистрацию сервера и клиента в Entra ID.
• Вход пользователя и проверку JWT-токенов.
• Разницу между scope - разрешением приложению действовать от имени пользователя — и ролью, позволяющей одобрять расходы.
• Ограничение доступа к отдельным MCP-инструментам и фильтрацию списка доступных tools.
Самый показательный момент: пользователь с ролью согласующего может одобрить чужой отчёт, но свой сервер отклонит. Личность определяется по токену, а бизнес-правило проверяется в коде.
Модель выбирает, какой инструмент вызвать. Сервер решает, разрешено ли выполнить действие.
🗓 29 ноября в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «C#-разработчик. Продвинутый уровень».
Разберем, как браузер общается с сервером, и создадим работающий HTTP-сервис без Spring и сторонних библиотек.
О чем поговорим:
✔️ Как связаны понятия асинхронности и многопоточности
✔️ Синтаксис async/await-конструкций
✔️ Во что компилируется конструкция async/await
✔️ Работа с исключениями при ожидании
🔗 Ссылка на регистрацию: https://otus.pw/DCX1/?erid=2W5zFJeppAM
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
⚡ Где тормозит .NET-приложение? SharpLsp покажет прямо в VS Code
В SharpLsp есть встроенный профилировщик CPU и памяти для C# и F#. Подключаешься к уже работающему процессу и смотришь, на что приложение тратит ресурсы. Перезапускать и пересобирать его не нужно.
После сбора CPU-профиля расширение подсвечивает горячие строки кода, строит flame graph и показывает функции, которые занимают больше всего процессорного времени.
Для памяти доступны отслеживание кучи, сравнение снимков и граф ссылок, помогающий понять, что удерживает объекты в памяти. Подозреваемые на утечки отображаются по мере работы приложения.
Отдельно устанавливать `dotnet-trace` не требуется. Движку профилировщика нужен runtime .NET 8 или новее, а у целевого процесса должна быть включена диагностика.
Проект открытый, под лицензией MIT, работает на Windows, macOS и Linux.