الخلاصة

  • في اختبار RFC 2348، انخفض زمن نقل ملف حجمه 2.25 ميغابايت من 23.85 إلى 4.90 ثانية على مسار بلا بوابة وسيطة عندما ارتفعت الكتلة من 512 إلى 8,192 بايت.
  • زاد حجم البيانات في الكتلة 16 مرة، لكن الزمن انخفض بنحو 80% فقط. وتحذر الوثيقة نفسها من كلفة التجزئة وإعادة التجميع حين تتجاوز الكتلة MTU المسار.

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

في مايو 1998، قدمت RFC 2348 خيار blksize القابل للتفاوض، مستندة إلى آلية الخيارات في RFC 2347. يضيف العميل الخيار إلى طلب القراءة أو الكتابة، وقد يرد الخادم برسالة OACK. لا يجوز للخادم قبول قيمة أعلى مما طلبه العميل، ولا أن يبدأ خياراً لم يطلبه الطرف الآخر. يستخدم العميل القيمة المؤكدة أو ينهي النقل. وإذا لم يفهم خادم قديم الخيار، أمكن للطرفين متابعة النقل العادي. كانت هذه إضافة تحافظ على التوافق، لا تغييراً مفروضاً على كل الأجهزة.

سمح الخيار بكتل تحتوي بين 8 و65,464 بايتاً من البيانات، من دون احتساب ترويسة TFTP ذات الأربعة بايتات. وقدمت RFC مثالاً بحجم 1,428 بايتاً عند حساب MTU لشبكة Ethernet بعد طرح ترويسات TFTP وUDP وIP. هذا مثال حسابي، لا قيمة صالحة لكل مسار. اتفاق طرفي TFTP على حجم لا يثبت أن كل وصلة أو نفق في الطريق يستطيع حمل رزمة IP الناتجة من دون تجزئة.

عرضت الوثيقة تجربة أولية بشروط محددة: جهازا HP-UX 9000، وشبكة Ethernet قليلة الازدحام، ونمط octet، وملفات حجمها 2.25 ميغابايت. كان كل رقم متوسط خمس عمليات نقل، مرة بلا بوابة وسيطة ومرة مع بوابة واحدة. عند كتل 512 بايتاً، سجلت 23.85 ثانية و37.05 ثانية على الترتيب؛ وعند 8,192 بايتاً، سجلت 4.90 و6.15 ثانية. أي إن الزمن انخفض إلى نحو 1/4.87 و1/6.02 من قيمته، بانخفاض يقارب 79.5% و83.4%.

لذلك تشير عبارة «16x» في المقارنة إلى نسبة حجم الكتلة: 8,192 مقسومة على 512. لا تعني أن النقل صار أسرع ستة عشر ضعفاً. ويتوافق انخفاض الزمن بنحو 80% مع متوسطات التجربة المنشورة. فحجم الكتلة وعدد الرزم والزمن الكلي مقاييس مختلفة. ومع ذلك كان التحسن ملحوظاً: الكتل الأكبر تقلل رزم البيانات والإقرارات وعدد مرات الانتظار وكلفة المعالجة لكل رزمة.

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

قدمت RFC 7440 لاحقاً خيار windowsize، الذي يسمح بإرسال عدة كتل قبل انتظار الإقرار. حجم الكتلة وعمق النافذة طريقتان مختلفتان لتغيير كلفة الانتظار. أما RFC 8900، التي جاءت بعد ذلك بزمن طويل، فتناقش هشاشة تجزئة IP في التشغيل؛ ولا تثبت أن تجربة 1998 فشلت. يكفي التحذير الأصلي: القيمة المتفق عليها لا تصادق على ملاءمة المسار كله.

الدرس التاريخي ليس أن الأكبر أسرع دائماً. أتاح RFC 2348 لبروتوكول بسيط أن يفاوض على وحدة نقل أنسب للشبكة، وأظهر مكسباً كبيراً ضمن ظروف معلومة، ثم حدد حد MTU الذي قد يغير النتيجة. الرقم ليس وصفة سحرية؛ بل بداية لقياس المسار الفعلي.

تجدون أساس TFTP في RFC 1350، وخياري المهلة وحجم النقل المنشورين في الفترة نفسها في RFC 2349. وهما يساعدان على فصل blksize عن بقية معاملات النقل القابلة للتفاوض.