الخلاصة

  • أعطى RFC 1146 كل طرف فعلًا مستقلًا: يضع المرسل خيار Alternate Checksum Request، من النوع 14، في SYN؛ ولا تتغير الجلسة إلا إذا احتوى SYN الآخر على النوع نفسه والخوارزمية نفسها بالضبط. الغياب أو الاختلاف يعيدان الاتصال كله إلى checksum TCP القياسي.
  • بقيت رسائل SYN وRST محمية بالطريقة القياسية حتى بعد الاتفاق. وكانت القيمة الطويلة تحتاج خيارًا ثانيًا، النوع 15، في المقاطع العادية. سجل RFC 4614 ضعف الاهتمام، ثم نقل RFC 6247 الوثيقة إلى Historic وطلب وسم الخيارين بأنهما obsolete.

صاحب اللغة المشتركة

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

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

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

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

المقترح لا يملك قرار الطرف الآخر

خصص RFC 1146 للخيار Alternate Checksum Request رقم النوع 14 وطولًا قدره ثلاثة octets. يحمل الحقل رقم الخوارزمية: صفر للـchecksum القياسي، وواحد لـ8-bit Fletcher الذي ينتج 16 بتًا، واثنان لـ16-bit Fletcher الذي ينتج 32 بتًا.

يمكن للطرف الأول أن يطلب، لكنه لا يستطيع فرض الاختيار. يضع الخيار في SYN الذي يرسله. ولكي يُستخدم البديل، يجب أن يتضمن SYN المرسل في الاتجاه الآخر النوع 14 نفسه ورقم الخوارزمية نفسه. لا يكفي أن يعرف الطرفان قائمة الخوارزميات؛ يجب أن يلتقيا على قيمة واحدة في هذه المصافحة بعينها.

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

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

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

للمستجيب فعل مستقل أيضًا

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

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

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

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

حتى بعد الموافقة بقيت رسائل لا تتغير

لم يسمح RFC 1146 للخوارزمية البديلة بأن تستولي على كل مقطع. يجب أن تستخدم SYN وRST دائمًا checksum القياسي. SYN هو موضع الإعلان؛ يجب أن يكون مفهومًا قبل وجود الاتفاق. أما RST فقد يصدر من طرف لا يملك حالة اتصال، ولذلك لا يمكن افتراض أنه استعاد نتيجة تفاوض سابقة.

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

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

هذا التفصيل مهم عند قراءة الدليل التاريخي. عدّ المقاطع القياسية لا ينفي الاتفاق، وعدّ خيار 14 لا يثبته. يجب ربط نوع المقطع واتجاهه ومرحلة الجلسة.

الخوارزمية الأطول استأجرت مساحة في كل مقطع

كانت نتيجة 8-bit Fletcher بطول 16 بتًا، لذلك أمكن وضعها في حقل checksum الموجود أصلًا. أما 16-bit Fletcher فكانت نتيجته 32 بتًا. وضع RFC 1146 الجزء A في الحقل القياسي، وخصص Alternate Checksum Data، النوع 15، لحمل الجزء B في المقاطع المناسبة.

لم يكن النوع 15 رسالة تفاوض أخرى. كان تكلفة متكررة في مسار البيانات بعد اتفاق النوع 14. يحتاج كل مقطع عادي يستعمل النتيجة الطويلة إلى مساحة خيار ومعالجة متسقة. ويجب ألا يظهر هذا الخيار عندما لا تكون الخوارزمية المتفق عليها ذات 32 بتًا.

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

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

ما الذي تثبته الأرقام في السجل؟

ما زالت سجلات IANA لمعاملات TCP تحتفظ بالنوعين 14 و15 بوصفهما متقادمين، وتحتفظ بسجل خوارزميات Alternate Checksum: صفر للقياسي، واحد واثنان لصيغتي Fletcher، وثلاثة لـRedundant Checksum Avoidance.

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

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

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

من تجربة منشورة إلى هامش تاريخي

استند الحساب إلى تقاليد موثقة أوسع. يعرض RFC 1071 خصائص وحيل تنفيذ Internet checksum القياسي. لكنه لا يمنح RFC 1146 دليل نشر، كما أن errata المتعلقة ببعض أمثلة التنفيذ فيه سبب إضافي لعدم تحويل مثال برمجي إلى حجة عن نجاح التجربة.

نشر RFC 1146 في مارس 1990 بوصفه Experimental، وصرح بأنه لا يوصي باستخدامه في أنظمة الإنتاج. كانت الوثيقة اقتراحًا قابلًا للاختبار، لا انتقالًا إلزاميًا للإنترنت.

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

وفي 2011، نقل RFC 6247 RFC 1146 إلى الحالة Historic وطلب من IANA وسم نوعي الخيار 14 و15 بأنهما obsolete. وذكر أن الآلية لم تشهد انتشارًا واسعًا. أما مناقشته الأمنية التفصيلية حول spoofing فكانت تخص T/TCP، لا Alternate Checksum؛ لا ينبغي استعارة سبب تقاعد آلية ونسبه إلى الأخرى.

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

الرجوع الآمن كان أيضًا احتكاك التبني

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

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

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

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

المصادر