الخلاصة

  • يعرّف draft-ietf-httpapi-ratelimit-headers-11 قيمة r بوصفها الحصة المتاحة حالياً ضمن سياسة وقسم محددين، لكنه ينص على أنها ليست طلبات ممنوحة ولا ضماناً بأن الطلب التالي سيُخدم.
  • على العميل أن يحتفظ بحدوده للسرعة والتزامن والكلفة، وأن يعامل الإشارة البعيدة كمدخل قابل للتقييد لا كسلطة على المشغّل. القيمة الكبيرة قد تزيد خطر الاستنزاف إذا تحولت آلياً إلى اندفاع.

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

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

لم تكن المشكلة أن الإشارة تمنع العميل من الفهم. المشكلة أن العميل منحها سلطة لم تمنحها المواصفة.

نشر فريق IETF HTTPAPI المراجعة 11 من RateLimit header fields for HTTP في 23 مايو 2026. وهي Internet-Draft نشطة مقصودة لمسار المعايير وتنتهي في 24 نوفمبر 2026. ليست RFC ولا دليلاً على انتشار تطبيق أو حادث حقيقي أو قابلية تشغيل بين منتجات. يناقش هذا المقال الحدود التي يقررها النص المقترح نفسه.

لا معنى للرقم بلا سياسة ووحدة وقسم

يصف RateLimit-Policy سياسة حصة مسماة. تحمل q مقدار الحصة، ويمكن أن تحمل qu الوحدة وw النافذة وpk مفتاح القسم. تقترح المراجعة ثلاث وحدات أولية: عدد الطلبات، وبايتات المحتوى، والطلبات المتزامنة.

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

أما RateLimit فيصف حداً حالياً لخدمة السياسة والقسم. تشير r إلى المتاح الآن، وتشير t إلى النافذة الفعالة. إذا خُزنت القيمة في حقل واحد اسمه «المتبقي»، ضاعت الوحدة واسم السياسة والقسم وزمن الملاحظة.

السجل القابل للمراجعة يحتفظ بالمصدر والوقت والسياسة والوحدة والقسم وq وw وr وt وحالة HTTP وخصائص الطلب. هذا السجل يثبت ما أعلنته الخدمة في تلك اللحظة، ولا ينسخ خوارزمية قبولها المستقبلية.

المتاح ليس محجوزاً

ينص المشروع على أن العميل لا يجوز أن يفترض أن قيمة موجبة لـr تضمن خدمة طلبات أخرى. ويصف قسم الأمن الوحدات المتاحة بأنها تلميحات تساعد على تجنب الخنق، لا طلبات ممنوحة ولا اتفاق مستوى خدمة.

يمكن أن تتغير الحمولة قبل وصول الطلب التالي. قد تصبح سياسة أخرى هي الحد الفعلي. قد تخفض الخدمة القيم استجابة لتشبع أو هجوم. وقد يفشل الطلب في المصادقة أو التفويض أو التحقق التطبيقي، وهي قرارات لا يملك حقل RateLimit أن يحسمها.

والعكس صحيح: يمكن للخدمة أن تقبل طلباً مع r=0. لا تفرض المسودة علاقة ثابتة بين القيمة وحالة الاستجابة. تحتفظ الخدمة بحرية التطبيق والقبول.

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

النافذة تقيد الاستهلاك ولا تعد بإعادة التعبئة

تمثل t عدداً من الثواني لا ينبغي للعميل خلاله استهلاك أكثر من r. اختيار مدة نسبية يخفف الاعتماد على تزامن الساعات ويقلل استيقاظ العملاء جميعاً عند وقت مطلق واحد.

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

ينبغي أن يعتبر المتحكم الملاحظة القديمة منتهية الصلاحية، لا أن يملأ دلواً محلياً. ينتظر مع قدر من العشوائية، ويرسل اختباراً محدوداً، ويقرأ إشارة جديدة، ثم يصعد تدريجياً ضمن حدوده المحلية.

قد تأتي Retry-After إلى جوار الحقول، وتقترح المسودة ألا تشير إلى وقت يسبق نهاية النافذة الفعالة. ومع ذلك يظل وقت إعادة المحاولة مختلفاً عن توفر الحصة والقبول. لا يوجد مقعد محجوز عند انتهاء المؤقت.

لماذا يمكن لقيمة كبيرة أن تصبح أداة ضغط

إذا قسّم العميل r على t بلا النظر إلى q/w، فقد يستنتج معدل اندفاع أكبر كثيراً من متوسط السياسة. يذكر النص هذا الخطر تحديداً: يمكن أن تتسبب الحقول نفسها في استنزاف الموارد إذا قادت سلوكاً بسيطاً.

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

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

هذه حدود سلطة مهمة: الخدمة تملك إعلان حالتها وتطبيق سياستها. العميل يملك قراره في مقدار الضغط الذي يستطيع إحداثه بأمان. لا يلغي أحد الإيصالين الآخر.

مفتاح القسم ليس هوية ولا إذناً

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

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

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

يجب حفظ هوية المصادقة وقرار التفويض وقسم الحصة وإشارة الحد والقبول والنتيجة كحقائق مترابطة لا كحقل واحد.

الوسيط قد يستهلك وحدة لا يراها العميل

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

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

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

حالة الاستجابة ليست السياسة كلها

يمكن أن تظهر الحقول في استجابة ناجحة أو غير ناجحة أو مخنوقة. لا تفرض المراجعة علاقة بين القيم ورمز الحالة. استجابة 200 تصف ما حدث للطلب الحالي، بينما r وt يصفان إشارة حالية لما بعده.

يعرّف RFC 6585 حالة 429، ويمكن استخدام Retry-After معها. لكن 429 لا يثبت خوارزمية واحدة، ولا يضمن أن المحاولة التالية ستنجح. كما أن نجاح الطلب الحالي لا يعد بسعة مستقبلية.

النظام الآمن يسجل الزمنين: نتيجة الطلب الذي انتهى، والملاحظة التي ستؤثر في قرار لاحق. إذا دمجهما في «الخدمة متاحة» أو «الخدمة مغلقة»، فقد يرسل حين يجب أن يهدأ أو يحجب عملاً كان يمكن قبوله.

نوع المشكلة تصنيف لا إدانة

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

لكن «استخدام غير طبيعي» هو تصنيف صادر عن الخدمة. لا يثبت وحده نية خبيثة أو هوية الفاعل أو صحة المصنف. يصلح لتصرف قابل للعكس: خفض السرعة، تعليق دفعة، طلب مراجعة. لا يكفي لعقوبة دائمة أو اتهام علني.

يوفر RFC 9457 بنية تفاصيل المشكلة، وRFC 9651 بنية الحقول، وRFC 9110 دلالات HTTP. دقة البنية تحفظ القول، لكنها لا تحول قول المنتج إلى حقيقة مستقلة.

المصادر والحدود

تضم الحزمة المجمدة المراجعة 11 وصفحات Datatracker للتاريخ والمراجع، وصف فريق HTTPAPI ومسودة الخصوصية، وRFC 9110 و9651 و6585 و9457 و9205، وسجلي IANA للحقول وأنواع المشكلة. تثبت هذه المواد النص المقترح وحدوده، ولا تثبت تنفيذاً أو منتجاً أو حادثاً أو انتشاراً أو أداءً أو قابلية تشغيل.

المصادر