الخلاصة

  • تسبق TPKT وحدة TPDU بحقول الإصدار والمحجوز والطول الكلي، فيعرف المستقبِل أين ينتهي السجل في تيار TCP.
  • هذا فصل للسجلات، لا دليل على هوية أو سلامة أو تفويض أو نجاح تطبيق.

RFC 793 يصف TCP كتيار مستمر من octets. قد تصل قطعة من سجل في قراءة واحدة، أو سجلات عدة؛ ولا يجوز جعل حدود مقاطع TCP حدوداً للرسالة. RFC 1006 في 1987 لم يغيّر تلك القاعدة، بل وضع طبقة تأطير للنقل ISO class 0 فوقها.

يتكون TPKT من ترويسة ثابتة ثم TPDU. الترويسة أربعة octets: version من 8 بتات، reserved من 8 بتات، وpacket length من 16 بتاً. في version 3 تكون قيمة الإصدار 3؛ والطول هو طول TPKT كله بما فيه الترويسة، من 7 إلى 65,535 octets. يجمع المستقبِل أول أربعة بايتات، ينتظر العدد المعلن، ثم يسلم TPDU للمعالجة. الرسم بعرض أربعة بايتات أسلوب عرض فقط، وليس شرطاً أن يكون طول الحزمة مضاعفاً لأربعة.

كانت RFC 1006 هي STD 35، وأبطلت RFC 983، وحجزت TCP port 102 للمضيفين الذين ينفذون المعيار. الغاية هي تقديم خدمة النقل ISO عبر حامل TCP/IP كي لا تعرف الطبقات ISO الأعلى الحامل الأدنى. لا يعني ذلك أن RFC أعادت إنشاء شبكة OSI تحت TCP؛ ولا أن ملاحظة port 102 تثبت مالك خدمة أو أن طولاً صحيحاً يثبت ثقة في الحمولة.

حدّثت RFC 2126 المعيار عام 1997، فاحتفظت بصورة TPKT، وصقلت class 0 للقاعدة المركبة، وأضافت class 2 فوق TCP. وتضع حد الأمن بوضوح: ليست أكثر أو أقل أمناً من TCP وISO 8073. يمكن للمحلل أن يثبت أن TPDU اكتمل، لكنه لا يثبت أن مستخدماً صودق عليه أو أن طلباً نُفّذ.

لذلك يجب أن يبقى سجل الاتصال TCP، والبايتات المؤقتة، وترويسة TPKT، والطول، ونتيجة TPDU، ونتيجة التطبيق أدلة منفصلة. قيمة الآلية أنها لم تدّعِ غير ذلك.

المصادر وحدود الإثبات