Mi az a sebességkorlátozás? Közérthető útmutató alkalmazás-építőknek

A sebességkorlátozás egy szabály, amely megszabja, hány kérést küldhet valaki egy rendszernek meghatározott idő alatt – például percenként 5 bejelentkezési kísérletet vagy óránként 100 API-hívást. Ha eléri a korlátot, a további kéréseket addig utasítják el (általában a 429 Too Many Requests hibakóddal), amíg az időablak újra nem indul. Védi az alkalmazásokat a visszaélésektől, megakadályozza, hogy egy nagy igénybevételű felhasználó mindenki számára lassítsa a dolgokat, és megállítja a kontrollálatlan költségeket.

A sebességkorlátozással kétféleképpen találkozhatsz: a te által hívott szolgáltatások korlátozzák téged, a saját alkalmazásodnak pedig a felhasználóit kellene korlátoznia.

Miért fontos a sebességkorlátozás, ha AI-val építkezel

Az AI-val épített alkalmazások gyakran fizetős szolgáltatásokhoz kapcsolódnak – AI-modellekhez, e-mailhez, SMS-hez, térképekhez –, és minden hívás pénzbe kerül. Ezért a sebességkorlátozás egyszerre biztonsági és költségvetési funkció.

• Költségkontroll. Ha az alkalmazásodban van egy „kérdezd meg az AI-t” mező, korlát nélkül egy bot egy éjszaka alatt ezer kérést küldhet. Minden egyes kérésért fizetsz.
• Biztonság. A bejelentkező űrlap korlátja nélkül egy támadó ezer jelszót kipróbálhat egy fiókon. Néhány kísérlet percenként ezt gyakorlatilag lehetetlenné teszi.
• Online maradás. Egyetlen hibás szkript – néha a saját kódod, amely végtelen ciklusba ragadt – túlterhelheti az adatbázisodat, és leállíthatja az alkalmazást.
• Mások korlátainak tiszteletben tartása. Ha az alkalmazásod túl gyakran hív egy külső API-t, te kapod a 429-es hibákat, és a funkciók elromlanak a felhasználóidnak.

Az AI-építők azt építik meg, amit kérsz. Ha nem említesz korlátokat, azok gyakran kimaradnak.

Hétköznapi hasonlat

Gondolj egy kávézó ingyenes utántöltési szabályára: „Vendégenként egy ingyenes utántöltés látogatásonként.”

• Nem akadályozza meg, hogy valaki élvezze a kávéját.
• Megakadályozza, hogy valaki egész nap a pultnál álljon, és az egész iroda számára töltögessen egy termoszba.
• Amikor valaki negyedik utántöltést kér, a barista udvariasan azt mondja: „most nem” – ez a 429.

A jó sebességkorlát a normál vásárlók számára észrevehetetlen, és csak az figyeli fel, aki szokatlan dolgot csinál.

Hogyan működik a sebességkorlátozás

A sebességkorlátozónak három dologra van szüksége:

Amikor kérés érkezik, az alkalmazás ellenőrzi az adott „kire” vonatkozó számlálót. A korlát alatt: a kérés átmegy, és a számláló nő. A korláton túl: a kérést elutasítják.

Néhány gyakori számlálási mód:

A számlálókat gyors, megosztott helyen kell tárolni. Egyetlen kis szerveren a memória elég. Ha az alkalmazás több gépen fut, a számláló általában megosztott tárolóban él, például Redisben vagy az adatbázisban, különben minden gép külön számol, és a tényleges korlát többszörösére nő.

Hogyan néz ki a korlátozott válasz

Ha egy kérés a korláton túl van, egy rendesen működő API így válaszol:

• 429 Too Many Requests állapotkód.
• Gyakran Retry-After fejléc, amely megmondja, hány másodpercet kell várni.
• Néha olyan fejlécek, amelyek megmutatják a korlátodat és azt, hány kérésed maradt ebben az ablakban (a nevek szolgáltatónként eltérnek).

Az alkalmazásodnak a 429-re úgy kell reagálnia, hogy vár, és később újrapróbálkozik – ideális esetben exponenciális visszalépéssel (backoff), vagyis minden sikertelen próbálkozás után egy kicsit tovább vár (1 másodperc, aztán 2, aztán 4), ahelyett hogy szüntelenül bombázná a szolgáltatást.

Munkapélda: egy AI-alapú íróasszisztens

Tegyük fel, hogy olyan alkalmazást építettél, ahol a felhasználók szöveget illesztenek be, és AI-átírást kapnak.

Korlátok nélkül: valaki olyan szkriptet ír, amely egy éjszaka alatt 20 000 kérést küld. Az AI-szolgáltatód számlája megugrik, a fiókod eléri a szolgáltató saját sebességkorlátját, így a valódi felhasználók egész délelőtt hibákat látnak.

Ésszerű korlátokkal:

1. Bejelentkezett felhasználónként: 30 átírás óránként az ingyenes csomagban, 300 a fizetősben. A korláton túl a felhasználó ezt látja: „Elérted ennek az órának a korlátját. Próbáld újra 12 perc múlva, vagy frissíts csomagot.”
2. IP-címenként a regisztrációs űrlapon: 5 regisztráció óránként, hogy a botok ne hozhassanak létre ezer ingyenes fiókot a felhasználónkénti korlát megkerülésére.
3. Költési limit az AI-szolgáltatód irányítópultján, utolsó védvonalként, ha minden más meghibásodik.
4. A szolgáltató korlátainak kezelése: ha az AI-szolgáltató 429-et küld, a szervered egy-két alkalommal vár és újrapróbálkozik, majd barátságos „foglalt, kérjük, próbáld újra” üzenetet mutat.

A korlátokat a szerveren ellenőrizd. Egy korlát, amely csak a böngészőben létezik – például a gomb letiltása 30 kattintás után –, bárki megkerülheti, aki közvetlenül hívja az API-dat.

Kulcsfogalmak

Gyakori tévhitek

• „A sebességkorlátozás csak nagy alkalmazásoknak kell.” A kis alkalmazások is célpontok, mert a botok az egész interneten nyitott űrlapokat és AI-végpontokat keresnek. A visszaélés költsége nem függ az alkalmazás méretétől.
• „Elég elrejteni a gombot.” A böngészőoldali korlátok udvariasságok, nem védelmek. A valódi korlátokat a szerveren kell érvényesíteni.
• „Az IP-alapú korlátok mindig igazságosak.” Sokan osztoznak egy IP-címen – egy irodában, iskolában vagy mobilhálózaton. A felhasználónkénti korlátok bejelentkezett embereknél igazságosabbak.
• „A 429 azt jelenti, hogy a szolgáltatás hibás.” Azt jelenti, hogy túl gyakran hívod. Nézd át a kódot ciklusok után, és gyorsítótárazd azokat az eredményeket, amelyek ritkán változnak – lásd: mi az a gyorsítótárazás.
• „A sebességkorlátozás helyettesíti a költési limitet.” Használd mindkettőt. Az alkalmazásodban lévő korlátokban lehetnek hibák; a szolgáltató költési limitje a végső biztosíték.

Mit kérj az AI-építődtől

• „Adj szerveroldali sebességkorlátozást a bejelentkezéshez, regisztrációhoz, jelszó-visszaállításhoz és az AI-végponthoz. Javasolj ésszerű korlátokat.”
• „Minden bejelentkezett felhasználót korlátozz [N] AI-kérésre óránként, és ha eléri, mutass egyértelmű üzenetet a várakozási idővel.”
• „Ha egy külső API 429-et ad, próbáld újra exponenciális visszalépéssel legfeljebb 3-szor, majd mutass barátságos hibaüzenetet.”
• „Hol tárolódnak a sebességkorlát-számlálók? Működnek majd, ha az alkalmazás több gépen fut?”
• „Naplózd, valahányszor egy felhasználó vagy IP eléri a korlátot, hogy észrevegyem a visszaéléseket.”
• „Mely külső szolgáltatásokat hívja ez az alkalmazás, és mik a sebességkorlátaik?”

Sebességkorlátozás a Mythexben

A Mythex dokumentációja egyenesen fogalmaz ezzel kapcsolatban az AI-funkciókra vonatkozóan: a sebességkorlátok, a biztonsági és költségkontrollok az általad épített alkalmazásokban a te feladatod a megtervezésük – lásd: AI-alkalmazás építése. Kérd az ügynöktől a korlátokat ugyanabban az üzenetben, amelyben a funkciót kéred. Pro csomagban egy közzétett szolgáltatás nagy forgalom esetén akár három gépen is futhat (lásd: Tárhelykorlátok), ezért kérj olyan számlálókat, amelyek az adatbázisban élnek, nem egyetlen szerver memóriájában.

Kapcsolódó olvasnivaló: mi az az API, hogyan használj LLM API-kat és az AI-val épített alkalmazások biztonsági ellenőrzőlistája.

Kérdések