Кратко

  • RFC 2351 сопоставил TCP/IP два разных класса авиационного трафика: Type A допускал потерю и повтор после молчания, а Type B требовал защиты, нескольких адресатов и четырёх приоритетов.
  • Установленный TCP и принятая сессия MATIP доказывали совместимость транспорта. Они не доказывали бронирование места, выпуск билета, безопасность повтора или переход ответственности за конкретное сообщение.

В 1998 году сеть могла обновляться быстрее, чем работа, которую она обслуживала. TCP/IP становился дешёвым и привычным для интранетов, но тысячи авиационных офисов всё ещё использовали терминалы P1024B и P1024C и центральные приложения, выросшие из протоколов шестидесятых годов.

RFC 2351 предложил MATIP — Mapping of Airline Traffic over Internet Protocol. Спецификация не переписывала бронирование, билетные операции или сообщения. Она стандартизировала прослойку между TCP и авиационным приложением вместо множества несовместимых частных шлюзов. Общим стал путь передачи, но не правило, по которому работа считалась выполненной.

Для Type A молчание означало решение о повторе

Type A охватывал интерактивную связь офиса или турагентства с центральной системой бронирования и билетов. Трафик был срочным и приоритетным, но защищался ограниченно и мог быть отброшен. RFC указывал: если из-за потери нет ответа, пользователь может продублировать запрос.

Это не обещание идемпотентности любой операции. Повторная проверка свободных мест и повторная продажа дают разные последствия. RFC 2351 не ввёл общий идентификатор транзакции, журнал удаления дублей или процедуру сверки для всех приложений. Только система, видящая деловое состояние, могла решить, был ли второй запрос восстановлением, дублем или новым распоряжением.

MATIP сохранял контекст, позволяющий доставить поток этой системе. При открытии согласовывались подтип, кодировка, представление, заголовок и мультиплексирование. H1, H2, A1 и A2 могли определять терминальный узел независимо от IP-адреса; для связи между хостами применялся Flow ID. Эти поля выбирали контекст протокола, но не удостоверяли человека, полномочие на бронь или запись в центральной базе.

Type B нёс другую обязанность

Type B был сообщениями. Ему не требовалась такая же мгновенность, зато требовались высокая защита, несколько адресатов и четыре уровня приоритета. BATAP располагался над MATIP как протокол между приложениями для защиты Type B.

В Session Open поле PROTEC обозначало протокол сквозной передачи ответственности за сообщение. Несовместимые механизмы позволяли Open Confirm отклонить сессию. Отправителя и получателя можно было определить через HLD либо через пару IP-адресов.

Совпадение механизма ещё не является распиской. Одинаковый PROTEC говорит, что стороны понимают один способ передачи ответственности. Он не показывает, что BATAP принял данное сообщение, что все адресаты получили его или что ответственность действительно перешла. Это подтверждает приложение и его последующее состояние.

Порты разделяли потоки, а не закрывали сделку

Type A получил TCP-порт 350, Type B — 351. Для каждого набора параметров создавались отдельные соединение и сессия. Session Open объявлял свойства, Open Confirm принимал или отклонял их, Session Close закрывал MATIP. Собственного keep-alive не было; тайм-аут зависел от TCP.

Жизненные циклы были связаны, но не совпадали. Без TCP MATIP не мог оставаться открытым, однако закрытие MATIP не требовало закрывать TCP. Поэтому живое TCP-соединение не доказывало работоспособную авиационную сессию, а принятая сессия MATIP — завершённую бизнес-операцию.

RFC 793 определял TCP как надёжный упорядоченный поток байтов между процессами. RFC 1122 задавал требования к коммуникационным слоям хоста. Ни один слой не видел остаток мест, номер выпущенного билета или принятие ответственности получателем Type B.

Полная цепочка включает маршрут, установление TCP, MATIP Session Open, Open Confirm, разрешённый ASCU, Flow ID или HLD, доставку данных, подтверждение приложения, переход ответственности, фиксацию делового состояния и сверку повторов. Если убрать ступени, транспортному сигналу приписывается знание, которого у него нет.

Предупреждение о безопасности показало цену совместимости

RFC 2351 допускал статическую конфигурацию ASCU или имя пользователя и пароль, фильтрацию на уровне IP или приложения, а IPsec ESP и AH оставлял необязательными. Сейчас RFC Editor предупреждает: статические идентификаторы и, по-видимому, открытые пароли не дают надёжной защиты, а полноценный IPsec не был обязательным.

Это ограничивает MATIP, но не отменяет его. Шлюз решал миграцию и совместимость, не создавая криптографическую авторизацию из старой метки. RFC 4301 позже описал политики IPsec и Security Associations. Однако и там наличие возможности не доказывает защиту конкретного обмена без операционной записи.

Исторический урок RFC 2351 состоит в границе общей инфраструктуры. Унифицировать можно перенос байтов. Значение молчания, подтверждения и завершения остаётся у приложения, способного выдать соответствующую расписку.

Источники