Кратко

  • Заголовок TPKT содержит версию, резервное поле и полную длину; он позволяет отделить один TPDU от следующего в потоке TCP.
  • Такое кадрирование не доказывает личность, целостность данных, право на действие, владельца порта или успешный результат приложения.

RFC 793 определяет TCP как непрерывный поток октетов. Поэтому один read может вернуть часть объекта либо несколько объектов, а границы TCP-сегментов не являются границами для прикладного протокола.

В 1987 году RFC 1006 зафиксировал узкое решение для ISO Transport class 0 поверх TCP/IP. TPKT — пакет переменной длины: постоянный заголовок и TPDU. В заголовке четыре октета: 8-битное поле version, 8-битное reserved и 16-битное packet length. Для версии 3 значение version всегда равно 3; длина включает сам заголовок и допускает от 7 до 65 535 октетов.

Приёмник сначала буферизует четыре октета, затем ждёт ровно объявленный остаток и только после этого передаёт TPDU транспортному разборщику. Один TPKT может прийти частями, несколько могут прийти вместе. Четырёхоктетная ширина рисунка в RFC — типографика, а не требование кратности длины четырём; правило задаёт поле длины.

RFC 1006 стала STD 35, заменила RFC 983 и резервировала TCP port 102 для хостов, реализующих стандарт. Её цель — предложить службу ISO Transport через носитель TCP/IP, чтобы верхние слои ISO не знали о нижнем носителе. Это не построение сетевого слоя OSI под TCP. Наблюдение порта не называет оператора, а правильно прочитанный TPKT не аутентифицирует сторону и не утверждает, что полезная нагрузка принята.

RFC 2126 обновила отображение в 1997 году: сохранила форму TPKT, уточнила class 0 для существующей базы RFC 1006 и добавила class 2 поверх TCP. Её граница безопасности ясна: протокол не более и не менее безопасен, чем TCP и ISO 8073. Факт полного TPDU — это факт разбора транспорта, не факт бизнес-операции.

Источники и границы доказательств