تضع خدمة حدًا قدره مئة طلب في الدقيقة لكل عنوان IP، ثم تتلقى شكاوى من موظفي شركة كاملة لا يستطيعون الدخول. قد يشارك عشرات الأشخاص عنوانًا عامًا واحدًا خلف NAT، بينما يستطيع مهاجم توزيع طلباته على عناوين متعددة. لذلك لا يكفي ضبط رقم ثابت؛ يجب تحديد من تقيّد، وأي عملية تحمي، وكيف تشرح للمستخدم سبب الرفض.
اختيار مفتاح الحد يبدأ بنموذج التهديد
للواجهات العامة قبل تسجيل الدخول قد يكون عنوان الشبكة إشارة مفيدة لكنه ليس هوية مستخدم مؤكدة. بعد المصادقة، غالبًا يكون مفتاح الحساب أو المؤسسة أو رمز API أكثر عدلًا، مع حد احتياطي على الشبكة لمنع إساءة الاستخدام. لا تثق تلقائيًا في X-Forwarded-For المرسل من العميل؛ استخرج عنوان المصدر من طبقة وكيل موثوقة ومضبوطة. ميّز بين الحسابات البشرية والخدمات الآلية، ولا تجعل مشاركة المكتب للشبكة سببًا لتعطيل العمل.
افصل العمليات حسب كلفتها وحساسيتها
قراءة صفحة خفيفة ليست مثل تشغيل تقرير ضخم أو إرسال رمز تحقق. ضع حدودًا مختلفة لكل مسار أو فئة تكلفة، مع قيود أشد على محاولات تسجيل الدخول واستعادة كلمة المرور. في العمليات المكلفة يمكن إضافة ميزانية تزامن أو طابور، لا مجرد عداد للطلبات. اختبر حالات الحساب الجديد والحساب الكبير والمستخدم الذي يعيد المحاولة بسبب اتصال ضعيف، حتى لا يتحول الحد إلى عقوبة للاستخدام الطبيعي.
اختر الخوارزمية وفق السلوك المطلوب
نافذة ثابتة سهلة التنفيذ لكنها تسمح بدفعة مضاعفة عند الحد الفاصل بين دقيقتين. Token Bucket تسمح بانفجار قصير مضبوط ثم تعيد تعبئة الرصيد تدريجيًا؛ Sliding Window تعطي توزيعًا أكثر اتساقًا مع كلفة أعلى بحسب التطبيق. لا توجد خوارزمية مثالية لكل الحالات. في نظام متعدد الخوادم، يجب أن تتشارك العقد حالة العد أو تستخدم بنية تقلل اختلاف القرارات، مع تحديد سلوك النظام عند تعطل مخزن العدادات.
أخبر العميل كيف يتعافى
عند تجاوز الحد استخدم استجابة HTTP 429 حيث تنطبق، ورسالة مفهومة، وترويسة Retry-After عند توفر وقت تقديري صحيح. تجنب إعادة المحاولة الفورية المتزامنة؛ على العملاء تطبيق تراجع تدريجي مع jitter وحد أقصى للمحاولات. لا تكشف تفاصيل حساسة عن قواعد كشف إساءة الاستخدام. راقب عدد الرفض حسب المسار ونوع الهوية والعميل، وافصل الطلبات العدائية عن مستخدمين متضررين من حد غير عادل.
اختبار عملي قبل التعميم
ابدأ بسياسة مراقبة فقط إذا أمكن، وسجل من كان سيُرفض دون تعطيل الطلبات، ثم جرّب حدًا تجريبيًا على شريحة صغيرة. اختبر 50 مستخدمًا خلف شبكة واحدة، ومستخدمًا واحدًا يرسل طلبات مكثفة، وفشل مخزن الحالة، وتزامن الطلبات عند حد النافذة. نجاح Rate Limiting لا يقاس بعدد طلبات 429 وحده، بل بانخفاض الحمل الضار مع بقاء المسارات الشرعية متاحة.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…