Кратко

  • TCPMUX выбирал службу уже после установления соединения с TCP-портом 1. Клиент передавал имя, получал согласие и продолжал разговор по выбранному протоколу в том же соединении.
  • Частной службе не требовался собственный официально выделенный порт, однако сохранялись общие правила имён и обязательство не закрывать прежние порты существующих служб.
  • inetd мог отправить положительный ответ вместо вызываемой программы. Поэтому принятие выбора нельзя считать доказательством аутентификации, исправности приложения или завершённой операции.

Один номер, за которым ещё предстоит выбрать программу

Номер порта обычно воспринимается как достаточно точный ответ на вопрос, с какой службой начнётся разговор. TCPMUX добавлял ещё один шаг. После установления TCP клиент сообщал имя, и только затем узел решал, какой программе передать соединение. Транспорт уже работал, а прикладной собеседник ещё не был выбран.

Такой порядок закрепил M. Lottor в RFC 1078, опубликованном в ноябре 1988 года. TCP Port Service Multiplexer принимал соединения на порту 1. Имя службы не зависело от регистра букв и завершалось возвратом каретки и переводом строки. Ответ начинался с положительного или отрицательного знака, мог содержать пояснение и также заканчивался границей строки.

Положительный ответ открывал разговор по указанному протоколу. Отрицательный приводил к закрытию соединения. Сервер не выдавал новый номер, по которому клиент должен был соединиться заново. Уже созданный поток TCP становился потоком выбранного приложения.

Это важно для смысла слова «мультиплексор». Спецификация не вводила несколько параллельных прикладных потоков внутри одного соединения и не описывала чередование их сообщений. Множество служб делило точку входа; каждое соединение выбирало одну из них. Речь шла о распределении входящих разговоров, а не о совмещении нескольких разговоров в одном.

Какую задачу решала общая нумерация

Известный контактный порт полезен именно потому, что клиент может не знать внутреннего устройства удалённого узла. Независимые реализации договариваются о значении номера, и для обращения к знакомой службе не нужен отдельный обмен сведениями с каждым оператором. Общая таблица сокращает неоднозначность.

RFC 1010, выпуск Assigned Numbers за май 1987 года, прямо упомянутый в RFC 1078, показывает эту практику. Он фиксирует назначения и указывает контакт для разработчиков, которым требуются новые номера. Таблица описывает согласованные значения, но не удостоверяет состояние конкретного процесса на конкретной машине.

В предложении TCPMUX диапазон общеизвестных портов той эпохи указан как 0–255. Это не означает, что поле порта TCP могло представить только 256 значений. Административно выделенная группа контактных номеров и весь числовой диапазон транспортного протокола — разные вещи. Историческую границу также нельзя автоматически переносить в современную классификацию.

Для частного протокола отдельное официальное назначение могло быть избыточным. Если его участники уже могли согласовать имя, общий вход позволял перенести следующий выбор внутрь узла. Имя связывалось с локальной программой, не требуя каждый раз нового глобального контактного номера.

При этом не исчезали ни общий порт, ни правила разговора, ни полномочия оператора машины. Нужно было включить приём соединений, настроить программу и её права, обеспечить допустимый сетевой путь. Клиенту требовалось понимать последующий протокол. Локальность означала ограниченный масштаб решения, а не отсутствие условий для его исполнения.

Совместимость с теми, кто не выбрал новый вход

RFC 1078 оставлял прежним службам их двери. Если службе уже выделен отдельный порт, она должна продолжать работать на нём. Доступ через TCPMUX можно добавить, но нельзя незаметно подменить им существующий путь. Новая возможность не превращала старых клиентов в обязанных участников.

Техническая причина проста. Старый клиент мог ждать приветствия сервера сразу после соединения. TCPMUX, напротив, сначала ждал имени от клиента. Замена номера назначения сама по себе не меняла порядок реплик. Два работающих конца могли ждать друг друга, потому что они ожидали разные начала разговора.

Сохранялись и значения имён, перечисленных в Assigned Numbers. Частным протоколам рекомендовались имена с малой вероятностью совпадения, например с названием организации в начале; версии можно было различать суффиксом. Такое оформление помогает избегать случайных конфликтов, но не подтверждает права на организацию и не проверяет владельца домена.

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

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

Положительный ответ за чужой подписью

Самое выразительное различие видно в руководстве NetBSD по inetd. Полученное имя ищется в таблице, заданной /etc/inetd.conf. При форме tcpmux/ положительный ответ должна отправлять вызываемая серверная программа. При форме tcpmux/+ его отправляет мультиплексор вместо неё.

Второй вариант позволяет подключать старые программы, использующие стандартный ввод и вывод, без добавления специальной начальной реплики TCPMUX. Для оператора это удобная адаптация. Для исследователя сетевой записи — предупреждение: один и тот же знак может исходить от разных участников процесса передачи.

Если ответ дал распределитель, он ещё не свидетельствует, что конечная программа обработала хотя бы один содержательный запрос. Но и ответ самой программы не равен завершению работы. Впереди могут оставаться проверка пользователя, разбор команды, отказ по правилам приложения или ошибка при выполнении. Выбор службы и итог операции нужно наблюдать отдельно.

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

Исходный текст руководства FreeBSD по inetd уточняет ещё одну границу: помимо отдельных служб требуется включить сам мультиплексор. Наличие строки с программой не означает, что общий вход уже принимает запросы. Руководство также описывает передачу соединения через дескрипторы ввода и вывода программы.

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

Осторожность при чтении поздних следов

Нумерация продолжала развиваться. RFC 6335, опубликованный в 2011 году, различает системные порты 0–1023, пользовательские 1024–49151 и динамические 49152–65535. Он допускает регистрацию имени службы без фиксированного порта. Согласовать название и закрепить номер — не обязательно одно административное действие.

RFC 7605 в 2015 году обсуждал экономное использование назначений и различение версий либо разговоров по информации внутри протокола. Это поздний контекст для той же инженерной задачи. Само сходство подхода не доказывает, что рекомендации возникли непосредственно под влиянием TCPMUX.

В реестре IANA для имён служб и номеров портов tcpmux сохраняется у порта 1. Там присутствуют строки TCP и UDP. Однако RFC 1078 описывает обмен по TCP; параллельная строка реестра не создаёт правил UDP-обмена, отсутствующих в спецификации.

Нельзя также превращать сохранённое назначение в статистику распространения. Документ протокола, руководство по реализации, активная настройка и наблюдаемый трафик подтверждают разные факты. Доступных материалов достаточно для объяснения устройства TCPMUX, но недостаточно для вывода о массовом использовании или единственной причине его коммерческой судьбы.

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