الخلاصة
- اقترحت RFC 1106 إشعار NAK استشارياً ونافذة استقبال TCP بعرض 30 بت. وقالت إن الامتدادين نُفذا وأثبتا العمل باستخدام موارد ناسا، لكنها وصفتهما بالتجريبيين ولم تقترحهما معياراً للإنترنت.
- بينت RFC 1110 بعد شهرين شرطاً غاب عن النجاح المحدود: كبرت النافذة وبقي فضاء التسلسل 32 بت، فأمكن إعادة استعمال الرقم بعد أربع رحلات ذهاب وإياب وقبول نسخة قديمة بوصفها حالية.
- لم يثبت NAK سوى فجوة رآها المستقبل. لم يميز التأخر من الفقد النهائي، ولا الضوضاء من الازدحام، ولم يثبت إعادة الإرسال أو التعافي أو الوصول.
كان نطاق النجاح مكتوباً بجواره
نشر R. Fox وثيقة RFC 1106 في يونيو 1989. قالت فقرة الحالة إن امتدادين لـTCP نُفذا وأثبتا العمل باستخدام موارد ناسا. وفي الفقرة نفسها سُميا بروتوكولاً تجريبياً ونقطة بدء للبحث، لا اقتراحاً لمعيار إنترنت.
يمكن إبقاء العبارتين بلا تناقض. اشتغل الكود في بنية محددة، وتفاوض طرفان على حالة، وظهرت قياسات. أثبت ذلك التنفيذ تحت الشروط المرصودة، لا كل حالة تسمح بها شبكة واسعة تخزن الحزم وتمررها.
ذكرت الخلاصة بنفسها ما بقي مفتوحاً: الازدحام في مقابل الضوضاء، ومدى صلاحية الامتدادين للإنترنت كله لا لبيئة قمر اصطناعي معزولة فحسب. حذف هذه الحدود لا يختصر النتيجة، بل يوسع الادعاء من دون مشاهدة.
تسجل صفحة RFC Editor الحالية الحالة Historic والمسار Legacy، ويحفظ IETF Datatracker السجل. تصف هذه البيانات السلطة والتبني اللاحقين؛ ولا تنفي أن تنفيذاً محدوداً وقع.
رأى المستقبل الغياب ولم ير سببه
أراد NAK تقليل انتظار المؤقت العادي في المسارات الطويلة. عندما تكشف حزمة لاحقة فجوة في التسلسل، يطلب المستقبل البيانات اللازمة لتحريك الحافة اليسرى للنافذة قبل أن يفرغ مسار القمر الاصطناعي من البيانات.
لكن RFC 1106 أقرت بأن المستقبل لا يستطيع معرفة ما إذا كانت البيانات الغائبة متأخرة أم ضائعة إلى الأبد. قد يصلح الطلب خسارة حقيقية، وقد يصنع نسخة إضافية من حزمة لا تزال في الطريق.
كان NAK استشارياً وغير موثوق، ولا يعاد إرساله. يستطيع المرسل تجاهله أو إعادة البيانات فوراً؛ وإذا ضاع الإشعار بقي التعافي العادي لـTCP. لذلك لا تعني عبارة أُرسل NAK أن الفقد تأكد، أو أن المرسل تصرف، أو أن التعافي والاتصال اكتَملا.
ولا تحدد الفجوة السبب. فالضوضاء، وإسقاط الطابور، وإعادة الترتيب، والتأخر الطويل تنتج المنظر المحلي نفسه. رؤية ما لم يصل لا تمنح رؤية المسار كله.
أعلنت النافذة ذاكرة الطرف لا سعة الطريق
حدّت نافذة 16 بت البيانات غير المؤكدة عند 64 KiB. في مسار مرتفع حاصل ضرب السعة في التأخر لا تكفي هذه الكمية لإبقاء البيانات جارية. أبقت RFC 1106 البتات الدنيا في رأس TCP وحملت العليا في option لتكوين نافذة 30 بت.
كان على الطرفين الاتفاق في SYN وSYN-ACK، ثم تحمل كل حزمة الجزء الأعلى. يثبت الاتفاق أن تطبيقين يفسران التمثيل نفسه؛ ولا يثبت أن فضاء التسلسل وعمر الحزمة وإعادة الترتيب آمنة في كل طريق.
كما أن نافذة الاستقبال ليست عرض النطاق. إنها مقدار ما تسمح به ذاكرة المستقبل وسياسته. حذرت RFC 1106 من أن قيمة كبيرة اعتباطية قد تستنفد الذاكرة أو تعطل أعمالاً أخرى أو تسقط الجهاز. وكان تقييد النوافذ الكبيرة ببرامج محددة باستخدام موارد ناسا إدارة محلية للذاكرة، لا منحة سعة عبر الشبكة.
عاد الرقم بعد أربع رحلات بدلاً من 65,536
في أغسطس نشر A. McKenzie وثيقة RFC 1110. يستطيع الإنترنت فقد الحزم وإعادة ترتيبها ونسخها. وتدور أرقام تسلسل TCP ذات 32 بت؛ كانت النافذة الصغيرة وحد عمر الحزمة يجعلان الرقم فريداً عملياً قبل أن تختفي البيانات القديمة.
حسب نموذج RFC 1110، جعلت نافذة 16 بت إعادة استعمال الرقم بعد 65,536 رحلة ذهاب وإياب. أما نافذة 30 بت مع فضاء التسلسل نفسه فاختصرت المدة إلى أربع. ويمكن لـNAK إنتاج نسخة بعد رحلة واحدة. فإذا بقيت الحزمة القديمة نحو خمس رحلات، قد تعود حين يقع رقمها داخل دورة أحدث وتُقبل بيانات الماضي على أنها الحاضر.
لم تقل المذكرة إن التجربة لم تقع. بل افترضت أن شبكة قمر اصطناعي معزولة قد تكون بلا ذاكرة: تسلم بالترتيب أو تفقد، ولا تحتفظ بالحزمة ثم تعيدها متأخرة. في ذلك العالم لا يظهر الخلل. يسمح الإنترنت العام بحالات أكثر، ولهذا فشل التعميم لا القياس السابق.
فصل السجل اللاحق العيب عن التبني والحلول الأخرى
صنفت RFC 4614 لاحقاً RFC 1106 معيبة للاستخدام العام، وRFC 1110 خافضة لمكانتها، وقالت إن المجتمع الأوسع لم يتبن الخيارات. أما استعمال NAK في SCPS-TP فظل استثناء محدوداً لا تبنياً للحزمة كلها.
نقلت RFC 6247 الوثيقتين رسمياً إلى Historic عام 2011 ضمن امتدادات لم تشهد استعمالاً واسعاً. «غير واسع» لا تساوي «لم يُنفذ قط».
وزعت RFC 7323 المسائل المتقاربة: Window Scale عرض يتفاوض عليه في SYN؛ ويصف SACK المقاطع الموجودة والمفقودة؛ وتحمي timestamps وPAWS من النسخ القديمة بعد دوران التسلسل. لا يثبت ذلك نسباً مباشراً إلى RFC 1106، لكنه يثبت أن النافذة ودليل الفقد وصلاحية البيانات ليست حالة واحدة.
كان وصف البيئة جزءاً من مادة الإثبات
يحفظ الاختبار الصالح للمراجعة نسخة التنفيذ، والبنية، ونموذج الخطأ، وحدود الذاكرة، والنوافذ، وسرعة دوران التسلسل، وأقصى إقامة للحزمة، وإعادة الترتيب والنسخ، وحركة البيانات ونقاط الرصد. ويحفظ أيضاً الحالات التي لم تُختبر.
إن بقيت كلمة «نجح» وحدها، انتقلت النتيجة خارج ولايتها. وإن بقيت Historic وحدها، اختفى تنفيذ حقيقي. قيمة RFC 1106 وRFC 1110 معاً أنهما تحفظان ما حدث وما لم يثبته ذلك الحدث من دون خلط.
المصادر
- RFC 1106 — TCP Big Window and NAK Options
- صفحة RFC Editor الخاصة بـRFC 1106
- IETF Datatracker — RFC 1106
- RFC 1110 — A Problem with the TCP Big Window Option
- صفحة RFC Editor الخاصة بـRFC 1110
- RFC 4614 — خارطة وثائق مواصفات TCP
- RFC 6247 — نقل امتدادات TCP غير المنتشرة إلى Historic
- RFC 7323 — TCP Extensions for High Performance
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
