Какво е Rate Limiting? Ръководство на прост език за строители на приложения

Rate limiting е правило, което ограничава колко заявки може да направи някой към дадена система за определено време — например 5 опита за вход в минута или 100 API заявки на час. Щом лимитът бъде достигнат, по-нататъшните заявки се отхвърлят (обикновено с код за грешка 429 Too Many Requests), докато прозорецът от време се нулира. Той защитава приложенията от злоупотреба, не позволява един натоварен потребител да забавя всички останали и спира неконтролируемите разходи.

Срещаш rate limiting от две страни: услугите, които ти извикваш, ограничават теб, а твоето собствено приложение трябва да ограничава своите потребители.

Защо rate limiting има значение, когато строиш с AI

Приложенията, построени с AI, често се свързват с платени услуги — AI модели, имейл, SMS, карти — и всяко извикване струва пари. Затова rate limiting е едновременно функция за сигурност и функция за бюджета.

• Контрол на разходите. Ако приложението ти има поле „попитай AI“ и няма лимит, бот може да му изпрати хиляди заявки за една нощ. Плащаш за всяка една.
• Сигурност. Без лимит във формата за вход атакуващ може да пробва хиляди пароли към един акаунт. Лимит от няколко опита в минута прави това непрактично.
• Оставане онлайн. Един неправилно работещ скрипт — понякога собственият ти код, заседнал в цикъл — може да претовари базата данни и да свали приложението.
• Спазване на лимитите на други услуги. Когато приложението ти вика външно API твърде често, ти получаваш грешките 429 и функциите се чупят за потребителите ти.

AI builder-ите ще построят каквото поискаш. Ако не споменеш лимити, те често липсват.

Ежедневна аналогия

Представи си политиката за безплатно допълване в кафене: „Едно безплатно допълване на клиент на посещение.“

• Не пречи на никого да се наслаждава на кафето си.
• Пречи на един човек да стои на тезгяха цял ден и да допълва термос за целия офис.
• Когато някой поиска четвърто допълване, бариста учтиво казва „не сега“ — това е 429.

Добрият лимит е невидим за нормалните клиенти и се забелязва само от някого, който прави нещо необичайно.

Как работи rate limiting

За ограничител на заявки са нужни три неща:

Когато пристигне заявка, приложението проверява броя за този „кой“. Под лимита: заявката минава и броят расте. Над лимита: заявката се отхвърля.

Има няколко чести начина за броене:

Броячите трябва да се пазят някъде бързо и споделено. На един малък сървър паметта върши работа. Когато приложението работи на няколко машини, броячът обикновено живее в споделено хранилище като Redis или базата данни, иначе всяка машина брои отделно и реалният лимит става няколко пъти по-висок.

Как изглежда отговор с ограничение

Когато заявката е над лимита, добре направеният API отговаря с:

• Статус код 429 Too Many Requests.
• Често заглавие Retry-After, което казва колко секунди да се изчака.
• Понякога заглавия, които показват лимита ти и колко заявки са останали в този прозорец (имената варират според доставчика).

Приложението ти трябва да отговори на 429, като изчака и опита по-късно — за предпочитане с експоненциално отстъпване (exponential backoff), което означава да се изчаква малко по-дълго след всеки неуспешен опит (1 секунда, после 2, после 4), вместо да се засипва услугата.

Работен пример: AI асистент за писане

Да кажем, че си построил приложение, в което потребителите поставят текст и получават AI пренаписване.

Без лимити: някой пише скрипт, който изпраща 20 000 заявки за една нощ. Сметката ти към AI доставчика скача и акаунтът ти достига собствения лимит на доставчика, така че реалните потребители виждат грешки цяла сутрин.

С разумни лимити:

1. По вписан потребител: 30 пренаписвания на час в безплатния план, 300 в платения. Над лимита потребителят вижда: „Достигнахте лимита за този час. Опитайте отново след 12 минути или надградете.“
2. По IP адрес във формата за регистрация: 5 регистрации на час, за да се спрат ботовете, които създават хиляди безплатни акаунта, за да заобиколят лимита по потребител.
3. Таван на разходите, зададен в таблото на AI доставчика, като последна линия на защита, ако всичко друго се провали.
4. Справяне с лимитите на доставчика: ако AI доставчикът върне 429, сървърът ти чака и опитва отново един-два пъти, после показва приятелско съобщение „заето е, опитайте пак“.

Лимитите се проверяват на сървъра. Лимит, който съществува само в браузъра — например деактивиране на бутона след 30 клика — може да бъде заобиколен от всеки, който извиква API-то ти директно.

Ключови термини

Чести заблуди

• „Rate limiting е само за големи приложения.“ Малките приложения също са мишени, защото ботовете сканират целия интернет за отворени формуляри и AI крайни точки. Цената на злоупотребата не зависи от размера ти.
• „Достатъчно е да скриеш бутона.“ Лимитите от страна на браузъра са любезност, а не защита. Реалните лимити трябва да се налагат на сървъра.
• „Лимитите по IP са винаги справедливи.“ Много хора могат да споделят един IP адрес — офис, училище, мобилна мрежа. Лимитите по потребител са по-справедливи, след като хората са влезли в акаунтите си.
• „429 означава, че услугата е счупена.“ Означава, че я викаш твърде често. Провери кода си за цикли и кеширай резултати, които не се променят често — виж какво е кеширане.
• „Rate limiting замества таван на разходите.“ Ползвай и двете. Лимитите в приложението могат да имат грешки; таванът на разходите при доставчика е твоята резервна мрежа.

Какво да поискаш от AI builder

• „Добави rate limiting от страна на сървъра за вход, регистрация, възстановяване на парола и AI крайната точка. Предложи разумни лимити.“
• „Ограничи всеки вписан потребител до [N] AI заявки на час и показвай ясно съобщение с времето за изчакване, когато достигне лимита.“
• „Когато външно API върне 429, опитай отново с експоненциално отстъпване до 3 пъти, после покажи приятелска грешка.“
• „Къде се пазят броячите на rate limit? Ще работят ли, ако приложението върви на повече от една машина?“
• „Записвай всеки път, когато потребител или IP достигне лимит, за да мога да откривам злоупотреби.“
• „Кои външни услуги вика това приложение и какви са техните лимити?“

Rate limiting в Mythex

Документацията на Mythex е пряка по този въпрос за AI функциите: лимитите, безопасността и контролът на разходите в приложенията, които строиш, са твоя отговорност — виж Създаване на AI приложение. Помоли агента да добави лимити в същото съобщение, в което искаш функцията. В Pro публикувана услуга може да работи на до три машини при голям трафик (виж Лимити на хостинга), затова поискай броячите да живеят в базата данни, а не в паметта на един сървър.

Свързани четива: какво е API, как да използваш LLM API-та и контролния списък за сигурност за приложения, построени с AI.

Въпроси