Technical Tutorials

مع تحول البنى القائمة على واجهات برمجة التطبيقات (API) إلى العمود الفقري للتجارب الرقمية الحديثة، لم يعد تأمين هذه النقاط النهائية ضد الإساءة وهجمات البوتات والارتفاعات المفاجئة في حركة المرور خياراً بل أصبح أمراً حاسماً. واحدة من أكثر الأدوات فعالية في ترسانة المهندس هي تقييد المعدلات (Rate Limiting). ومع ذلك، فإن اختيار الخوارزمية المناسبة يمكن أن يؤثر بشكل كبير على أداء النظام وتجربة المستخدم. في هذا المنشور، نغوص بعمق في استراتيجيتين شائعتين: خوارزمية دلو الرموز (Token Bucket) ومنهج سجل النافذة المنزلقة (Sliding Window Log).

لماذا يهم تقييد المعدلات

قبل اختيار خوارزمية، من الضروري فهم التهديدات التي نعمل على تخفيفها. يخدم تقييد المعدلات ثلاثة أغراض رئيسية: حماية الخدمات الخلفية من الحمل الزائد، ومنع الإساءة الخبيثة مثل هجمات القوة الغاشمة، وضمان الاستخدام العادل بين المستأجرين في البيئات متعددة المستأجرين. بدون هذه الضوابط، يمكن لعميل خائن واحد استهلاك جميع الموارد المتاحة، مما يؤدي إلى حجب الخدمة (DoS) للمستخدمين الشرعيين.

خوارزمية دلو الرموز: اندفاع بكفاءة

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

الخصائص الرئيسية

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

مفهوم التنفيذ

عند تنفيذ هذا في بوابة API مثل NGINX أو Kong، تقوم عادةً بتكوين معدل يحدد سرعة إعادة تعبئة الرموز. فيما يلي مقتطف تكوين مفاهيمي لبوابة تعتمد على Lua:


-- تكوين دلو الرموز
local token_bucket = require "resty.token_bucket"

-- تحديد سعة الدلو ومعدل إعادة التعبئة
local bucket = token_bucket:new({
    capacity = 100,      -- الحد الأقصى لحجم الانفجار
    refill_rate = 10,    -- الرموز في الثانية
    key = "client_ip"    -- تقييد المعدل لكل عنوان IP
})

if bucket:consume() then
    -- تم السماح بالطلب
    return ngx.HTTP_OK
else
    -- تم تجاوز حد المعدل
    return ngx.HTTP_TOO_MANY_REQUESTS
end

سجل النافذة المنزلقة: الدقة في التتبع

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

كيف يعمل

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

المفاضلات

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

اختيار الاستراتيجية المناسبة

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

الخاتمة

يعد تنفيذ تقييد معدل قوي حجر الزاوية في أمن التطبيقات. سواء اخترت الطبيعة القادرة على تحمل الانفجارات لدلو الرموز أو دقة النافذة المنزلقة، فإن فهم الآليات الأساسية يتيح لك تكوين بوابة واجهة برمجة التطبيقات الخاصة بك بفعالية. من خلال موازنة الأداء واستهلاك الذاكرة ومتطلبات الأمان، يمكنك حماية بنيتك التحتية مع الحفاظ على تجربة سلسة لمستخدميك.