هجوم غير مقصود من عملائك: كيف أنقذني تحديد المعدل (Rate Limiting) من انهيار الـ API؟

يا أهلاً وسهلاً فيكم يا جماعة، معكم أخوكم أبو عمر. اليوم بدي أحكيلكم قصة صارت معي قبل كم سنة، قصة فيها شوية توتر، وكاسة شاي بالنعناع، ودرس تعلمته بالطريقة الصعبة، زي ما بحكوها. بتذكر اليوم هداك كأنه مبارح، كنا في الشركة مبسوطين كثير، أطلقنا API جديد كلياً، واشتغلنا عليه شهور طويلة، ليالي وأيام، وكود انكتب وانمسح مية مرة.

في يوم الإطلاق، الأجواء كانت احتفالية. القهوة جاهزة، والفريق كله متابع لوحات المراقبة (Dashboards) وشايفين الأرقام بتزيد. أول عميل كبير بلش يستخدم الـ API الجديد، وكان الحماس في أوجه. فجأة، وبدون أي مقدمات، بلشت الإنذارات توصل على تلفوني وعلى قنوات السلاك (Slack) زي المطر. “High CPU Usage”, “Memory Leak Detected”, “Service Unresponsive”.

قلبي بلش يدق بسرعة. أول إشي خطر ببالي: هجوم DDoS! حدا بستهدفنا! بلشنا نركض ونحلل مصدر الطلبات (Requests). لكن المفاجأة كانت أكبر من توقعاتنا. مصدر الهجوم ما كان جيش من الأجهزة المجهولة (Botnet) من آخر الدنيا، لأ. مصدر ملايين الطلبات كان جاي من عنوان IP واحد: عنوان IP الخاص بعميلنا الجديد اللي كان المفروض يحتفل معنا!

بعد تواصل سريع معهم، اكتشفنا الكارثة (البريئة): أحد مطوريهم كتب سكربت فيه حلقة لا نهائية (Infinite Loop) بالخطأ، والسكربت هاد كان بنادي على الـ API تبعنا بشكل مجنون بدون أي تأخير. كانوا متحمسين زينا، بس حماسهم كان رح يوقع السيستم كله. وقتها، أدركت إنه حماية أنظمتك من الغرباء مهم، بس حمايتها من “أصدقائك” وعملائك اللي ممكن يخطئوا، يمكن يكون أهم.

ومن هداك اليوم، صار مبدأ الـ Rate Limiting مش مجرد “إشي حلو يكون عندك”، بل صار أساس في كل سطر كود وكل تصميم نظام بنعمله. خلونا نحكي فيه بالتفصيل.

ما هو تحديد المعدل (Rate Limiting)؟

ببساطة شديدة، تخيل الـ API تبعك زي كأنه شباك بيع تذاكر في سينما. لو كل الناس هجمت على الشباك مرة واحدة، الموظف رح يتلبك، رح تصير فوضى، وممكن ما حدا ياخد تذاكر. تحديد المعدل هو بمثابة “حارس أمن” أو نظام طابور بنظم العملية. هو بقول: “يا جماعة، واحد واحد، وكل واحد إله عدد معين من الطلبات في الدقيقة”.

تقنياً، الـ Rate Limiting هو آلية للتحكم في كمية الطلبات التي يمكن للمستخدم (أو عنوان IP، أو مفتاح API) إرسالها إلى الخادم خلال فترة زمنية معينة. إذا تجاوز المستخدم هذا الحد، يتم رفض طلباته مؤقتًا، وغالبًا ما يتم إرجاع رمز حالة HTTP مثل 429 Too Many Requests.

ليش هو مهم لهالدرجة؟

أكيد قصتي بتوضح جزء من الأهمية، بس الموضوع أعمق من مجرد حماية من أخطاء العملاء. هاي أهم الأسباب اللي بتخليه ضرورة قصوى:

• حماية استقرار الخدمة (Availability): السبب الرئيسي. منع الحمل الزائد على الخوادم، سواء كان مقصود (DDoS) أو غير مقصود (زي ما صار معي)، مما يضمن أن الخدمة تظل متاحة للجميع.
• الأمان (Security): يمنع هجمات القوة الغاشمة (Brute-force attacks) على صفحات تسجيل الدخول أو استعادة كلمة المرور. تخيل لو سمحت لمهاجم يجرب آلاف كلمات المرور في الثانية! تحديد المعدل بخلّي هالهجمات بطيئة وغير عملية.
• ضمان الاستخدام العادل (Fair Usage): في بيئة فيها مستخدمين كثر، تحديد المعدل بيضمن إنه ما يجي مستخدم “طماع” أو عنده سكربت سيء يستهلك كل الموارد ويخرب التجربة على باقي المستخدمين.
• التحكم في التكاليف (Cost Control): في عالم الحوسبة السحابية (Cloud Computing)، كل طلب API ممكن يكلفك فلوس (وقت معالجة، نقل بيانات، استدعاء خدمات أخرى). بدون تحديد المعدل، ممكن فاتورتك الشهرية تصدمك صدمة عمرك.

كيف بيشتغل؟ أشهر الخوارزميات

هنا بنبدأ ندخل في العمق التقني شوي. في طرق وخوارزميات مختلفة لتطبيق الـ Rate Limiting، وكل وحدة إلها ميزاتها وعيوبها. خلونا نشوف أشهرها:

1. عداد النافذة الثابتة (Fixed Window Counter)

هاي أبسط طريقة. بنحدد “نافذة” زمنية (مثلاً، دقيقة واحدة) و”حد أقصى” (مثلاً، 100 طلب). وبنصير نعد الطلبات من كل مستخدم في هاي الدقيقة. إذا وصل 100 طلب قبل ما تخلص الدقيقة، بنرفض أي طلب جديد لحد ما تبدأ الدقيقة التالية.

مشكلتها: ممكن المستخدم يستهلك كل حصته في آخر ثانية من الدقيقة، وبعدها يستهلك حصة الدقيقة الجديدة في أول ثانية منها. يعني فعلياً، بكون أرسل 200 طلب خلال ثانيتين، وهذا ممكن يسبب ضغط مفاجئ على الخادم.

2. خوارزمية دلو التوكنات (Token Bucket)

هاي الخوارزمية أذكى شوي. تخيل إنه عندك “دلو” لكل مستخدم. هذا الدلو له سعة معينة، والنظام بضل يضيف “توكنات” (قطع رمزية) على الدلو بمعدل ثابت (مثلاً، 2 توكن كل ثانية).

• كل طلب بيجي من المستخدم، بيستهلك “توكن” من الدلو.
• إذا الدلو كان فاضي، الطلب بينرفض.
• إذا المستخدم ما أرسل طلبات لفترة، التوكنات بتتجمع في الدلو (لحد السعة القصوى).

ميزتها: بتسمح بحدوث “رشقات” (Bursts) من الطلبات بشكل متحكم فيه. يعني لو المستخدم كان هادي لفترة، بنسمحله يرسل عدد كبير من الطلبات مرة واحدة (طالما عنده توكنات)، وبعدها لازم يلتزم بالمعدل الثابت. هذا بيعطي مرونة ممتازة.

3. خوارزمية النافذة المنزلقة (Sliding Window Log/Counter)

هاي تعتبر من أدق وأفضل الطرق. هي بتحل مشكلة “النافذة الثابتة”. بدل ما نحسب الطلبات في دقيقة ثابتة (من 00:00 إلى 00:59)، بنحسبها في آخر 60 ثانية من لحظة وصول الطلب.

يعني لو الطلب وصل الساعة 10:30:15، النظام بشوف كم طلب وصل من نفس المستخدم من الساعة 10:29:15 لحد الآن. هاي الطريقة بتمنع حدوث الضغط المفاجئ على حواف النوافذ الزمنية وبتعطي توزيع أكثر سلاسة للحمل.

خلّونا نشوف إشي عملي: مثال برمجي

الحكي النظري حلو، بس “فرجيني الكود”، زي ما بقولوا المبرمجين. بما إنه كثير من الشباب بشتغلوا Node.js و Express، هي مثال بسيط باستخدام مكتبة مشهورة اسمها express-rate-limit.

const express = require('express');
const rateLimit = require('express-rate-limit');

const app = express();

// تطبيق تحديد المعدل على كل الطلبات
const limiter = rateLimit({
    windowMs: 15 * 60 * 1000, // 15 دقيقة
    max: 100, // الحد الأقصى: 100 طلب لكل IP خلال 15 دقيقة
    standardHeaders: true, // إرجاع معلومات الحد في الهيدرز `RateLimit-*`
    legacyHeaders: false, // تعطيل الهيدرز القديمة `X-RateLimit-*`
    message: 'يا صاحبي، طلباتك كثيرة! خذ نفس وارجع جرب بعد ربع ساعة.',
});

app.use(limiter);


// يمكن تطبيق محددات مختلفة لنقاط وصول (endpoints) حساسة
const loginLimiter = rateLimit({
    windowMs: 60 * 60 * 1000, // ساعة واحدة
    max: 5, // 5 محاولات تسجيل دخول فاشلة لكل IP في الساعة
    message: 'عدد محاولات تسجيل الدخول كثير، تم حظرك مؤقتاً.',
    skipSuccessfulRequests: true, // لا تحسب محاولات الدخول الناجحة
});

// تطبيق المحدد فقط على مسار تسجيل الدخول
app.post('/login', loginLimiter, (req, res) => {
    // ... منطق تسجيل الدخول
});


app.get('/', (req, res) => {
    res.send('أهلاً بك في الـ API تبعنا!');
});

app.listen(3000, () => {
    console.log('الخادم يعمل على المنفذ 3000');
});

شوفوا ما أبسطه! خلال دقائق، بتكون حميت الـ API تبعك من الاستخدام المفرط. الكود واضح: بنحدد فترة زمنية وعدد طلبات مسموح فيها، وبنطبق هاد “الوسيط” (Middleware) على المسارات اللي بدنا نحميها.

نصايح أبو عمر من الكيس

بعد سنين من الشغل والوقعات والمشاكل، اتعلمت كم شغلة بخصوص هالموضوع، وحابب أشارككم إياها:

1. لا تستخدم حداً واحداً للجميع: تحديد معدل الطلبات لازم يكون ذكي. مسار مثل /login يجب أن يكون له حد صارم وقليل (مثلاً 5 طلبات في الساعة) لمنع هجمات التخمين، بينما مسار مثل /posts يمكن أن يكون له حد أعلى بكثير.
2. أخبر المستخدمين بالحدود: من أفضل الممارسات إنك ترجع Headers في استجابة الـ API بتوضح للمطورين حدودهم. أشهرها:
   • X-RateLimit-Limit: الحد الأقصى للطلبات في النافذة.
   • X-RateLimit-Remaining: عدد الطلبات المتبقية للمستخدم.
   • X-RateLimit-Reset: الوقت (كتوقيت Unix) الذي سيتم فيه إعادة تعيين العداد.

   هذا بساعد المطورين اللي بستخدموا الـ API تبعك إنهم يبنوا تطبيقاتهم بطريقة تحترم حدودك.

3. فكر في مكان التطبيق: يمكنك تطبيق الـ Rate Limiting على مستوى التطبيق نفسه (زي مثال Express)، أو على مستوى أعلى مثل الـ API Gateway (مثل Kong, Nginx, Traefik) أو الـ Load Balancer. التطبيق على مستوى الـ Gateway أفضل لأنه بيحمي تطبيقك من الأساس، وما بوصل الطلب الزائد إله أصلاً.
4. مستويات مختلفة للمستخدمين: إذا كان عندك خطط أسعار مختلفة (مجاني, مدفوع, أعمال)، يمكنك ربط تحديد المعدل بهذه الخطط. المستخدم المجاني يحصل على 100 طلب في الساعة، بينما المستخدم المدفوع يحصل على 5000. هذا حافز ممتاز للترقية.
5. راقب وسجل (Logging & Monitoring): لازم يكون عندك نظام مراقبة يوضح لك مين اللي بيوصل للحد الأقصى باستمرار. ممكن يكونوا مستخدمين بحاجة لخطة أعلى، أو ممكن يكون مؤشر على وجود مشكلة في تطبيقهم.

الخلاصة يا جماعة الخير 🏁

تحديد المعدل (Rate Limiting) مش مجرد أداة تقنية، هو فلسفة في بناء الأنظمة القوية والمرنة. هو بمثابة صمام أمان بيحمي استثمارك، ووقتك، وراحة بالك. في عالم كل شيء فيه متصل، الـ API تبعك هو واجهتك للعالم، وحمايته هي أولويتك الأولى.

لا تستنوا تصير معكم قصة زي قصتي حتى تقتنعوا. ابدأوا من اليوم، طبقوا تحديد المعدل على مشاريعكم. الشغلة بسيطة، لكن أثرها كبير جداً. وزي ما بنقول في فلسطين: “الوقاية خير من قنطار علاج”.