كان سقوط الحزمة الرابعة حتميًا، لكنه لم يحسم نتيجة التجربة

الخلاصة

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

ما الذي قيس فعلًا؟

يبدو فارق 0.229 ثانية صغيرًا، لكنه يلخص حسابًا محددًا. فعندما وصلت المحاكاتان إلى حالتين متقاربتين، كان مسار الأربع حزم متقدمًا بمقدار 2.889 ثانية وثلاثة أرقام حزم. وقدّر المذكرة أن المودم يحتاج 2.66 ثانية لإرسال ثلاثة مقاطع TCP بحجم 1024 بايت. بعد طرح هذا الزمن، بقي تقدم يقارب 0.229 ثانية في معظم الحالات.

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

خط الأساس لم يتجنب الفقد إلى الأبد

في البدء المعتاد، تُرسل الحزمة الأولى عند الزمن صفر. يصل إقرارها بعد 1.222 ثانية، فيرسل المرسل الحزمتين الثانية والثالثة. وبعد إقرار لاحق عند 2.444 ثانية يرسل الحزمتين الرابعة والخامسة. ثم يؤدي الإقرار الثالث عند 3.278 ثانية إلى إرسال الحزمتين السادسة والسابعة. تُفقد الحزمة السابعة لاحقًا، وتؤدي ثالثة إشارة ACK مكررة عند 8.278 ثانية إلى إعادة إرسالها.

أما البدء بأربع حزم فيرسل الحزم من الأولى إلى الرابعة دفعة واحدة. تسقط الرابعة عند طابور الحزم الثلاث، ثم تؤدي ثالثة إشارة ACK مكررة عند 5.389 ثانية إلى إعادة إرسالها. عند نقطة المقارنة، تبدو الحالتان متقاربتين؛ وبعدها لا تختلف المسارات كثيرًا إلا بإزاحة 2.889 ثانية وثلاث حزم.

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

نموذج واضح الحدود

نشر RFC 2416 في سبتمبر 1998 بصفة Informational؛ فهو لا يحدد معيارًا. ويتكون المسار من وصلة بسرعة 100 ميغابت/ث بلا تأخير، ثم وصلة 1.5 ميغابت/ث بتأخير أحادي الاتجاه قدره 25 ملي ثانية، ثم وصلة مودم 9600 بت/ث بتأخير 150 ملي ثانية في اتجاه واحد. قبيل المودم، يستطيع الموجّه الاحتفاظ بثلاث حزم: واحدة قيد الإرسال واثنتان تنتظران.

استخدم الباحثان NS 1.2a2 من مختبر لورنس بيركلي الوطني، وقارنا وحدات Tahoe وReno وSACK وFACK، مع عرض مفصل لـTahoe. عوملت الحزمة على أنها 1024 بايت لحساب زمن الإرسال؛ أما الوحدات فاستخدمت أرقام الحزم ولم تحاكِ آليات أرقام التسلسل في TCP. كما جرت المراقبة قرب المرسل على الوصلة السريعة. هذه التفاصيل تجعل الاستدلال قابلًا للفحص، وتوضح في الوقت نفسه ما لم تختبره الدراسة.

تُستخدم هنا فكرتا Running-Code Primacy وReality Layers في ملاحظات Heng Lu كعدستين للتحليل، لا كإسناد تاريخي للتأليف. الأولى تفضل أثر التشغيل الفعلي على الحدس، لكنها تقصر دلالته على الشيفرة والمسار المختبرين. والثانية تفصل بين إسقاط حزمة في طابور، وزمن اتصال واحد، واستقرار الشبكة بأكملها. قدم RFC 2416 دليلًا محدودًا على المستويين الأولين؛ أما السلامة على مستوى الشبكة فتركها مؤلفوه مفتوحة وطلبوا إعادة التجربة باستخدام TCP ومودم وقيود تخزين حقيقية.

المصادر

• RFC 2416 — When TCP Starts Up With Four Packets Into Only Three Buffers
• RFC 2414 — Increasing TCP’s Initial Window
• RFC 2415 — Simulation Studies of Increased Initial TCP Window Size
• RFC 1122 — Requirements for Internet Hosts: Communication Layers
• RFC 3390 — Increasing TCP’s Initial Window
• RFC 5681 — TCP Congestion Control
• RFC 6928 — Increasing TCP’s Initial Window
• Heng Lu, “Running-Code Primacy”
• Heng Lu, “On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile”