محدودیت نرخ درخواست چیست؟ راهنمای ساده برای سازندگان اپلیکیشن
محدودیت نرخ قانونی است که تعداد درخواست‌هایی را که یک نفر می‌تواند در مدت مشخصی به یک سیستم بفرستد محدود می‌کند؛ مثلاً ۵ تلاش ورود در دقیقه، یا ۱۰۰ فراخوانی API در ساعت. وقتی به حد برسد، درخواست‌های بیشتر رد می‌شوند (معمولاً با کد خطای 429 Too Many Requests) تا بازه‌ی زمانی تمام شود. این قانون اپلیکیشن‌ها را در برابر سوءاستفاده محافظت می‌کند، نمی‌گذارد یک کاربر پرمصرف برای همه کند کند، و از هزینه‌های بی‌کنترل جلوگیری می‌کند.
محدودیت نرخ را از دو طرف می‌بینید: سرویس‌هایی که شما صدا می‌زنید شما را محدود می‌کنند، و اپلیکیشن خودتان باید کاربرانش را محدود کند.
چرا محدودیت نرخ وقتی با هوش مصنوعی می‌سازید مهم است
اپلیکیشن‌هایی که با هوش مصنوعی ساخته می‌شوند اغلب به سرویس‌های پولی وصل‌اند: مدل‌های هوش مصنوعی، ایمیل، پیامک، نقشه؛ و هر فراخوانی هزینه دارد. پس محدودیت نرخ هم یک ویژگی امنیتی است و هم یک ابزار کنترل بودجه.
- کنترل هزینه. اگر اپلیکیشن شما یک کادر «از هوش مصنوعی بپرس» دارد و هیچ محدودیتی ندارد، یک ربات می‌تواند شب‌ها هزاران درخواست به آن بفرستد. برای هر کدام پول می‌دهید.
- امنیت. بدون محدودیت روی فرم ورود، یک مهاجم می‌تواند هزاران رمز را روی یک حساب امتحان کند. محدودیت چند تلاش در دقیقه این کار را غیرعملی می‌کند.
- آنلاین ماندن. یک اسکریپت بد، و گاهی حتی کد خودتان که در یک حلقه گیر کرده، می‌تواند پایگاه داده را بار کند و اپلیکیشن را از کار بیندازد.
- رعایت محدودیت سرویس‌های دیگر. وقتی اپلیکیشن شما یک API بیرونی را خیلی زیاد صدا می‌زند، خطای 429 را شما می‌گیرید و قابلیت‌ها برای کاربرانتان خراب می‌شود.
سازندگان اپلیکیشن با هوش مصنوعی هر چیزی را که بخواهید می‌سازند. اگر حرفی از محدودیت نزنید، اغلب اصلاً ساخته نمی‌شود.
یک تشبیه روزمره
سیاست «یک بار شارژ مجانی در هر مراجعه» یک کافه را در نظر بگیرید.
- این سیاست جلوی لذت بردن کسی از قهوه را نمی‌گیرد.
- جلوی این را می‌گیرد که یک نفر تمام روز پشت پیشخوان بایستد و یک فلاسک برای کل دفتر کارش پر کند.
- وقتی کسی برای چهارمین بار شارژ بخواهد، باریستا مؤدبانه می‌گوید «فعلاً نه»؛ همان
429.
یک محدودیت نرخ خوب برای مشتری‌های معمولی نامرئی است و فقط کسی را می‌گیرد که کار غیرعادی می‌کند.
محدودیت نرخ چطور کار می‌کند
یک محدودکننده‌ی نرخ به سه چیز نیاز دارد:
| بخش | به چه سؤالی جواب می‌دهد | نمونه |
|---|---|---|
| چه کسی | درخواست‌های چه کسی شمرده می‌شود؟ | حساب کاربری، آدرس IP، کلید API |
| چقدر | حد چقدر است؟ | ۵، ۶۰، ۱۰۰۰ درخواست |
| در چه زمانی | در چه بازه‌ای؟ | ثانیه، دقیقه، ساعت، روز |
وقتی درخواستی می‌رسد، اپلیکیشن شمارش آن «چه کسی» را بررسی می‌کند. اگر زیر حد باشد، درخواست رد نمی‌شود و شمارش بالا می‌رود. اگر بالای حد باشد، درخواست رد می‌شود.
چند روش رایج شمارش وجود دارد:
| روش | چطور کار می‌کند | مصالحه |
|---|---|---|
| پنجره‌ی ثابت | شمارش سر ساعت ریست می‌شود، مثلاً هر دقیقه سر دقیقه | ساده، ولی در مرز دو پنجره اجازه‌ی انفجار کوتاه می‌دهد |
| پنجره‌ی لغزان | ۶۰ ثانیه‌ی آخر را از «الان» نگاه می‌کند | هموارتر، و محاسبه‌اش کمی سنگین‌تر است |
| سطل توکن (Token bucket) | هر کاربر یک سطل دارد که با سرعت ثابت پر می‌شود؛ هر درخواست یک توکن می‌گیرد | اجازه‌ی انفجارهای کوتاه می‌دهد و میانگین را ثابت نگه می‌دارد |
شمارش‌ها باید جایی سریع و مشترک ذخیره شوند. روی یک سرور کوچک، حافظه کافی است. وقتی اپلیکیشن روی چند ماشین اجرا شود، شمارنده معمولاً در یک ذخیره‌ی مشترک مثل Redis یا پایگاه داده قرار می‌گیرد؛ وگرنه هر ماشین جداگانه می‌شمارد و حد واقعی چند برابر بالاتر می‌رود.
پاسخ محدودشده چه شکلی است
وقتی درخواستی از حد گذشته باشد، یک API خوش‌رفتار این‌ها را برمی‌گرداند:
- کد وضعیت
429 Too Many Requests. - معمولاً یک هدر
Retry-Afterکه می‌گوید چند ثانیه باید صبر کنید. - گاهی هدرهایی که حد شما و تعداد درخواست‌های باقی‌مانده در این بازه را نشان می‌دهند (نام‌ها بین ارائه‌دهنده‌ها فرق دارد).
اپلیکیشن شما باید به 429 با صبر کردن و تلاش دوباره‌ی بعدی جواب دهد؛ بهتر است با backoff نمایی این کار را کند، یعنی بعد از هر تلاش ناموفق کمی بیشتر صبر کند (۱ ثانیه، بعد ۲، بعد ۴) به‌جای اینکه سرویس را بی‌وقفه بکوبد.
یک مثال کامل: یک دستیار نوشتن با هوش مصنوعی
فرض کنید اپلیکیشنی ساخته‌اید که کاربرها متن می‌چسبانند و یک بازنویسی با هوش مصنوعی می‌گیرند.
بدون محدودیت: یک نفر اسکریپتی می‌نویسد که شب ۲۰٬۰۰۰ درخواست بفرستد. صورتحساب ارائه‌دهنده‌ی هوش مصنوعی بالا می‌رود، و حساب شما به محدودیت نرخ خود ارائه‌دهنده می‌خورد، پس کاربران واقعی تمام صبح خطا می‌بینند.
با محدودیت‌های معقول:
- به‌ازای هر کاربر واردشده: ۳۰ بازنویسی در ساعت در پلن مجانی، ۳۰۰ در پلن پولی. بالای حد، کاربر می‌بیند: «به سقف این ساعت رسیده‌اید. ۱۲ دقیقه‌ی دیگر دوباره امتحان کنید، یا ارتقا دهید.»
- به‌ازای هر آدرس IP در فرم ثبت‌نام: ۵ ثبت‌نام در ساعت، تا ربات‌ها نتوانند هزاران حساب مجانی بسازند و از محدودیت کاربر عبور کنند.
- یک سقف هزینه در داشبورد ارائه‌دهنده‌ی هوش مصنوعی، به‌عنوان آخرین خط دفاع اگر همه‌چیز دیگر شکست بخورد.
- مدیریت محدودیت‌های ارائه‌دهنده: اگر ارائه‌دهنده‌ی هوش مصنوعی خطای 429 بدهد، سرور شما یک یا دو بار صبر و تلاش دوباره می‌کند، و بعد پیام دوستانه‌ی «مشغولیم، لطفاً دوباره امتحان کنید» را نشان می‌دهد.
محدودیت‌ها باید روی سرور بررسی شوند. محدودیتی که فقط در مرورگر وجود دارد، مثلاً غیرفعال کردن دکمه بعد از ۳۰ کلیک، توسط هر کسی که مستقیم API شما را صدا بزند قابل دور زدن است.
توضیح اصطلاحات کلیدی
| اصطلاح | معنی |
|---|---|
| محدودیت نرخ (Rate limit) | بیشترین تعداد درخواست مجاز در یک بازه‌ی زمانی. |
| سهمیه (Quota) | سهمیه‌ی بزرگ‌تر، اغلب روزانه یا ماهانه، و گاهی وابسته به پلن پولی. |
| 429 | کد وضعیت HTTP برای «درخواست‌های بیش از حد». |
| Retry-After | هدر پاسخی که می‌گوید قبل از تلاش دوباره چقدر باید صبر کرد. |
| Throttling | کند کردن یا رد کردن درخواست‌های بالای حد. اغلب به‌جای هم به کار می‌رود. |
| Exponential backoff | صبر کردن هر بار طولانی‌تر بین تلاش‌های دوباره. |
| انفجار (Burst) | یک اوج کوتاه با درخواست‌های زیاد همزمان. |
| حمله‌ی brute-force | امتحان کردن تعداد زیادی رمز یا کد تا یکی درست درآید. |
برداشت‌های غلط رایج
- «محدودیت نرخ فقط برای اپلیکیشن‌های بزرگ است.» اپلیکیشن‌های کوچک هم هدف‌اند، چون ربات‌ها کل اینترنت را برای فرم‌ها و endpointهای هوش مصنوعی بازخوانی می‌کنند. هزینه‌ی سوءاستفاده به اندازه‌ی شما بستگی ندارد.
- «پنهان کردن دکمه کافی است.» محدودیت در مرورگر یک لطف است، نه حفاظت. محدودیت واقعی باید روی سرور اجرا شود.
- «محدودیت بر اساس IP همیشه منصفانه است.» خیلی آدم می‌توانند یک آدرس IP را مشترک داشته باشند؛ یک دفتر، یک مدرسه، یا یک شبکه‌ی موبایل. وقتی افراد واردشده‌اند، محدودیت به‌ازای هر کاربر منصفانه‌تر است.
- «429 یعنی سرویس خراب است.» یعنی شما خیلی زیاد صدایش می‌زنید. کد خود را برای حلقه‌ها بررسی کنید، و نتایجی را که کم تغییر می‌کنند کش کنید؛ برای نمونه، کش چیست را ببینید.
- «محدودیت نرخ جای سقف هزینه را می‌گیرد.» هر دو را داشته باشید. محدودیت‌های داخل اپلیکیشن ممکن است باگ داشته باشند؛ سقف هزینه‌ی ارائه‌دهنده پشتیبان نهایی شماست.
از ابزار ساخت اپلیکیشنتان چه بخواهید
- «محدودیت نرخ سمت سرور را برای ورود، ثبت‌نام، بازیابی رمز و endpoint هوش مصنوعی اضافه کن. محدودیت‌های معقول پیشنهاد بده.»
- «هر کاربر واردشده را به [N] درخواست هوش مصنوعی در ساعت محدود کن، و وقتی به حد رسید، پیام واضح با زمان انتظار نشان بده.»
- «وقتی یک API بیرونی 429 برگرداند، تا ۳ بار با backoff نمایی دوباره تلاش کن، و بعد یک خطای دوستانه نشان بده.»
- «شمارنده‌های محدودیت کجا ذخیره می‌شوند؟ اگر اپلیکیشن روی بیش از یک ماشین اجرا شود، هنوز کار می‌کنند؟»
- «هر وقت کاربر یا IPای به حد می‌رسد ثبت کن، تا سوءاستفاده را ببینم.»
- «این اپلیکیشن کدام سرویس‌های بیرونی را صدا می‌زند و محدودیت نرخ هر کدام چقدر است؟»
محدودیت نرخ در Mythex
مستندات Mythex برای قابلیت‌های هوش مصنوعی صریح است: محدودیت نرخ، ایمنی و کنترل هزینه در اپلیکیشن‌هایی که می‌سازید با خودتان است؛ به ساخت اپلیکیشن هوش مصنوعی مراجعه کنید. محدودیت‌ها را همان پیامی که قابلیت را درخواست می‌کنید از عامل بخواهید. در پلن Pro، یک سرویس منتشرشده وقتی ترافیک زیاد است می‌تواند روی حداکثر سه ماشین اجرا شود (ببینید محدودیت‌های میزبانی)، پس شمارنده‌هایی بخواهید که در پایگاه داده نگه داشته شوند، نه در حافظه‌ی یک سرور.
مطالب مرتبط: API چیست، چطور از LLM APIها استفاده کنیم و چک‌لیست امنیتی برای اپلیکیشن‌های ساخته‌شده با هوش مصنوعی.
پرسش‌ها
محدودیت نرخ به زبان ساده چیست؟
محدودیت نرخ قانونی است که تعداد درخواست‌هایی را که یک کاربر، دستگاه یا برنامه می‌تواند در یک بازه‌ی زمانی بفرستد محدود می‌کند؛ مثلاً ۵ تلاش ورود در دقیقه یا ۱۰۰ فراخوانی API در ساعت. درخواست‌هایی که از حد بگذرند، تا پایان بازه رد می‌شوند.
خطای 429 Too Many Requests یعنی چه؟
کد وضعیت HTTP ۴۲۹ یعنی در زمان خیلی کوتاه درخواست زیادی فرستاده‌اید و به یک محدودیت نرخ رسیده‌اید. پاسخ اغلب یک هدر Retry-After دارد که می‌گوید چقدر باید صبر کنید. راه‌حل این است که آهسته‌تر شوید، بعد از مکثی دوباره تلاش کنید، یا دفعات فراخوانی سرویس را کم کنید.
چرا اپلیکیشن مبتنی بر هوش مصنوعی من به محدودیت نرخ نیاز دارد؟
هر درخواست هوش مصنوعی با توکن هزینه دارد. بدون محدودیت، یک کاربر یا یک ربات می‌تواند هزاران درخواست بفرستد، صورتحساب بزرگی ایجاد کند، یا سهمیه‌ی ارائه‌دهنده را تمام کند و قابلیت را برای همه از کار بیندازد. محدودیت به‌ازای هر کاربر، هزینه‌ها را قابل پیش‌بینی نگه می‌دارد.
آیا محدودیت نرخ همان throttling است؟
این دو خیلی به هم نزدیک‌اند و اغلب به جای هم استفاده می‌شوند. محدودیت نرخ معمولاً به معنای رد کردن درخواست‌های بالای حد است، در حالی که throttling می‌تواند به معنای کند کردن یا صف گذاشتن درخواست‌ها هم باشد، به جای رد فوری آن‌ها.
آیا محدودیت نرخ جلوی حملات DDoS را می‌گیرد؟
در برابر سیل‌های کوچک و سوءاستفاده‌ی یک کاربر یا آدرس IP کمک می‌کند، ولی حمله‌ی توزیع‌شده‌ی بزرگ از آدرس‌های زیادی همزمان می‌آید. محافظت در برابر آن‌ها معمولاً در سطح شبکه یا CDN انجام می‌شود، پیش از اینکه ترافیک به اپلیکیشن شما برسد.