ما هو تحديد المعدل (Rate Limiting)؟ دليل مبسّط لبناة التطبيقات
تحديد المعدل قاعدة تحدّ من عدد الطلبات التي يمكن لشخص إرسالها إلى نظام ما خلال فترة زمنية محددة، مثلاً 5 محاولات لتسجيل الدخول في الدقيقة، أو 100 استدعاء API في الساعة. وعند بلوغ الحد، تُرفض الطلبات الإضافية (عادةً برمز الخطأ 429 Too Many Requests) حتى تُعاد الفترة الزمنية. وهو يحمي التطبيقات من الإساءة، ويمنع مستخدماً واحداً كثير الطلبات من إبطاء الخدمة للجميع، ويوقف التكاليف غير المنضبطة.
تواجه تحديد المعدل من جهتين: الخدمات التي تستدعيها تحدّ منك، وتطبيقك يجب أن يحدّ من مستخدميه.
لماذا يهم تحديد المعدل عند البناء بالذكاء الاصطناعي
غالباً ما تتصل التطبيقات المبنية بالذكاء الاصطناعي بخدمات مدفوعة، مثل نماذج الذكاء الاصطناعي والبريد الإلكتروني والرسائل النصية والخرائط، وكل استدعاء يكلّف مالاً. لذلك يكون تحديد المعدل ميزة أمنية وميزة متعلقة بالميزانية في الوقت نفسه.
- التحكم في التكاليف. إذا كان تطبيقك يحتوي على خانة "اسأل الذكاء الاصطناعي" دون أي حد، فيمكن لروبوت أن يرسل إليها آلاف الطلبات طوال الليل. وأنت تدفع ثمن كل واحد منها.
- الأمان. بدون حد على نموذج تسجيل الدخول، يستطيع مهاجم تجربة آلاف كلمات المرور على حساب واحد. وحد من بضع محاولات في الدقيقة يجعل ذلك غير عملي.
- البقاء متصلاً. سكربت واحد يتصرف بشكل خاطئ، وأحياناً شيفرتك أنت عالقة في حلقة، قد يُثقل قاعدة بياناتك ويعطّل التطبيق بالكامل.
- احترام حدود الخدمات الأخرى. حين يستدعي تطبيقك واجهة برمجية خارجية بكثرة، فأنت من يتلقى أخطاء 429، وتتعطل الميزات عند مستخدميك.
تبني أدوات بناء التطبيقات بالذكاء الاصطناعي ما تطلبه منها، وإذا لم تذكر الحدود، فغالباً ما تُغفل.
تشبيه من الحياة اليومية
فكّر في سياسة إعادة تعبئة القهوة المجانية في مقهى: "إعادة تعبئة مجانية واحدة لكل زبون في كل زيارة".
- هي لا تمنع أحداً من الاستمتاع بقهوته.
- وتمنع شخصاً واحداً من الوقوف عند الكاونتر طوال اليوم لتعبئة وعاء يكفي المكتب كله.
- وحين يطلب أحدهم إعادة تعبئة رابعة، يقول النادل بأدب "ليس الآن"، وهذا هو الخطأ 429.
الحد الجيد لا يلاحظه الزبائن العاديون، ولا يلاحظه إلا من يفعل شيئاً غير معتاد.
كيف يعمل تحديد المعدل
يحتاج محدِّد المعدل إلى ثلاثة أشياء:
| الجزء | السؤال الذي يجيب عنه | أمثلة |
|---|---|---|
| من | طلبات من تُحسب؟ | لكل حساب مستخدم، أو لكل عنوان IP، أو لكل مفتاح API |
| كم | ما الحد؟ | 5، أو 60، أو 1,000 طلب |
| خلال أي فترة | ما نافذة الوقت؟ | في الثانية، أو الدقيقة، أو الساعة، أو اليوم |
حين يصل طلب، يتحقق التطبيق من عداد "المَن" هذا. إذا كان دون الحد، يمرّ الطلب ويزيد العداد. وإذا تجاوز الحد، يُرفض الطلب.
وهناك طرق شائعة للعدّ:
| الطريقة | كيف تعمل | المقايضة |
|---|---|---|
| النافذة الثابتة (Fixed window) | يُعاد ضبط العداد على الساعة، مثلاً كل دقيقة عند بداية الدقيقة | بسيطة، لكنها تسمح بانفجار في طلبات عند حافة نافذتين |
| النافذة المنزلقة (Sliding window) | تنظر إلى آخر 60 ثانية من الآن | أكثر سلاسة، وحساب أعقد قليلاً |
| دلو الرموز (Token bucket) | لكل مستخدم دلو يُعبّأ بمعدل ثابت، وكل طلب يستهلك رمزاً | تسمح بانفجارات قصيرة مع الحفاظ على متوسط ثابت |
يجب أن تُخزَّن العدادات في مكان سريع ومشترك. فعلى خادم صغير واحد، تكفي الذاكرة. أما حين يعمل التطبيق على عدة أجهزة، فيُحفظ العداد عادةً في مخزن مشترك مثل Redis أو قاعدة البيانات، وإلا فإن كل جهاز يعدّ على حدة، فيصبح الحد الفعلي أكبر بعدة أضعاف.
شكل الاستجابة عند تجاوز الحد
حين يتجاوز طلب الحد، تستجيب واجهة API جيدة بالشكل التالي:
- رمز الحالة
429 Too Many Requests. - غالباً ترويسة
Retry-Afterتبيّن عدد الثواني التي يجب انتظارها. - وأحياناً ترويسات تبيّن حدّك وعدد الطلبات المتبقية في هذه النافذة (وتختلف الأسماء حسب المزود).
يجب أن يستجيب تطبيقك لخطأ 429 بالانتظار ثم إعادة المحاولة لاحقاً، ويفضل أن يستخدم التراجع الأُسّي (Exponential Backoff)، أي الانتظار أطول قليلاً بعد كل محاولة فاشلة (ثانية، ثم ثانيتان، ثم 4)، بدلاً من إغراق الخدمة بالطلبات.
مثال عملي: مساعد كتابة بالذكاء الاصطناعي
لنفترض أنك بنيت تطبيقاً يلصق فيه المستخدمون نصوصاً ويحصلون على إعادة صياغة بالذكاء الاصطناعي.
بدون حدود: يكتب أحدهم سكربتاً يرسل 20,000 طلب طوال الليل. تقفز فاتورة مزود الذكاء الاصطناعي، ويصل حسابك إلى حد المعدل الخاص بالمزود، فيرى المستخدمون الحقيقيون أخطاء طوال الصباح.
مع حدود معقولة:
- لكل مستخدم مسجّل: 30 إعادة صياغة في الساعة في الخطة المجانية، و300 في الخطة المدفوعة. وإذا تجاوز المستخدم الحد، يرى: "لقد وصلت إلى حد هذه الساعة. حاول مرة أخرى بعد 12 دقيقة، أو قم بالترقية."
- لكل عنوان IP في نموذج التسجيل: 5 عمليات تسجيل في الساعة، لمنع الروبوتات من إنشاء آلاف الحسابات المجانية للالتفاف على الحد لكل مستخدم.
- حد للإنفاق يُضبط في لوحة تحكم مزود الذكاء الاصطناعي، كخط دفاع أخير إن فشل كل شيء آخر.
- التعامل مع حدود المزود: إذا أعاد مزود الذكاء الاصطناعي الخطأ 429، ينتظر الخادم ويعيد المحاولة مرة أو مرتين، ثم يعرض رسالة لطيفة مثل "الخدمة مشغولة، يرجى المحاولة مرة أخرى".
يتم فحص الحدود على الخادم. فالحد الذي يوجد فقط في المتصفح، مثل تعطيل الزر بعد 30 نقرة، يمكن لأي شخص تجاوزه باستدعاء واجهتك البرمجية مباشرة.
شرح المصطلحات
| المصطلح | المعنى |
|---|---|
| Rate limit (حد المعدل) | أقصى عدد من الطلبات المسموح بها في نافذة زمنية. |
| Quota (الحصة) | مخصص أكبر، غالباً يومياً أو شهرياً، وقد يرتبط بخطة مدفوعة. |
| 429 | رمز حالة HTTP لعبارة "طلبات كثيرة جداً". |
| Retry-After | ترويسة في الاستجابة تبيّن المدة التي يجب الانتظار قبل المحاولة مجدداً. |
| Throttling (التقييد) | إبطاء الطلبات التي تتجاوز الحد أو رفضها. ويُستخدم غالباً كمرادف. |
| Exponential backoff (التراجع الأُسّي) | الانتظار لفترات أطول تدريجياً بين المحاولات. |
| Burst (انفجار) | زيادة قصيرة في عدد الطلبات دفعة واحدة. |
| Brute-force attack (هجوم القوة الغاشمة) | تجربة أعداد هائلة من كلمات المرور أو الرموز حتى ينجح أحدها. |
مفاهيم خاطئة شائعة
- "تحديد المعدل مخصص للتطبيقات الكبيرة فقط." التطبيقات الصغيرة أهداف أيضاً، لأن الروبوتات تفحص الإنترنت بأكمله بحثاً عن نماذج مفتوحة ونقاط نهاية للذكاء الاصطناعي. وتكلفة الإساءة لا تعتمد على حجمك.
- "إخفاء الزر يكفي." الحدود في المتصفح مجرد لطف، وليست حماية. يجب فرض الحدود الحقيقية على الخادم.
- "الحدود لكل عنوان IP عادلة دائماً." كثيرون قد يشاركون عنوان IP واحداً، كمكتب أو مدرسة أو شبكة هاتف محمول. والحدود لكل مستخدم أكثر إنصافاً بعد أن يسجّل الناس الدخول.
- "خطأ 429 يعني أن الخدمة معطلة." بل يعني أنك تستدعيها بكثرة. تحقق من شيفرتك بحثاً عن الحلقات، واحفظ النتائج التي لا تتغير كثيراً مؤقتاً، راجع ما هو التخزين المؤقت (Caching).
- "تحديد المعدل يغني عن حد الإنفاق." استخدم الاثنين. قد تحتوي الحدود في تطبيقك على أخطاء، وحد الإنفاق لدى المزود هو شبكة أمانك الأخيرة.
ماذا تطلب من أداة البناء بالذكاء الاصطناعي
- "أضف تحديد معدل على الخادم لتسجيل الدخول، والتسجيل، وإعادة تعيين كلمة المرور، ونقطة نهاية الذكاء الاصطناعي. واقترح حدوداً معقولة."
- "اسمح لكل مستخدم مسجّل بعدد [N] من طلبات الذكاء الاصطناعي في الساعة، واعرض رسالة واضحة مع وقت الانتظار عند بلوغ الحد."
- "عندما ترجع واجهة خارجية الخطأ 429، أعد المحاولة بالتراجع الأُسّي حتى 3 مرات، ثم اعرض رسالة خطأ لطيفة."
- "أين تُخزَّن عدادات تحديد المعدل؟ هل ستعمل إذا عمل التطبيق على أكثر من جهاز؟"
- "سجّل كل مرة يصل فيها مستخدم أو عنوان IP إلى الحد، حتى أكتشف الإساءة."
- "ما الخدمات الخارجية التي يستدعيها هذا التطبيق، وما حدودها؟"
تحديد المعدل في Mythex
توضح وثائق Mythex ذلك بوضوح بالنسبة لميزات الذكاء الاصطناعي: حدود المعدل وضوابط الأمان والتكلفة في التطبيقات التي تبنيها تعود إليك في تصميمها، راجع بناء تطبيق ذكاء اصطناعي. اطلب من الوكيل إضافة الحدود في الرسالة نفسها التي تطلب فيها الميزة. وفي خطة Pro يمكن أن تعمل الخدمة المنشورة على ما يصل إلى ثلاثة أجهزة عند الحركة الكثيفة (راجع حدود الاستضافة)، لذلك اطلب عدادات تُحفظ في قاعدة البيانات بدلاً من ذاكرة خادم واحد.
قراءات ذات صلة: ما هي واجهة API، وكيف تستخدم واجهات LLM، وقائمة التحقق الأمنية للتطبيقات المبنية بالذكاء الاصطناعي.
الأسئلة
ما هو تحديد المعدل ببساطة؟
تحديد المعدل قاعدة تحدّ من عدد الطلبات التي يمكن لمستخدم أو جهاز أو تطبيق إرسالها خلال فترة معينة، مثلاً 5 محاولات لتسجيل الدخول في الدقيقة أو 100 استدعاء API في الساعة. تُرفض الطلبات التي تتجاوز الحد حتى تُعاد الفترة إلى الصفر.
ماذا يعني خطأ 429 Too Many Requests؟
يعني رمز الحالة HTTP 429 أنك أرسلت طلبات كثيرة في وقت قصير جداً، فتجاوزت حد المعدل. وغالباً ما تتضمن الاستجابة ترويسة Retry-After تخبرك بمدة الانتظار. والحل هو التباطؤ، أو إعادة المحاولة بعد توقف، أو تقليل عدد مرات استدعاء الخدمة من تطبيقك.
لماذا يحتاج تطبيقي المدعوم بالذكاء الاصطناعي إلى تحديد للمعدل؟
كل طلب للذكاء الاصطناعي يكلفك مالاً بالتوكنات. بدون حد، يستطيع مستخدم واحد أو روبوت إرسال آلاف الطلبات وتكوين فاتورة كبيرة أو استنزاف حصة مزود الخدمة، فيتوقف الميزة عن الجميع. الحدود لكل مستخدم تجعل التكاليف متوقعة.
هل تحديد المعدل هو نفسه التقييد (Throttling)؟
هما مرتبطان جداً ويُستخدمان غالباً بالتبادل. فتحديد المعدل يعني عادةً رفض الطلبات التي تتجاوز الحد، بينما يمكن أن يعني التقييد إبطاء الطلبات أو وضعها في قائمة انتظار بدلاً من رفضها مباشرة.
هل يوقف تحديد المعدل هجمات DDoS؟
يساعد ضد الفيضانات الصغيرة والإساءة من مستخدمين أو عناوين IP فردية، لكن الهجوم الموزع الكبير يأتي من عناوين كثيرة في وقت واحد. والحماية منه تتم عادةً على مستوى الشبكة أو شبكة توصيل المحتوى (CDN)، قبل أن تصل الحركة إلى تطبيقك.