Çfarë është rate limiting-u? Udhëzues i thjeshtë për ndërtuesit e aplikacioneve
Rate limiting-u është një rregull që kufizon sa kërkesa mund të bëjë dikush drejt një sistemi brenda një kohe të caktuar — për shembull, 5 përpjekje hyrjeje në minutë, ose 100 thirrje API në orë. Kur arrihet kufiri, kërkesat e tjera refuzohen (zakonisht me kodin e gabimit 429 Too Many Requests) derisa dritarja kohore të rifillojë. Mbron aplikacionet nga abuzimi, ndalon që një përdorues i rëndë të ngadalësojë gjithçka për të tjerët dhe parandalon kostot e pakontrolluara.
Rate limiting-un e takon nga dy anë: shërbimet që thërret të kufizojnë ty, dhe aplikacioni yt duhet të kufizojë përdoruesit e vet.
Pse ka rëndësi rate limiting-u kur ndërton me AI
Aplikacionet e ndërtuara me AI shpesh lidhen me shërbime të paguara — modele AI, email, SMS, harta — dhe çdo thirrje kushton para. Kjo e bën rate limiting-un si një veçori sigurie ashtu edhe një veçori buxheti.
- Kontroll i kostove. Nëse aplikacioni yt ka një kuti “pyet AI” dhe nuk ka kufi, një bot mund të dërgojë mijëra kërkesa gjatë natës. Paguan për secilën.
- Siguria. Pa kufi te formulari i hyrjes, një sulmues mund të provojë mijëra fjalëkalime ndaj një llogarie. Një kufi prej disa përpjekjesh në minutë e bën këtë të pamundur.
- Të mbetesh online. Një skript i keq — ndonjëherë kodi yt i bllokuar në një lak — mund ta mbingarkojë bazën e të dhënave dhe ta rrëzojë aplikacionin.
- Respektimi i kufijve të shërbimeve të tjera. Kur aplikacioni yt thërret një API të jashtme shumë shpesh, ti merr gabimet 429, dhe veçoritë prishen për përdoruesit e tu.
Ndërtuesit me AI do të ndërtojnë atë që kërkon. Nëse nuk përmend kufij, shpesh ata lihen jashtë.
Një analogji e përditshme
Mendo politikën e rimbushjes falas të një kafeterie: “Një rimbushje falas për klient për vizitë.”
- Nuk e pengon askënd të shijojë kafenë.
- Pengon një person të qëndrojë te banaku gjithë ditën duke rimbushur një termos për gjithë zyrën.
- Kur dikush kërkon një rimbushje të katërt, kamarieri thotë me kujdes “jo tani” — ky është
429-ja.
Një kufi i mirë rate limiting është i padukshëm për klientët normalë dhe vihet re vetëm nga dikush që bën diçka të pazakontë.
Si funksionon rate limiting-u
Një rate limiter ka nevojë për tre gjëra:
| Pjesa | Pyetja që përgjigjet | Shembuj |
|---|---|---|
| Kush | Kujt kërkesat po numërohen? | Llogaria e përdoruesit, adresa IP, çelësi API |
| Sa | Sa është kufiri? | 5, 60, 1,000 kërkesa |
| Për sa kohë | Brenda cilës dritare? | Për sekondë, minutë, orë, ditë |
Kur arrin një kërkesë, aplikacioni kontrollon numërimin për atë “kush”. Nën kufi: kërkesa kalon dhe numërimi rritet. Mbi kufi: kërkesa refuzohet.
Janë disa mënyra të zakonshme numërimi:
| Metoda | Si funksionon | Kompromisi |
|---|---|---|
| Dritare fikse | Numërimi rifillon sipas orës — p.sh. çdo minutë në minutë | E thjeshtë, por lejon një shpërthim në kufirin e dy dritareve |
| Dritare rrëshqitëse | Shikon 60 sekondat e fundit nga tani | Më e qetë, pak më shumë punë për llogaritjen |
| Token bucket | Çdo përdorues ka një kovë që mbushet me ritëm të qëndrueshëm; çdo kërkesë merr një token | Lejon shpërthime të shkurtra duke mbajtur mesataren të qëndrueshme |
Numërimet duhet të ruhen diku të shpejtë dhe të përbashkët. Në një server të vetëm të vogël, memoria mjafton. Sapo aplikacioni të ekzekutohet në disa makina, numëruesi zakonisht jeton në një depozitim të përbashkët si Redis ose baza e të dhënave; përndryshe çdo makinë numëron veçmas dhe kufiri real bëhet disa herë më i lartë.
Si duket një përgjigje e kufizuar nga rate limiting
Kur një kërkesë është mbi kufi, një API e mirë përgjigjet me:
- Kodin e statusit
429 Too Many Requests. - Shpesh një header
Retry-After, që tregon sa sekonda të presësh. - Ndonjëherë header-a që tregojnë kufirin tënd dhe sa kërkesa të kanë mbetur në këtë dritare (emrat ndryshojnë sipas ofruesit).
Aplikacioni yt duhet të përgjigjet ndaj një 429 duke pritur dhe duke provuar përsëri më vonë — mundësisht me exponential backoff, që do të thotë të presësh pak më gjatë pas çdo përpjekjeje të dështuar (1 sekondë, pastaj 2, pastaj 4) në vend që ta bombardosh shërbimin.
Një shembull i punuar: një asistent shkrimi me AI
Të themi se ke ndërtuar një aplikacion ku përdoruesit ngjisin tekst dhe marrin një rishkrim me AI.
Pa kufi: dikush shkruan një skript që dërgon 20,000 kërkesa gjatë natës. Fatura e ofruesit të AI-së rritet, dhe llogaria jote arrin kufirin e vet të ofruesit, kështu që përdoruesit e vërtetë shohin gabime gjatë gjithë mëngjesit.
Me kufij të arsyeshëm:
- Për çdo përdorues të kyçur: 30 rishkrime në orë në planin falas, 300 në ato të paguara. Mbi kufi, përdoruesi sheh: “Ke arritur kufirin e kësaj ore. Provo përsëri pas 12 minutash, ose përmirëso planin.”
- Për adresë IP te formulari i regjistrimit: 5 regjistrime në orë, për të ndaluar botët nga krijimi i mijëra llogarive falas për të anashkaluar kufirin për përdorues.
- Një kufi shpenzimesh i vendosur në panelin e ofruesit të AI-së, si mbrojtja e fundit nëse gjithçka tjetër dështon.
- Trajtimi i kufijve të ofruesit: nëse ofruesi i AI-së kthen 429, serveri yt pret dhe provon përsëri një ose dy herë, pastaj shfaq një mesazh miqësor “i zënë, provo përsëri”.
Kufijtë kontrollohen në server. Një kufi që ekziston vetëm në shfletues — për shembull, çaktivizimi i butonit pas 30 klikimeve — mund të anashkalohet nga kushdo që thërret API-n tënde drejtpërdrejt.
Termat kryesorë
| Termi | Kuptimi |
|---|---|
| Rate limit | Numri maksimal i kërkesave të lejuara në një dritare kohore. |
| Kuota | Një shpërndarje më e madhe, shpesh për ditë ose muaj, ndonjëherë e lidhur me një plan të paguar. |
| 429 | Kodi i statusit HTTP për “shumë kërkesa”. |
| Retry-After | Header përgjigjeje që tregon sa të presësh para se të provosh përsëri. |
| Throttling | Ngadalësimi ose refuzimi i kërkesave mbi kufi. Shpesh përdoret si sinonim. |
| Exponential backoff | Pritja gjithnjë e më gjatë midis provave të përsëritura. |
| Burst | Një shpërthim i shkurtër i shumë kërkesave njëherësh. |
| Brute-force attack | Provimi i sasive të mëdha fjalëkalimesh ose kodesh deri sa njëri të funksionojë. |
Keqkuptime të zakonshme
- “Rate limiting-u është vetëm për aplikacionet e mëdha.” Aplikacionet e vogla janë edhe ato objektiva, sepse botët skanojnë gjithë internetin për formularë dhe endpoint-e AI të hapura. Kostoja e abuzimit nuk varet nga madhësia jote.
- “Mjafton të fshihet butoni.” Kufijtë në shfletues janë mirësjellje, jo mbrojtje. Kufijtë e vërtetë duhet të zbatohen në server.
- “Kufijtë për IP janë gjithmonë të drejtë.” Shumë njerëz mund të ndajnë një adresë IP — një zyrë, një shkollë, një rrjet celular. Kufijtë për përdorues janë më të drejtë sapo njerëzit kyçen.
- “429 do të thotë se shërbimi është i prishur.” Do të thotë se e thërret shumë shpesh. Kontrollo kodin për lakje dhe ruaj në memorje rezultatet që nuk ndryshojnë shpesh — shiko çfarë është caching-u.
- “Rate limiting-u zëvendëson kufirin e shpenzimeve.” Përdori të dyja. Kufijtë në aplikacion mund të kenë gabime; kufiri i shpenzimeve të ofruesit është rrjeta jote e fundit.
Çfarë t’i kërkosh ndërtuesit tënd të AI-së
- “Shto rate limiting në server për hyrjen, regjistrimin, rivendosjen e fjalëkalimit dhe endpoint-in e AI-së. Sugjero kufij të arsyeshëm.”
- “Kufizo çdo përdorues të kyçur në [N] kërkesa AI në orë, dhe shfaq një mesazh të qartë me kohën e pritjes kur arrin kufirin.”
- “Kur një API e jashtme kthen 429, provo përsëri me exponential backoff deri në 3 herë, pastaj shfaq një gabim miqësor.”
- “Ku ruhen numëruesit e rate limit-it? A do të punojnë akoma nëse aplikacioni ekzekutohet në më shumë se një makinë?”
- “Regjistro sa herë një përdorues ose IP arrin një kufi, që të mund të zbuloj abuzimet.”
- “Cilat shërbime të jashtme thërret ky aplikacion, dhe cilët janë kufijtë e tyre?”
Rate limiting-u në Mythex
Dokumentacioni i Mythex është i drejtpërdrejtë për këtë për veçoritë AI: kufijtë e rate limit-it, sigurimi dhe kontrolli i kostove në aplikacionet që ndërton janë në dorën tënde — shiko Ndërto një aplikacion AI. Kërko agjentit të shtojë kufij në të njëjtin mesazh ku kërkon veçorinë. Në Pro, një shërbim i publikuar mund të ekzekutohet në deri tre makina kur trafiku është i lartë (shiko Kufijtë e hostimit), kështu që kërko numërues që jetojnë në bazën e të dhënave e jo në memorien e një serveri.
Leximi i lidhur: çfarë është një API, si të përdorësh API-t e LLM dhe lista e sigurisë për aplikacionet e ndërtuara me AI.
Pyetje
Çfarë është rate limiting-u me fjalë të thjeshta?
Rate limiting-u është një rregull që kufizon sa kërkesa mund të bëjë një përdorues, pajisje ose aplikacion brenda një periudhe të caktuar — për shembull, 5 përpjekje hyrjeje në minutë ose 100 thirrje API në orë. Kërkesat mbi kufi refuzohen derisa dritarja të rifillojë.
Çfarë do të thotë një gabim 429 Too Many Requests?
Statusi HTTP 429 do të thotë se ke dërguar shumë kërkesa në një kohë shumë të shkurtër dhe ke arritur një kufi rate limit. Përgjigja shpesh përfshin një header Retry-After që tregon sa të presësh. Zgjidhja është të ngadalësosh, të provosh përsëri pas një pauze, ose të zvogëlosh sa shpesh aplikacioni thërret shërbimin.
Pse ka nevojë aplikacioni im me AI për rate limiting?
Çdo kërkesë AI kushton para në token. Pa kufi, një përdorues ose një bot mund të dërgojë mijëra kërkesa dhe të krijojë një faturë të madhe ose të shterojë kuotën e ofruesit, duke e çaktivizuar veçorinë për të gjithë. Kufijtë për përdorues e mbajnë koston të parashikueshme.
A është rate limiting-u i njëjtë me throttling-un?
Janë shumë të lidhura dhe shpesh përdoren në vend të njëra-tjetrës. Rate limiting-u zakonisht do të thotë refuzimi i kërkesave mbi kufi, ndërsa throttling-u mund të thotë edhe ngadalësimi ose vendosja e tyre në radhë në vend që të refuzohen menjëherë.
A e ndalon rate limiting-u sulmet DDoS?
Ndihmon kundër përmbytjeve të vogla dhe abuzimeve nga përdorues ose adresa IP individuale, por një sulm i madh i shpërndarë vjen nga shumë adresa njëherësh. Mbrojtja nga ato zakonisht ndodh në nivelin e rrjetit ose CDN-së, përpara se trafiku të arrijë aplikacionin tënd.