عدم التوافق، بصراحة
لحركة مرور الويب البشرية شكل. إنها متقطعة، مرتبطة بالجلسة ومحدودة ذاتيًا: يفتح الشخص صفحة، يقرأها، ينقر، ثم يتوقف في النهاية. لا تتفرع المتصفحات إلى ألف عنوان URL على التوازي، والشخص الذي يصطدم بـ 429 عادةً ما يستسلم أو ينتظر. وقد بُني تخطيط السعة على مدى العشرين عامًا الماضية على هذا الافتراض.
لحركة مرور الوكلاء شكل مختلف. إنها متوازية، مستمرة ورخيصة التضخيم. يمكن لمنسّق واحد أن يولّد وكلاء فرعيين يحاكي كل منهم نمط الطلب نفسه عبر العديد من عناوين المصدر، ويعيد المحاولة عند الفشل دون إرهاق، ويُبقي الجلسة مفتوحة لساعات أثناء عمله عبر خطة استرجاع. تكلفة إصدار طلب إضافي تقترب من الصفر، لذا فالتوازن الطبيعي ليس "اقرأ بأدب ثم انصرف" — بل "أعد المحاولة حتى يستسلم شيء ما".
هذا عدم التوافق صار مرئيًا الآن على الجانبين. المواقع التي تنشر مواد مرجعية تُبلّغ عن إغراقها بعملاء آليين لا يتصرفون بأي شكل كالقرّاء، بينما بدأت مواقع أخرى تقيّد وصول الوكلاء خلف شروط صريحة وضوابط تقنية. تُظهر المدونة كلا نصفَي نمط الفشل: وكلاء يُغرقون موقعًا مرجعيًا، ومشغّلون يستجيبون بتقييد الوصول الآلي جملةً. لا النتيجة الأولى ولا الثانية تصميم مستقر.
السبب الجذري ليس الحجم. بل أن الموقع لا يعرف ما يفعله العميل، والعميل لا يلتزم بإخباره.
لماذا تفترض حدود المعدل القائمة على IP العميل الخطأ
معظم حدود المعدل مكتوبة لعميل يتصرف كالمتصفح. تُفتّش على عنوان IP أو مفتاح API، وتطبّق دلو رموز، وتعيد 429 مع Retry-After. بالنسبة للمتصفح هذه حلقة مغلقة: يرى الإنسان خطأً، يتوقف التبويب عن التحميل، يُعاد ملء الدلو.
الوكلاء يكسرون كل جزء من تلك الحلقة.
- إعادة المحاولات تتجاهل نية التراجع. مكتبة عميل تتعامل مع 429 كخطأ عابر ستعيد المحاولة، غالبًا بتراجع أُسّي مُشوّش لا يزال يتضاعف عبر الوكلاء الفرعيين.
- التفرع يهزم التفتيش على IP. عبء عمل ينتشر عبر عناوين أو مناطق أو مجموعات خروج يبدو كعملاء كثيرة حسنة السلوك بدلًا من عميل واحد عدواني.
- المحاكاة تهزم الحدود لكل نقطة نهاية. إذا كان الحد لكل مسار، يوزّع الوكيل العمل عبر المسارات. وإذا كان لكل مفتاح، يوزّعه عبر المفاتيح. الحد لا يكون جيدًا إلا بقدر الهوية المرتبط بها.
والأسوأ أن الحدود القائمة على IP تعاقب الطرف الخطأ. يمكن تقييد NAT مشترك أو وكيل مؤسسي أو مشغّل CI لأن عبء عمل واحدًا خلفه أساء التصرف. الحد حقيقي، لكن المساءلة غائبة.
ما يحتويه عقد القبول
البديل هو التوقف عن التعامل مع طلبات الوكلاء كـ HTTP مجهول والبدء في التعامل معها كعبء عمل تفاوضي. عقد القبول اتفاق صغير صريح يُبرم قبل وصول أول طلب حقيقي إلى خدمة أصل. وله ثلاثة أجزاء.
غرض ونطاق مُعلنان، مرتبطان بهوية عبء العمل
يسمّي العقد ما يفعله العميل والموارد التي يغطيها. والأهم أنه مرتبط بـ هوية عبء العمل — بيانات اعتماد قابلة للتحقق للمهمة الجارية — لا بمفتاح API ثابت يمكن نسخه أو مشاركته أو تسريبه. مفتاح API يعرّف مستأجرًا؛ هوية عبء العمل تعرّف مهمة. الفرق مهم لأن الميزانيات والأغراض والإلغاءات خصائص مهام، لا خصائص مؤسسات.
ينبغي التعبير عن النطاق كمجموعة عمليات مسموح بها وبادئات موارد، لا كوصف نصي حر. "استرجع التوثيق تحت /docs/" قابل للإنفاذ. "مساعد بحثي" ليس كذلك.
ميزانية تزامن وطلبات بشروط الموقع
يجب أن تكون الميزانية مقوّمة بوحدات يتحكم بها الموقع، لا وحدات يفضّلها العميل. وهذا يعني:
- حدًا أقصى لعدد الطلبات الجارية، لا مجرد طلبات في الثانية؛
- مخصصًا إجماليًا للطلبات طوال عمر العقد، حتى لا تستهلك مهمة طويلة الأمد سعة غير محدودة بهدوء؛
- مخصصًا منفصلًا أصغر للعمليات المُغيّرة للحالة.
التعبير عن الميزانية بشروط الموقع هو ما يجعلها قابلة للدفاع. لا يمكن للعميل أن يحتج بأن مفهومه هو لـ "استعلام منطقي واحد" يجب أن يقابل خمسين نداءً صاعدًا.
انتهاء وإلغاء يعملان أثناء التشغيل
تنتهي العقود افتراضيًا. والأهم أنها قابلة للإلغاء أثناء سير المهمة، ويسري الإلغاء عند الحافة على الطلب التالي لا عند نافذة الإصدار التالية. هذا هو الجزء الذي تخطئ فيه معظم التطبيقات: تعامل القبول كبوابة لمرة واحدة عند إصدار الرمز، ما يعني أن عميلًا مسيئًا يحتفظ بوصوله حتى انتهاء صلاحية الرمز.
مقبض الإلغاء معرّف قصير يمكن للموقع إبطاله، بالإضافة إلى مستوى تحكم ينشر ذلك الإبطال إلى كل عقدة حافة. ويُتوقع من العميل التعامل مع الإلغاء كنتيجة طبيعية غير قابلة لإ
أنهِ العقد عند الحافة
قرارات القبول تنتمي إلى طبقة البوابة أو CDN، أمام خدمات الأصل. لا ينبغي أن ترى الأصول حركة غير متفاوض عليها؛ فبحلول وصول الطلب إلى خادم تطبيق يكون العقد قد فُحص، وخُفّضت الميزانية، وسُجّل القرار. هذا يُبقي الإنفاذ موحدًا عبر الخدمات ويمنع الفشل الشائع حيث يُحمى أصل فريق ولا يُحمى أصل آخر.
الحافة أيضًا هي المكان الوحيد ذو نقطة الرؤية الكافية لإنفاذ حدود التزامن، لأنها ترى كل الطلبات الجارية لهوية عبء عمل بصرف النظر عن الأصل الذي تستهدفه.
سجّل قرارات القبول كأحداث مُهيكلة
كل سماح ورفض وتقييد وإلغاء ينبغي أن يُصدر حدثًا مُهيكلًا يحمل هوية عبء العمل ومعرّف العقد وفئة العملية والسبب. الغاية هي قابلية التشخيص: ينبغي أن تبدو الإساءة كانتهاك سياسة بعقد مُسمّى، لا كطفرة حركة غير مفسّرة تستغرق ساعة لنسبها.
هذا يغيّر أيضًا الحوار التشغيلي. بدلًا من السؤال "لماذا ارتفعت الحركة؟"، يصبح السؤال "أي عقد تجاوز ميزانيته، وهل كان ذلك متوقعًا؟" — سؤال له مالك وجواب.
افصل الاسترجاع للقراءة فقط عن النداءات المُغيّرة للحالة
للقراءات والكتابات ملفات مخاطر مختلفة وينبغي أن تكون لها منح مختلفة. عقد استرجاع يمكن أن يكون واسعًا ورخيصًا وسهل الإلغاء. أما عقد يغيّر الحالة فيحتاج منحًا أقوى وميزانية منفصلة، ويُفضّل خطوة موافقة بشرية أو سياسية صريحة. الخلط بينهما هو كيف ينتهي وكيل كان يُفترض أن يلخّص صفحة بنشر إلى نقطة نهاية لأن بيانات الاعتماد التي حملها كانت مفرطة النطاق.
آلية ملموسة: أصدر رموزًا قصيرة العمر محددة النطاق بالعملية من العقد، واجعل الحافة ترفض أي طلب تقع طريقته ومساره خارج فئة العملية المُعلنة للرمز، حتى لو كانت هوية عبء العمل الأساسية صالحة.
ما لا يحلّه هذا
عقد القبول لا يجعل الوكلاء موثوقين. بل يجعلهم مسؤولين وقابلين للإيقاف. العميل الذي يكذب بشأن غرضه سيظل يكذب — الإعلان آلية تنسيق، لا حدود أمنية.
ولهذا بالضبط يكون مسار الإلغاء أهم من الإعلان. إذا كان الشيء الوحيد الفاصل بين عميل غير صادق والأصل هو سلسلة غرض مُبلّغ عنها ذاتيًا، فالنظام مسرح. أما إذا استطاع الموقع قطع عبء العمل أثناء التشغيل، ونسب القرار إلى عقد مُسمّى، ورؤية الانتهاك في سجلات مُهيكلة، يصبح الإعلان إشارة مفيدة لا افتراضًا حاملًا للحمل.
المقايضة الصادقة هي الاحتكاك. التفاوض على عقد يضيف خطوة إعداد، ويتطلب من العملاء حمل هوية عبء عمل، ويفرض على المواقع صيانة مستوى تحكم للإلغاء. المواقع التي تتخطاه ستستمر في استيعاب حركة الوكلاء كما لو كانت حركة ويب، وستستمر في اكتشاف أن العميل على الطرف الآخر لا يتعب.