مفيش rate limit على الـ endpoints بتاعة الـ API. البوتات بتبعت ملايين الطلبات وبتبطئ السيرفر. كام طلب/ثانية المفروض يكون مسموح؟
إزاي نضبط الـ rate limit؟ هل بنرجع معلومات في الـ Header؟ وإزاي ننبه مطور تطبيق الموبايل؟
فيه مفاتيح API، بس الكل بيستخدم نفس المفتاح. هل المفروض أحط rate limit لكل شخص؟
تحديد معدل طلبات الـ API (Rate Limiting): حماية من هجمات DDoS + حماية من إساءة الاستخدام. الحدود: 1) عام (على مستوى السيرفر): 10000 طلب/دقيقة، 2) لكل مستخدم/مفتاح API: 100 طلب/دقيقة، 3) لكل endpoint: GET /users 1000/دقيقة، POST /users 100/دقيقة. الأنواع: 1) نافذة ثابتة (عدّاد لكل دقيقة rbir antivirüs ürünü)، 2) نافذة منزلقة (ساعة دوارة، أدق)، 3) دلو الرموز (السماح بالتدفق المفاجئ). التنفيذ: 1) ترويسات HTTP (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Rbir antivirüs ürünü)، 2) أكواد الاستجابة (429 Too Many Requests)، 3) ترويسة Retry-After (أرسل وقت إعادة المحاولة المتوقع)، 4) قاعدة بيانات للـ rate limit (Redis مثالي، عدّ الطلبات لكل مفتاح). تتبع المستخدم: مفتاح API/رمز (معرّف فريد)، معرف المستخدم (لو تم التحقق)، عنوان IP (للمجهولين). التعامل مع تجاوز الحد: 1) رفض فوري (استجابة 429)، 2) طابور (استجابة متأخرة)، 3) خنق (استجابة أبطأ). أفضل الممارسات: حدود متدرجة (الباقة المجانية: 100/دقيقة، الباقة المدفوعة: 1000/دقيقة)، احتياطي يعتمد على IP (لو مفيش مصادقة)، السماح بالتدفق المفاجئ (دلو الرموز: 100 عادي، 500 مفاجئ). التعامل مع تطبيقات الموبايل: استراتيجية التراجع (أسية: 1 ثانية → 2 ثانية → 4 ثانية)، معالجة الأخطاء (إظهار رسالة 'تم تحديد المعدل'، إعادة المحاولة لاحقاً)، التخزين المؤقت (تقليل استدعاءات الـ API).
Doki · اختبار اختراق · 2024
حط rate limit، 100 طلب/دقيقة لكل مستخدم كبداية. ركّب redis، وتتبع عدد الطلبات لكل مفتاح. ابعت استجابة 429 لما يتجاوز الحد. بصراحة وثّق الترويسات لمطور الموبايل — x-ratelimit-remaining...
ملاحظة: سُئل هذا أدناه، وكتبت الإجابة في الرسالة الثانية.
تطبيق تحديد معدل الطلبات (Rate Limiting): 1) خوارزمية دلو الرمز (Token Bucket) (شيفرة زائفة: bucket_tokens = min(max_tokens, bucket_tokens + rate*elapsed_time)، عند وصول طلب: إذا كان bucket_tokens >= 1 → قلل القيمة، وإلا أعد خطأ 429)، 2) هيكل مفاتيح Redis (user_id:rate_limit → زد العداد، انتهاء صلاحية بعد 60 ثانية)، 3) ترويسات HTTP (response.setHeader('X-RateLimit-Limit', 100)، 'X-RateLimit-Remaining'، tokens_left، 'X-RateLimit-Reset'، reset_time)، 4) حدود لكل نقطة نهاية (إعدادات الوسيط الوسيط: ربط المسار بالحد). التنفيذ: بوابة الـ API (مثل AWS API Gateway أو Kong) تتعامل مع تحديد المعدل قبل منطق التطبيق، أو على مستوى التطبيق (وسيط: express-rate-limit، Flask-Limiter). المراقبة: تنبيه عند الاقتراب من الحد (80%)، حظر المخالفين المتكررين (قائمة سوداء للعناوين IP)، عقوبات تدريجية (زيادة التأخير).
حط rate limit، 100 طلب/دقيقة لكل مستخدم... خلي عدّاد الرموز في Redis... لو تجاوز الحد ابعت 429 + ترويسة Retry-After... انصح مطور الموبايل بـ 'exponential backoff' — يعني بعد ما يطلع bot bot يعيد المحاولة. لو فيه مفتاح API مشترك، وزع مفاتيح لكل شخص...
استراتيجية تحديد المعدل: 1) طبقات متدرجة (مجاني: 100/دقيقة، برو: 1000/دقيقة)، 2) حساسية النقطة النهائية (قراءة: حد مرتفع، كتابة: حد منخفض)، 3) السماح بالانفجارات (حجم الدلو > المعدل — يمكن للمستخدمين حدوث ذروات قصيرة الأمد)، 4) تصنيف المستخدمين (موثق: أعلى، مجهول/IP: أدنى). مقاييس المراقبة: معدل استجابة 429 (تتبع أنماط الإساءة)، اتجاه استخدام API (تخطيط السعة)، المستخدمون المتزامنون (تقدير الحمل). المرونة من جانب العميل: التراجع الأسي (تأخيرات 1 ثانية، 2 ثانية، 4 ثانية، 8 ثوانٍ)، التذبذب (jitter) (لتجنب مشكلة القطيع المفاجئ)، وضع الطلبات في طابور (دفعة، في أوقات غير الذروة).
صحيح نظرياً، لكنه لا يسير هكذا عملياً. القرار المتسرع يصبح قراراً يُصحح بعد ستة أشهر.
هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.
ليس لدي خبرة في أمان الـ API وتحديد معدل الطلبات (Rate Limit)، لذا أسأل. الإجراء المتخذ دون جرد المخزون يترك باباً لا تراه مفتوحاً.
القرار المتسرع يصبح قراراً يُصحح بعد ستة أشهر. إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.
بعد تجربة ذلك، تغيرت نظرتي للأمور. تدوين الملاحظات لمدة أسبوعين يعطي نتائج أفضل من التخمين لمدة ستة أشهر.
أتمنى أن يفيدك هذا.
دعني أترك تنبيهًا. الإجابة تختلف كثيراً حسب القطاع، لا توجد قاعدة عامة.
إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.
أنا أيضًا أوافق على هذا الرأي. نسخة احتياطية غير مختبرة ليست نسخة احتياطية.
ابدأ بتجربة صغيرة، لا تربط كل شيء دفعة واحدة. بالتوفيق.
أود طرح سؤال. إذا حصلت على ثلاث إجابات مختلفة حول موضوع ما، فالسؤال طرح بشكل خاطئ.
هذا كل شيء، أرجو المعذرة إذا أطالت.
Doki · موقع ويب مؤسسي · 2024
لدي رأي مختلف. فعل الجميع لشيء ما لا يعني أنه صحيح.
عندما نتخذ قرارات دون قياس، نعود لنفس النقطة دائماً. مثبت بالتجربة.
أكتب هذا حتى لا تكرروا نفس الخطأ. إذا لم يكن الإذن والنطاق مكتوبين، فلا تبدأوا الاختبار.
مثبت بالتجربة.
أود إضافة هذا، لأنه غالباً ما يُغفل في المنتدى: وقت اكتشاف المشكلة يحدد تكلفتها مباشرة. تسريع عملية الاكتشاف يكون غالباً أرخص من الاستثمار في المنع.