الخلاصة

  • قسّم RFC 1025 التشغيل البيني إلى خطوات قابلة للملاحظة: فتح الاتصال، وتبادل البيانات، والإغلاق السليم، والتكرار من دون إعادة التهيئة، ثم الوصول إلى تطبيقات أخرى عبر بوابة.
  • رتّب نظام النقاط أدلة مفيدة، لكنه لم يحوّل نتيجة ناجحة إلى برهان على الصحة في كل الحالات، أو إلى ترتيب للأداء، أو إلى دليل على النشر الفعلي.

«الصحة» كانت لا تزال موضع نقاش

في سبتمبر 1987، نشر جون بوستل وثيقة قصيرة وصريحة على نحو لافت عن اختبار TCP وIP بينما كان البرنامجان والمواصفات لا يزالان في طور التطور. يوضح RFC 1025 أنه حين كان عدد التطبيقات قليلاً، لم تكن هناك وسيلة عملية للحكم على «صحة» تطبيق ما سوى اختباره مع تطبيق آخر، ثم مناقشة ما الذي أثبتته النتيجة. فقد يؤدي الاختبار إلى تعديل التطبيق، وقد تغيّر المناقشة المواصفة نفسها.

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

RFC 1025 مراجعة تاريخية، لا محضر تفصيلي لكل لقاء. تذكر الوثيقة قائمة مبكرة للاختبارات في IEN 69 الصادر في أكتوبر 1978؛ وعرضاً لأربعة تطبيقات TCP في ريستون يوم 4 ديسمبر من العام نفسه؛ ولقاء ستة تطبيقات في معهد علوم المعلومات بجامعة جنوب كاليفورنيا يومي 27 و28 يناير 1979؛ ثم لقاءً موزعاً عبر الشبكة في أبريل 1980. ويعيد نص 1987، مع تعديلات تحريرية طفيفة، نشر الإجراءات والاختبارات ونظام النقاط المستخدم في لقاء 1980. يكشف التسلسل عن ممارسة تشكلت عبر لقاءات متتابعة، لا عن امتحان رسمي وُضع بعد اكتمال البروتوكولات. RFC 1025، IEN 69، IEN 77

للمحادثة أكثر من مرحلة

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

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

جعلت الفئة المتوسطة الانتقال من الاختبار الذاتي إلى التشغيل البيني صريحاً. ففتح الاتصال وتبادل البيانات وإغلاقه مع TCP آخر تساوي نقطتين لكل خطوة؛ والتكرار من دون إعادة التهيئة أربع نقاط؛ وإتمام المحادثة عبر بوابة الاختبار عشر نقاط. ويشير RFC 1025 إلى أن هذه الفرص تتكرر مع كل TCP مختلف يتم الاتصال به، ويورد مثالاً يصل فيه الحد إلى عشرين نقطة لكل تطبيق آخر. كان الهدف اتصالاً من رتبة N تربيع: اختبار شبكة العلاقات الممكنة كلها، لا الاكتفاء بإثبات أن زوجاً اختير مسبقاً قادر على التواصل.

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

كان مسموحاً للبوابة أن تجعل الطريق أسوأ عمداً

أكثر الأدوات لفتاً للنظر في RFC 1025 هي «flakeway»: بوابة غير موثوقة عمداً، يمكن تعديل إعداداتها أثناء التشغيل لتحديد نسبة مخططات البيانات التي تُسقطها، أو تُتلفها ثم تمررها، أو تعيد ترتيبها قبل وصولها. الاسم طريف، لكن الغرض جاد. فقد أصبح الطريق نفسه جزءاً من التجربة. والاتصال الذي لا يصمد إلا عبر مسار نظيف يقدم دليلاً أضيق من تبادل يظل مستمراً حين تختفي بعض الحزم أو تتغير أو تصل بترتيب مختلف.

جعل شرط المجموع الاختباري التحايل على الاختبار أصعب. ينص RFC 1025 على وجوب تفعيل فحص المجموع الاختباري، ولا تُمنح أي نقاط إذا عُطّل. لا يمكن إيقاف الآلية المكلفة باكتشاف التلف ثم احتساب النتيجة على أنها نجاح.

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

وكانت هناك فئة IP منفصلة للمضيفين والبوابات. تناولت النقاط تجزئة مخططات البيانات وإعادة تجميعها، والتوجيه من المصدر، ومسار العودة، ونصائح التوجيه، ورسائل source quench، وإشارات الخدمة، والخيارات. كما كافأت كشف بوابة لا تخفض TTL، أو تمرر مخططاً بقيمة TTL تساوي صفراً، أو تسيء التعامل مع المجموع الاختباري. يعكس الفصل اختلاف العمل: يدير TCP محادثة بين المضيفين، بينما ينقل IP مخططات البيانات بين الشبكات المترابطة وعبر البوابات. RFC 793، RFC 791

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

مجموع النقاط له حدود

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

يعترف RFC 1025 بذلك في قسمه الأخير. فالاختبارات السابقة فحصت التشغيل الأساسي وبعض الحالات الصعبة، لكنها لم تتناول الأداء ولا تنفيذ الأفكار الأحدث آنذاك. وذكر النص إجراءات جون نيغل، وبدء الازدحام البطيء وقياسات زمن الذهاب والإياب لفان جاكوبسون، وإجراءات SQuID كمسائل منفصلة. ثم اقترح اختبارات أداء محتملة: نقل ملف حجمه ميغابايت واحد عبر FTP أو NETBLT على Ethernet أو ARPANET، وقياس زمن ذهاب وعودة حرف يُرسل إلى خادم Echo عبر TCP. وحذّر من أن هذه النتائج تعتمد كثيراً على بيئة الاختبار. RFC 896، RFC 862

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

كان الاختبار جزءاً من حياة البروتوكول العملية

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

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

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

المصادر