Кратко

  • Ранний Telnet отводил верхнюю половину пространства байтов управляющим сигналам. Поздняя архитектура сосредоточила власть команд в IAC со значением 255, поэтому остальные 255 значений перестали сталкиваться с отдельно стоящими кодами команд.
  • Буквальное значение данных 255 кодируется как IAC IAC. Согласованная Binary Transmission открывает весь восьмибитный диапазон, но не выключает управление Telnet: получатель по-прежнему ищет IAC и исполняет встроенные команды.

Одна красная плитка могла приказывать; две превращались в одни данные

Представим двоичный файл, проходящий через терминальный протокол. Очередной байт случайно равен 255 в десятичной записи. Если получатель понимает его как «интерпретировать следующий байт как команду», часть файла будет съедена синтаксисом протокола. Если всегда считать его содержимым файла, будет пропущена настоящая инструкция сменить параметр. На проводе в обоих случаях находится одно число.

Telnet устранил двусмысленность небольшой грамматикой. Один IAC — Interpret As Command — открывает управляющее состояние. За ним следует определённый код команды, иногда с дополнительными байтами. Только IAC, за которым стоит ещё один IAC, представляет обычный байт данных со значением 255. Отправитель удваивает его, а получатель узнаёт пару и удаляет копию, служившую рамкой.

Это не универсальное экранирование со смыслом «всё следующее буквально». Второй IAC имеет в этой позиции одно точное значение. Иные значения после IAC остаются командами Telnet или частью их синтаксиса. Два байта на линии становятся одним в приложении, потому что оба конца поддерживают одно состояние разбора.

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

Первый Telnet отдал управлению половину пространства

В апреле 1972 года RFC 318 описал официальный протокол Telnet ARPANET на основе сетевого виртуального терминала. Значения от 0 до 127 несли USASCII, а значения от 128 до 255 были назначены специальным управляющим сигналам.

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

RFC 318 называл способы перехода к иным кодам, включая режим Transparent, однако признавал, что после такого перехода смысл сигналов Telnet и даже путь назад к ASCII могли оставаться неопределёнными. Расширение алфавита данных ставило под угрозу способность протокола узнавать собственное управление.

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

Предложение QUOTE показало очертания решения

RFC 435, обсуждавший проблемы Telnet в январе 1973 года, рассматривал прямой двоичный режим по умолчанию. Авторы предложили символ QUOTE, после которого байт всегда читался бы как данные. Высокие значения могли оставаться пространством команд, а процитированные вхождения передавались бы буквально.

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

Выбор в общих чертах был между двумя путями. Можно оставить много управляющих значений и цитировать множество возможных столкновений. Можно выделить один особый вход в управление и платить дополнительный байт только тогда, когда это значение нужно как данные. Поздняя спецификация Internet Telnet выбрала второе.

IAC сжал власть команд до одного префикса

RFC 764, опубликованный в июне 1980 года, описывал Telnet как средство, ориентированное на восьмибитные байты, работающее через одно соединение TCP, где управляющая информация перемежается с данными. Базовый стандарт RFC 854 от мая 1983 года сохранил эту архитектуру.

Каждая команда Telnet начинается с IAC, значения 255, за которым идёт код команды. Переговорные WILL, WON'T, DO и DON'T несут третий байт с номером параметра. Другие коды означают конец подпереговоров, отсутствие действия, Data Mark, прерывание, отмену вывода, стирание символа и прочие базовые функции.

Цена и выигрыш названы прямо. Раз переговоры позволяют полнее использовать пространство данных, столкновения с командами следует свести к минимуму. В конструкции IAC только сам IAC требует удвоения как данные; остальные 255 значений могут проходить прозрачно с точки зрения базового обрамления команд.

«Прозрачно» здесь имеет узкий смысл. В режиме NVT сохраняются соглашения о символах и строках; слово не обещает неизменной семантики каждого значения. Оно означает, что прочие значения не принимаются за самостоятельные команды Telnet только из-за своего числа. Управляющая власть переместилась из целой области голых байтов в последовательности, начинающиеся у одних ворот.

Команда стояла ровно там, где менялась интерпретация

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

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

Граница налагает обязанности на анализатор. TCP может отдать IAC в одном чтении, а следующий байт — в другом; границы сегментов не являются записями Telnet. Реализация должна хранить состояние «префикс уже пришёл, продолжение ещё нет». Удвоение нужно снять ровно один раз: сохранение обоих байтов портит данные, а свёртывание настоящей пары команды в данные уничтожает управление.

Транспорт сохраняет порядок. Telnet задаёт грамматику. Ни один из них сам по себе не превращает поток в сообщения.

Подпереговоры унаследовали ту же дисциплину экранирования

Некоторым параметрам недостаточно ответа да или нет. RFC 855 задаёт подпереговоры как IAC SB, код параметра и его содержимое, завершаемое IAC SE. Даже не понимая формат содержимого, получатель может найти конец по рамке.

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

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

Такая граница делает незнание переносимым. Даже если нагрузка параметра непрозрачна, базовый анализатор может пройти до настоящего IAC SE, пока отправитель правильно экранирует буквальное 255.

Двоичный режим открыл восемь бит, не отключив управление

Произвольные двоичные данные были решающей проверкой. RFC 856 определяет параметр 0, Binary Transmission. Он согласуется отдельно в каждом направлении: сторона может принять восьмибитные двоичные данные, в то время как обратное направление остаётся в прежнем режиме.

После активации байты, которым не предшествует IAC, трактуются как восьмибитные двоичные данные. При этом IAC IAC по-прежнему означает значение данных 255, а IAC с действующей командой Telnet остаётся командой. Binary меняет обработку данных, а не делает весь поток TCP непрозрачным для Telnet.

Здесь и окупается префикс. Если бы все значения от 128 до 255 сохраняли управляющий смысл, двоичный режим должен был бы экранировать половину алфавита или отказаться от команд. Сосредоточение управления в одном значении позволяет почти всем двоичным значениям идти напрямую, а смене параметров — оставаться в том же соединении.

Поэтому Binary — не «сырой TCP после переговоров». Это соглашение о данных под неизменным обрамлением Telnet.

Требования к хостам не позволили забыть исключение

К октябрю 1989 года RFC 1123 превратил поведение в явное требование к хостам. Поскольку параметры Telnet могут появляться в любом месте потока, IAC, отправляемый как данные, обязан удваиваться. После успешных переговоров Binary получатели всё равно ищут IAC, исполняют встроенные команды и требуют удвоения значения данных 255.

Другие преобразования прекращаются. В режиме Binary нельзя применять обычные замены возврата каретки и соглашения о конце строки. Этот контраст запрещает удобное, но неверное сокращение: «двоичный» может отключить нормализацию текста, но не анализатор Telnet.

Нынешний реестр параметров Telnet IANA хранит пространство параметров и ссылки, включая Binary Transmission под номером 0. Реестр не является переписью современного использования. Он также показывает различие областей: параметр с номером 255 — не тот же объект, что байт IAC со значением 255 в потоке. Равенство чисел не объединяет роли протокола.

Повторённый байт сохранил один упорядоченный разговор

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

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

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

Байт повторял себя не для усиления. Первое вхождение брало на себя границу команды, чтобы второе могло остаться данными.

Источники и пределы

Раннее деление пространства происходит из RFC 318, обсуждение QUOTE — из RFC 435. RFC 764 и RFC 854 описывают смешанный поток и грамматику IAC. RFC 855 задаёт экранирование подпереговоров, RFC 856 — поведение Binary, RFC 1123 — требования к хостам, а реестр IANA — пространство параметров. Эти источники не устанавливают современную долю внедрения, соответствие продуктов, безопасность анализаторов, шифрование, аутентификацию или единую дату принятия всеми хостами.