الخلاصة

  • لا يعد RFC 5136 رقم السعة كاملاً من دون طبقة البروتوكول ونوع الحزم والطرفين ووقت البدء والفترة.
  • NomCap(L) حد فيزيائي نظري أعلى، وليس سعة IP التي يستطيع تدفق معين استخدامها.
  • تحسب سعة IP البتات في الحزم المستلمة بصورة صحيحة عند الوجهة، ولا تثبت أن التطبيق حصل على بيانات نافعة مكتملة.
  • يحدد Type P مجتمع الحزم لأن العلامات والصفوف وACL وسياسة التوجيه والموازنة قد تغير المعاملة والمسار.
  • الاستخدام هو حركة وصلت فعلاً؛ أما الاستغلال فهو الاستخدام مقسوماً على سعة محددة بالقيود نفسها.
  • السعة المتاحة هي الجزء غير المستخدم في [T,T+I]، وسعة المسار المتاحة هي أصغر هامش بين وصلاته.
  • الوصلة الأضيق صاحبة أصغر سعة ليست بالضرورة الوصلة الأشد صاحبة أصغر سعة متاحة.
  • القياس الذي يفقد T وI لا يصلح تلقائياً للمقارنة أو لإثبات الحالة الراهنة.
  • قد تتزامن دورية أخذ العينات مع حمل دوري فتكرر الانحياز بدلاً من علاجه.
  • النسخ المكررة والرؤوس والإعادات تستهلك الشبكة من دون أن تزيد بالضرورة البيانات الفريدة للمستخدم.
  • Bulk Transfer Capacity رؤية على طبقة النقل للبيانات الفريدة وتتفاعل مع الازدحام، ولا تساوي كميات IP في RFC 5136.
  • ينبغي فصل القدرة الفيزيائية ورصد IP والهامش الحالي والحق التعاقدي ونتيجة التطبيق في إيصالات مستقلة.

حد أعلى لا يقول كم بقي منه

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

يسمي RFC 5136 الحد الفيزيائي النظري NomCap(L). وظيفته تحديد سقف وفصل الطبقة الفيزيائية عن مقاييس IP. لا يدخل هذا الرقم تلقائياً في بقية التعريفات كأن كل بت فيزيائي صار بتاً متاحاً للتطبيق.

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

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

ما الذي تعترف به طبقة IP؟

يعرف RFC 5136 بتات IP بأنها ثمانية أضعاف عدد الثمانيات من أول رأس IP إلى آخر حمولة في الحزم التي استلمتها الوجهة D بصورة صحيحة بين T وT+I. وقت البداية وطول الفترة جزء من هوية النتيجة.

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

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

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

Type P يكشف السياسة المختبئة في القياس

لا تعامل الشبكة كل الحزم بين الطرفين بالطريقة نفسها. قد تختار العلامة صفاً مختلفاً، وتحجب ACL بروتوكولاً، وتنقل سياسة التوجيه المسار، ويوزع موازن الحمل التدفقات على وصلات أخرى. يصف Type P التدفق أو المجموعة التي يتناولها القياس.

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

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

يغير حجم الحزمة مقدار الحمل في الطبقات الأدنى. وقد يرسل ضغط الرأس بتات فيزيائية أقل، مع أن مقياس IP يعد الطول بعد الفك. لا يعني الفرق تعطل أحد العدادين؛ بل يعني أن التحويل بين الطبقات يجب أن يكون موثقاً.

السعة والاستخدام والهامش ثلاث حقائق

تعرف C(L,T,I) أكبر معدل لبتات IP من Type P يرسلها S وتستلمها D صحيحة عبر الوصلة خلال الفترة. وسعة المسار هي أصغر سعة بين وصلاته. وتسمى الوصلة التي تعطي هذا الحد الوصلة الأضيق.

أما Used(L,T,I) فهو الحركة الفعلية المستلمة من أي مصدر، وليس قيمة قصوى. والاستغلال Util هو Used/C. لذلك لا يكفي رقم 70 في المئة من دون معرفة المقام وطبقته ونوع حزمه وفترته.

السعة المتاحة للوصلة هي C*(1-Util)، وللمسار أصغر سعة متاحة بين الوصلات. هذه الوصلة هي الأشد. ويمكن لوصلة بطيئة قليلة الحمل أن تترك هامشاً أكبر من وصلة أسرع مزدحمة؛ عندئذ لا تكون الأضيق هي الأشد.

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

الزمن ليس زينة على الرسم

تتغير الحركة في مقاييس زمنية كثيرة، ولذلك تتقلب السعة المتاحة أكثر من السعة. يطلب RFC 5136 وقتاً وفترة، ويقترح سلسلة من القياسات. القياس المفرد ليس باطلاً، بل محدود النطاق.

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

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

نسخة ثانية تستهلك المورد ولا تضيف معلومة

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

يجب عندئذ تقييد Type P أو إضافة مقياس للوحدانية. الاحتفاظ بعمل الشبكة الخام والتسليم الفريد يكشف الخلل. أما الاحتفاظ بالمجموع وحده فيحول التكرار إلى أداء ظاهري أعلى.

تقيس Bulk Transfer Capacity في RFC 3148 بيانات فريدة عبر اتصال نقل يستجيب للازدحام، ولا تعد الرؤوس أو البيانات المعادة ضمن النافع. تؤثر الخسارة والتأخير وإعادة الترتيب وخوارزمية الاسترداد في النتيجة. وهذا منظور مختلف عن كميات IP في RFC 5136.

تضيف RFC 9097 لاحقاً طرقاً وإحصاءات لسعة IP أحادية الاتجاه، وتحدد RFC 9946 اختبار UDP مضبوطاً. تحسن هذه الأعمال قابلية إعادة القياس، لكنها لا تنشئ حجزاً أو حقاً للمشترك أو حكماً على SLA أو نجاحاً للتطبيق.

سلم الإثبات المطلوب

يبدأ الملف بالوسط ووضع الواجهة والتفاوض وNomCap(L). ثم يسجل المصدر والوجهة والمسار الكامل والوصلات. بعد ذلك يحدد الطبقة وType P والأحجام والعلامات وشروط الاستلام والأخطاء والتجزئة والنسخ. ثم يحفظ T وI والساعة وخطة العينات.

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

العقد إيصال آخر: المعدل الملتزم به وقواعد الاندفاع والنسب المئوية والاستثناءات وسلطة الحكم. ويقدم التطبيق البايتات الفريدة والسلامة والإعادات ووقت الإكمال والنتيجة. لا تستنتج هذه الحقول من RFC 5136.

اختلاف الإيصالات تشخيص مفيد. قد تكون الفيزياء سليمة ويضيق Type P، وقد تكون سعة IP عالية والهامش منخفضاً، وقد يكون الهامش جيداً وتفشل حلقة النقل، وقد يكتمل النقل بعد فوات القيمة العملية. لا يحكم لون واحد على السلسلة كلها.

تنسيق رفيع وإثبات محلي كثيف

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

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

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

يمكن للرقم على المنفذ أن يبقى صحيحاً. ما يمنعه RFC 5136 هو أن يتكلم باسم طبقات لم يرها.

المصادر

  1. RFC 5136 بصيغة HTML
  2. RFC 5136 بالنص الصريح
  3. سجل RFC Editor
  4. سجل IETF Datatracker
  5. تاريخ الوثيقة
  6. بحث التصحيحات
  7. RFC 1812
  8. RFC 2330
  9. RFC 2544
  10. RFC 3148
  11. RFC 4656
  12. RFC 6349
  13. RFC 6703
  14. RFC 7312
  15. RFC 8337
  16. RFC 9097
  17. RFC 9473
  18. RFC 9946
  19. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  20. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  21. Running-Code Primary