الخلاصة

  • رفضت RFC 872 اعتبار TCP ثقيلاً على الشبكة المحلية بحكم طبيعتها السريعة وقلة أخطائها. حاجة التطبيق إلى اتصال موثوق ومرتب هي التي تحدد قيمة الخدمة.
  • أتاح Padlipsky مجالاً لاستخدام UDP أو خصائص الشبكة المحلية مباشرة حين تلائم المهمة؛ لكنه وضع في الحساب كلفة صيانة حزمة محلية موازية للاتصال خارج الشبكة.

السلك قصير، وTCP يبدو أحياناً كضيف حضر إلى غرفة مجاورة بحقيبة سفر كبيرة. في RFC 872 الصادرة في سبتمبر 1982، فتح Michael A. Padlipsky الحقيبة ليرى ما فيها. كانت حجة تتكرر: بروتوكول صُمم للعمل بين شبكات متعددة سيكون أثقل من اللازم داخل شبكة محلية سريعة. شبّه الكاتب الخوف بوحش متخيل تكبر قصته كلما اتبع الناس الآثار التي تركوها بأنفسهم. بقي في الغرفة حاسوبان وسلك ومهمة حقيقية تنتظر الإنجاز.

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

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

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

ترك النص مساحة للاختيار. تطبيق الصوت المرسل في رزم قد يفضل السرعة على الضمانات التي يقدمها TCP، ولذلك ذكر UDP. ويمكن لتطبيق محلي مصمم لغرض خاص أن يستخدم قدرات الشبكة القريبة بصورة مباشرة. ظهرت فاتورة أخرى حين تحتاج المؤسسة إلى بروتوكولات محلية منفصلة وتحتفظ أيضاً بـTCP/IP للتواصل خارجها. سيعيش على الحواسيب نفسها مجموعتان من الشيفرة والاختبارات ومهام الصيانة. الهروب من وحش رُسم على الورق قد يملأ الخزانة بأجهزة ومشكلات حقيقية.

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

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

تحتفظ RFC 872 بأسئلة مفيدة من جدل 1982: هل يحتاج البرنامج إلى ترتيب ووثوق وتحكم في التدفق؟ هل يجب أن يبلغ المضيف خارج الشبكة المحلية؟ أين ظهر الاختناق في القياس؟ حين تصبح الأسئلة محددة، يصغر الوحش بسرعة.