الخلاصة

  • جعل RFC 2414 نافذة TCP الابتدائية الأكبر اختيارية، بحد min(4*MSS, max(2*MSS, 4380 bytes)). تناول أول إرسال في اتصال جديد، لا كل استئناف بعد الخمول ولا نافذة ما بعد الفقد.
  • كان الرهان أن المقطع الثاني قد يستجلب إقراراً قبل مؤقت الإقرار المؤجل. وفي حالات كثيرة ضمن النموذج، سجلت محاكاة ns-2 في RFC 2415 انخفاضاً في وسيط زمن صفحات الويب.
  • لم تمنح نتائج المجموعات المختلطة حكماً واحداً. عند أحمال متوسطة لم يضر IW=3 بمجموعة IW=1؛ أما عند 32/32 من عملاء الويب في حالة ازدحام شديد، فتضررت مجموعة النافذة الأكبر نفسها.
  • كانت تلك محاكاة، لا مسحاً لانتشار التقنية على الإنترنت. سرعة الاتصال المفرد وكيفية توزيع الأثر على مسار مشترك سؤالان مختلفان.

الإقرار الأول هو المكسب

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

لم يفرض RFC 2414 أربعة مقاطع على كل اتصال. فقد رفع الحد المسموح به إلى min(4*MSS, max(2*MSS, 4380 bytes)) في وثيقة تجريبية نُشرت في سبتمبر 1998، وقال إن TCP MAY يستخدم القيمة الأكبر. وبحسب MSS، قد يعني الحد مقطعين أو ثلاثة أو أربعة. انطبقت القاعدة على النافذة الابتدائية بعد المصافحة الثلاثية. وظلت نافذة الفقد مقطعاً واحداً، وعولج الاستئناف بعد خمول طويل في قاعدة اختيارية منفصلة. كان ذلك اختباراً محدوداً، لا إذناً بتكبير كل نافذة كلما سكت الاتصال.

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

احتفظت المحاكاة بأكثر من مقياس

اختبرت RFC 2415، وهي وثيقة معلوماتية مصاحبة وليست تقرير انتشار ميداني، الخلاف باستخدام ns-2. وضع النموذج عنق زجاجة بسرعة 1.5 ميغابت/ثانية وزمن ذهاب وإياب 50 مللي ثانية، وروابط أسرع حوله. واختبر 8 أو 16 أو 32 عميل ويب، وما يصل إلى ثلاث عمليات FTP طويلة، ونوافذ ابتدائية من مقطع إلى أربعة مقاطع بحجم 1460 بايت. استخدم نموذج الويب صفحات صغيرة فيها ثلاثة عناوين مضمنة وطلبات لاحقة بفواصل عشوائية، بينما نقل FTP ملفات بحجم ميغابايت. أتاح ذلك مقارنة مضبوطة، لكنه حدد أيضاً نطاق ما تستطيع النتيجة إثباته.

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

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

يختلف هذا الدليل عن أثر الاتصال الواحد ذي المخازن الثلاثة في RFC 2416، الذي غطته مادة سابقة. تتناول RFC 2415 تدفقات عديدة داخل نموذج وعنق زجاجة مشترك وكيف يتغير الناتج مع تركيبتها. ولا تثبت أي من المحاكاتين سلوك الأجهزة الفعلية عبر الإنترنت كله، ولا تضع مقياساً عالمياً للإنصاف. لاحقاً، استبدل RFC 3390 RFC 2414 بحد اختياري ضمن مسار المعايير؛ وسجل RFC 5681 القاعدة، ثم بحث RFC 6928 تجريبياً بدءاً بعشرة مقاطع. لا تحول سلسلة النشر بأثر رجعي نموذج 1998 إلى إحصاء للانتشار الفعلي.

تُستخدم ملاحظة هينغ لو Running-Code Primacy هنا كضابط للأدلة فقط: إبقاء الآلية والنظام المختبَر فعلياً في الصورة. وتدعو On Reality Layers إلى عدم دمج زمن الصفحة وفقد الطابور واستنتاج يخص شبكة بأكملها في ملاحظة واحدة. لا تقدم الملاحظتان دليلاً تاريخياً عن TCP؛ المصادر هي RFCs نفسها.

المصادر