Kas ir pieprasījumu ierobežošana? Vienkāršs ceļvedis lietotņu veidotājiem

Rate limiting ir noteikums, kas ierobežo, cik pieprasījumus kāds var nosūtīt sistēmai noteiktā laika periodā — piemēram, 5 pieteikšanās mēģinājumus minūtē vai 100 API izsaukumus stundā. Kad limits ir sasniegts, turpmākie pieprasījumi tiek noraidīti (parasti ar kļūdas kodu 429 Too Many Requests), līdz laika logs tiek atiestatīts. Tas aizsargā lietotnes no ļaunprātīgas izmantošanas, neļauj vienam smagam lietotājam palēnināt darbu visiem un novērš neapturamas izmaksas.

Ar rate limiting saskaraties divos virzienos: pakalpojumi, kurus jūs izsaucat, ierobežo jūs, un jūsu pati lietotne jāierobežo tās lietotājus.

Kāpēc rate limiting ir svarīgs, veidojot ar MI

MI veidotās lietotnes bieži savienojas ar maksas pakalpojumiem — MI modeļiem, e-pastu, SMS, kartēm — un katrs izsaukums maksā naudu. Tādēļ rate limiting ir gan drošības, gan budžeta funkcija.

• Izmaksu kontrole. Ja jūsu lietotnē ir lauks „pajautāt MI” bez ierobežojuma, robots var nosūtīt tam tūkstošiem pieprasījumu pār nakti. Jūs maksājat par katru no tiem.
• Drošība. Bez ierobežojuma pieteikšanās veidlapā uzbrucējs var izmēģināt tūkstošiem paroļu vienam kontam. Ierobežojums dažiem mēģinājumiem minūtē to padara nepraktisku.
• Palikt tiešsaistē. Viens nekorekti strādājošs skripts — dažreiz pat jūsu pašu kods, kas iestrēdzis cilpā — var pārslogot datu bāzi un apturēt lietotni.
• Ievērot citu pakalpojumu ierobežojumus. Ja jūsu lietotne ārēju API izsauc pārāk bieži, jūs saņemat 429 kļūdas, un funkcijas jūsu lietotājiem pārtrūkst.

MI veidotāji uzbūvēs to, ko pieprasāt. Ja neminēsiet ierobežojumus, tie bieži vien tiek izlaisti.

Ikdienas salīdzinājums

Iedomājieties kafejnīcas bezmaksas papildinājuma politiku: „Viens bezmaksas papildinājums vienam klientam vienā apmeklējumā.”

• Tā neliedz nevienam baudīt kafiju.
• Tā neļauj vienam cilvēkam visu dienu stāvēt pie letes un papildināt termosu visam birojam.
• Kad kāds lūdz ceturto papildinājumu, bārmenis pieklājīgi saka „ne šobrīd” — tas ir tas 429.

Labs ierobežojums ir neredzams parastiem klientiem un pamanāms tikai tam, kurš dara kaut ko neparastu.

Kā darbojas rate limiting

Rate limiter-am vajag trīs lietas:

Kad pieprasījums ienāk, lietotne pārbauda skaitu šim „kas”. Zem limita: pieprasījums tiek izpildīts un skaits palielinās. Virs limita: pieprasījums tiek noraidīts.

Ir vairāki parasti skaitīšanas veidi:

Skaitītājiem jābūt glabātiem ātrā un kopīgā vietā. Vienā mazā serverī pietiek ar atmiņu. Kad lietotne darbojas uz vairākām mašīnām, skaitītājs parasti atrodas kopīgā krātuvē, piemēram, Redis vai datu bāzē, citādi katra mašīna skaita atsevišķi un patiesais limits kļūst vairākas reizes lielāks.

Kā izskatās atbilde ar ierobežojumu

Kad pieprasījums ir virs limita, labi uzvesties API atbild ar:

• statusa kodu 429 Too Many Requests;
• bieži Retry-After galveni, kas norāda, cik sekundes jāgaida;
• dažreiz galvenēm, kas parāda jūsu limitu un to, cik pieprasījumu atlicis šajā logā (nosaukumi atšķiras atkarībā no pakalpojumu sniedzēja).

Jūsu lietotnei uz 429 jāreaģē, gaidot un vēlāk mēģinot vēlreiz — ideālā gadījumā ar eksponenciālu atkāpšanos (exponential backoff), kas nozīmē katrā neveiksmīgā mēģinājumā gaidīt nedaudz ilgāk (1 sekunde, tad 2, tad 4), nevis bombardēt pakalpojumu.

Darba piemērs: MI rakstīšanas palīgs

Pieņemsim, ka esat izveidojis lietotni, kurā lietotāji ielīmē tekstu un saņem MI pārrakstījumu.

Bez ierobežojumiem: kāds raksta skriptu, kas pār nakti nosūta 20 000 pieprasījumu. Jūsu MI pakalpojumu sniedzēja rēķins strauji pieaug, un jūsu konts sasniedz paša pakalpojumu sniedzēja ierobežojumu, tāpēc reāli lietotāji visu rītu redz kļūdas.

Ar saprātīgiem ierobežojumiem:

1. Katram pieteiktam lietotājam: 30 pārrakstījumi stundā bezmaksas plānā, 300 maksas plānā. Virs limita lietotājs redz: „Jūs esat sasniedzis šīs stundas limitu. Mēģiniet vēlreiz pēc 12 minūtēm vai jauniniet plānu.”
2. Pa IP adresi reģistrācijas veidlapā: 5 reģistrācijas stundā, lai novērstu robotus, kas izveido tūkstošiem bezmaksas kontu, lai apietu limitu katram lietotājam.
3. Tēriņu limits, kas iestatīts MI pakalpojumu sniedzēja panelī, kā pēdējā aizsardzības līnija, ja viss pārējais neizdodas.
4. Pakalpojumu sniedzēja ierobežojumu apstrāde: ja MI pakalpojumu sniedzējs atgriež 429, jūsu serveris vienu vai divas reizes gaida un mēģina vēlreiz, pēc tam parāda draudzīgu ziņojumu „aizņemts, lūdzu, mēģiniet vēlreiz”.

Limitus pārbauda serverī. Limits, kas eksistē tikai pārlūkprogrammā — piemēram, pogas atspējošana pēc 30 klikšķiem —, var apiet ikviens, kas izsauc jūsu API tieši.

Galvenie termini

Biežākie nepareizi priekšstati

• „Rate limiting ir tikai lielām lietotnēm.” Mazas lietotnes arī ir mērķi, jo roboti skenē visu internetu meklējot atvērtas veidlapas un MI galapunktus. Ļaunprātīgas izmantošanas izmaksas nav atkarīgas no jūsu lieluma.
• „Pietiek paslēpt pogu.” Ierobežojumi pārlūkprogrammā ir pieklājība, nevis aizsardzība. Īstie ierobežojumi jāpiemēro serverī.
• „Ierobežojumi pa IP ir vienmēr taisnīgi.” Daudzi cilvēki var dalīties vienā IP adresē — birojs, skola, mobilais tīkls. Ierobežojumi pa lietotāju ir taisnīgāki, kad cilvēki ir pieteikušies.
• „429 nozīmē, ka pakalpojums ir bojāts.” Tas nozīmē, ka to izsaucat pārāk bieži. Pārbaudiet kodu, vai nav cilpu, un kešojiet rezultātus, kas nemainās bieži — skatiet kas ir kešatmiņa.
• „Rate limiting aizstāj tēriņu limitu.” Izmantojiet abus. Ierobežojumiem lietotnē var būt kļūdas; pakalpojumu sniedzēja tēriņu limits ir jūsu pēdējā aizsardzība.

Ko prasīt no sava MI veidotāja

• „Pievieno servera puses rate limiting pieteikšanās, reģistrācijas, paroles atjaunošanas un MI galapunktam. Iesaki saprātīgus limitus.”
• „Ierobežo katru pieteikto lietotāju līdz [N] MI pieprasījumiem stundā un, kad limits sasniegts, parādi skaidru ziņu ar gaidīšanas laiku.”
• „Kad ārējais API atgriež 429, mēģini vēlreiz ar eksponenciālu atkāpšanos līdz 3 reizēm un tad parādi draudzīgu kļūdu.”
• „Kur tiek glabāti ierobežojumu skaitītāji? Vai tie joprojām darbosies, ja lietotne darbosies uz vairākām mašīnām?”
• „Reģistrē katru reizi, kad lietotājs vai IP sasniedz limitu, lai es varētu pamanīt ļaunprātīgu izmantošanu.”
• „Kuri ārējie pakalpojumi šī lietotne izsauc un kādi ir to rate limit?”

Rate limiting Mythex

Mythex dokumentācija šajā jautājumā par MI funkcijām ir tieša: rate limit, drošības un izmaksu kontroles lietotnēs, ko veidojat, ir jūsu pašu uzdevums — skatiet MI lietotnes veidošana. Lūdziet aģentam pievienot ierobežojumus tajā pašā ziņojumā, kurā pieprasāt funkciju. Pro plānā publicēts pakalpojums smagas datplūsmas gadījumā var darboties līdz trim mašīnām (skatiet Hosting limits), tāpēc lūdziet skaitītājus, kas glabājas datu bāzē, nevis vienā servera atmiņā.

Saistītie raksti: kas ir API, kā lietot LLM API un drošības kontrolsaraksts MI veidotām lietotnēm.

Jautājumi