الرد الذي احتاج إلى سؤال لم يُجب عنه بعد

الخلاصة

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

كيف يُغلق طريق الرد على الرد؟

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

وصف RFC 1122، الصادر في أكتوبر 1989، هذا الخطر في مناقشة تفاوض بروتوكول المقاطع اللاحقة. لم تكن المعالجة زيادة مهلة أو عدد محاولات، بل تضييق السبب الذي يسمح بإرسال الإعلان: لا يُرسل ردا على جواب IP إلا إذا كان الجواب يحسم طلبا معلّقا، أي إن عنوان العتاد كان ما زال غير معروف عند استلامه.

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

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

حين وقفت الترويسة في طريق صفحة الذاكرة

ناقش RFC 893 في أبريل 1984 صيغة استخدمتها 4.2BSD UNIX وأنظمة أخرى في ذلك الوقت. الوثيقة معلوماتية، وتصرح بأنها ليست بروتوكولا رسميا لمجتمع ARPA Internet. موضوعها تحسين محلي مشروط ببيئة المستقبل.

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

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

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

ما الذي انتقل، وما الذي لم يتغير؟

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

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

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

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

فائدة المستقبل لم تكن مجانية للجميع

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

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

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

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

الجار لم يكن ملزما بالتحسين

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

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

في 1989 أصبح الشرط أكثر تحديدا في RFC 1122: الاستخدام اختياري، لكن لا بد من التحقق من دعم طرفي اتصال الوصلة، سواء كان الطرف مضيفا أم بوابة. وإذا لم يوجد تفاوض ديناميكي لكل وجهة، وجب أن يعطل الإعداد الافتراضي الصيغة.

لم تكن هذه حظرا على التحسين. كانت طريقة لإبقاء المسار العادي متاحا لمن لا يشارك فيه، بدلا من تحويل نجاح مجموعة متجانسة إلى افتراض عن جميع الجيران.

نجاح ARP لم يكن إعلان قدرة عامة

يفصل RFC 826 بين نوع إطار Ethernet الحامل لرسالة ARP، وحقل فضاء البروتوكول داخل ARP، ورمز العملية الذي يميز الطلب من الرد. هذه طبقات من المعنى لا يجوز جمعها في حقل واحد متخيل.

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

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

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

ويؤكد سياق البوابات في RFC 1009، الصادر في يونيو 1987، ضرورة إبقاء النطاق محليا. فقد تجيب بوابة في proxy ARP بعنوان واجهتها عن عنوان خارج الوصلة يمكنها توجيهه. من هنا لا يصح تحويل معرفة نظير Ethernet إلى ادعاء بأن الوجهة النهائية وكل المسار يفهمان تغليفا محليا معينا.

بعض الحزم كانت تكفي لإخفاء العيب

حذر RFC 1122 من أعراض مربكة عند غياب التوافق. الصيغة لا تُختار لكل الحزم، بل للحزم ذات خصائص حجم معينة. يمكن أن تصل حزم عادية بينما تختفي أخرى، فيبدو الاتصال موجودا ومتعطلا في آن واحد.

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

كما أن ترتيب الترويسات لا يزيد سعة Ethernet تلقائيا. حتى نص خط الأساس القديم يحتاج إلى قراءة مصححة: التصحيح 570، وحالته Verified، يصلح كلمة «الحد الأدنى» إلى «الحد الأقصى» عند ذكر 1500 بايت في RFC 894. وجود قدرة ترميز أو ترتيب بديل ليس إذنا بتجاوز حد الوصلة.

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