Summary

  • RFC 1692 предложил TMux для упаковки коротких сегментов Telnet и Rlogin с одним адресатом в общий IP-пакет, чтобы снизить число пакетов и нагрузку от прерываний.
  • Внешний пакет с номером протокола 18 скрывал внутренние TCP-порты от маршрутизатора, который фильтровал по портам. RFC предписывал такому устройству разбирать пакет или блокировать TMux. RFC 4450 позже перевёл документ в Historic.

Человек нажал одну клавишу на терминале. Сервер отправил короткий пакет. Когда десятки терминалов разговаривают с одним хостом, канал может передавать немного байтов, а хост всё равно занят приёмом отдельных пакетов. Авторы RFC 1692 в августе 1994 года сравнили работу по обработке пакета с одним октетом данных и пакета с 1500 октетами: для хоста она почти одинаковая. Узким местом они считали пакеты в секунду, а не только биты.

Peter Cameron, David Crocker, Danny Cohen и Jon Postel предложили упаковывать несколько коротких транспортных сегментов между одной парой хостов в общую IP-датаграмму. Перед каждым сегментом TMux ставил четырёхоктетный заголовок с длиной, исходным протоколом и проверкой самого заголовка. Снаружи IP сообщал номер протокола 18. Получатель раскрывал пакет и отдавал части TCP или UDP в привычном виде. Само приложение не обязано было знать о совместной поездке.

Для заполнения пакета нужен был короткий сбор. Первый сегмент запускал таймер, остальные успевали присоединиться до отправки. RFC предлагал настраиваемые 20–30 миллисекунд и считал примерно одну десятую секунды вероятным пределом, чтобы не испортить отклик терминала. Полный буфер отправлялся сразу. Крупные сегменты, например больше 700 октетов, лучше было не задерживать ради упаковки. Если в каждом пакете оказывался один сегмент, экономия превращалась в лишнее ожидание.

Отправитель должен был удостовериться, что получатель понимает новый формат. Валидный встречный TMux-пакет служил свидетельством; начать обмен можно было пустым запросом ENQ с протоколом 18. Без ответа интервалы повторения росли, а обычные IP-пакеты продолжали идти. Запомненная способность имела срок действия: перезагрузка хоста могла изменить его поведение. Отправка могла переключаться между двумя форматами по ходу общения.

Скрытая цена обнаружилась в разделе о безопасности. Фильтр маршрутизатора, настроенный по TCP-порту, видит протокол 18, а не порты отдельных сегментов внутри. Большой сегмент того же TCP-соединения может пройти обычным IP/TCP-пакетом и попасть под другое правило. RFC 1692 требовал от маршрутизатора с портовым фильтром, который не умеет разбирать TMux, блокировать его в обоих направлениях. Устройство, понимающее формат, могло проверить каждый вложенный сегмент и удалить запрещённые.

TMux опубликовали как Proposed Standard. В ходе пересмотра старых предложений в 2004–2005 годах обсуждали, будут ли разработчики создавать или поддерживать реализации. RFC 4450 включил TMux в перечень документов, переведённых в Historic; такой статус указан и у RFC Editor. Сокращение числа пакетов и потеря видимости портов были двумя сторонами одной технической операции.

Источники