TELNET

Telnet

Название:	Teletype network
Уровень (по модели OSI):	Прикладной
Семейство:	TCP/IP
Порт/ID:	23/TCP
Назначение протокола:	виртуальный текстовый терминал
Спецификация:	RFC 854 / STD 8
Основные реализации (клиенты):	telnet (Unix)
Основные реализации (серверы):	telnetd, MS Telnet
Расширяемость:	Опции (RFC 855)

TELNET (англ. TELecommunication NETwork) — сетевой протокол для реализации текстового интерфейса по сети (в современной форме — при помощи транспорта

Введение

Назначение протокола TELNET в предоставлении достаточно общего, двунаправленного, восьми битного байт ориентированного средства связи. Его основная задача заключается в том, чтобы позволить терминальным устройствам и терминальным процессам взаимодействовать друг с другом. Предполагается, что этот протокол может быть использован для связи вида терминал-терминал ("связывание") или для связи процесс-процесс ("распределенные вычисления").

Описание

Соединение TELNET - это TCP соединение, используемое для передачи данных, с различной управляющей информацией.

Протокол TELNET базируется на трех основных идеях: первая, концепция "Виртуального Сетевого Терминала" (англ. Network Virtual Terminal, NVT); вторая, принцип оговоренных опций; третья, симметричный вид терминалов и процессов.

1. Когда устанавливается TELNET соединение, предполагается, что на каждом конце соединения порождается и завершается "Виртуальный Сетевой Терминал" или ВСТ. ВСТ - это воображаемое устройство которое предоставляет стандартное, доступное через cеть, промежуточное представление классического терминала. Это устраняет необходимость в "серверном" и "клиентском" узлах для хранения информации о характеристиках каждого терминала и договоренностей о взаимодействии. Все узлы, как клиентский, так и серверный, отображают свои локальные характеристики устройства с тем, чтобы выступать в сети как ВСТ, и каждый мог принять похожее отображение с другой стороны. ВСТ предназначен для сведения баланса между чрезмерным ограничением и чрезмерными возможностями.
   Примечание: "Пользовательский" хост - это обычно хост с привязанным к нему физическим терминалом, а "серверный" хост - это обычно хост предоставляющий некий сервис. Как альтернативную точку зрения, можно рассматривать случай когда соединяются равные хосты: терминал-терминал или процесс-процесс. Таким образом будем считать "пользовательским" хостом тот хост который инициирует соединение.
2. Принцип оговоренных опций охватывает тот факт, что многие хосты скорее всего будут хотеть предоставить дополнительные сервисы до или после их доступности в ВСТ, и многие пользователи захотят иметь сложные терминалы с элементами изысканности, вместо минимальных, для получения таких дополнительных сервисов. Независимые от, но структурированные в TELNET протоколе различные "опции" санкционированы и могут быть использованы с "DO, DON'T, WILL, WON'T" структурой (обсуждается ниже) для того, чтобы позволить пользователю и серверу сходиться в использовании более продуманного (или отличного) набора соглашений для их TELNET соединения. Такие опции включают изменение набора символов, режима эха, и т.д.
   Базовая стратегия для налаживания использования опций - это на одной из сторон (или на обоих) инициировать запрос: будет ли определенная опция иметь какой либо эффект. Другая сторона может либо принять, либо отвергнуть запрос. Если запрос принимается, то опция немедленно вступает в силу; если же опция отвергается, то связанный аспект соединения остается как специфицировано для ВСТ. Очевидно, что сторона может всегда отвергать запрос на включение, и никогда не должна отвергать запрос на отключение некоторой опции начиная с момента когда стороны договорились о поддержке ВСТ.
   Синтаксис оговоренной опции должен быть таким, чтобы если обе стороны запросят одновременно опцию, то каждый будет рассматривать запрос с другой стороны как положительное подтверждение этой опции.
3. Симметричность синтаксиса согласования может потенциально привести к бесконечному циклу согласования - когда каждая сторона видит входящие команды не подтверждает их, но для подтверждения посылает новый запрос. Для предотвращения таких циклов, необходимо придерживаться следующих правил:
   • Стороны могут запрашивать только изменение статуса опции; т.е. сторона может не посылать "запрос" только для того, чтобы сообщить, что данная опция поддерживается.
   • Если сторона получает что-то, что интерпретируется как запрос переключения в некоторый режим в котором эта сторона уже находится, то на такой запрос не нужно отправлять подтверждения.
   • Всякий раз, когда одна сторона отправляет команду опции на другую сторону, не важно запрашивая или подтверждая, и использование опции должно иметь какой либо эффект на обработку данных, отсылаемых первой стороной второй стороне, то команда опции должна быть вставлена в потоке данных в том месте, с которого желательно, чтобы опция вступила в силу. (Следует отметить, что пройдет некоторое время между передачей запроса и получением подтверждения, и оно может быть отрицательным. Таким образом, хост может буферизовать данные, после отправки запроса опции и до получения ответа с принятием или отвержением опции, для того, чтобы скрыть "период неопределенности" от пользователя.)

Вероятно, что сразу после установки TELNET соединения, запросы опций будут шквалом передаваться в обоих направлениях соединения, из-за того, что каждая сторона будет пытаться получить наилучший сервис от другой стороны. Кроме того, опции могут быть использованы для динамического изменения характеристик соединения с тем, чтобы соответствовать изменяющимся локальным условиям. Например, ВСТ, как будет описано ниже, использует дисциплину передачи, хорошо подходящую для многих приложений "строка за раз" (таких как BASIC), но плохо подходит для приложений "символ за раз" (таких как NLS). Сервер мог бы выделить дополнительное процессорное время требуемое для дисциплины "символ за раз" если это подходит для локального процесса и договориться о соответствующей опции. Хотя, вместо того, чтобы надолго обременяться дополнительной тратой процессорного времени, можно переключиться (т.е. договориться) вернуться назад к ВСТ, когда детальный контроль больше не требуется.

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

Проектировщики опции не должны себя чувствовать стесненными несколько ограниченным синтаксисом для оговоренной опции. Смысл простого синтаксиса состоит в том, чтобы упростить принятие опции. Если некоторая специфическая опция требует более сложной структуры согласований чем имеющаяся в "DO, DON'T, WILL, WON'T", то необходимо сначала договориться через существующую структуру согласований, а после того, как обе стороны удостоверятся в понимании этой опции, использовать свободно более экзотический синтаксис. Например, одна из сторон могла бы послать запрос на изменение (установку) длинны строки. Если он принимается, то может быть использован отличный от базового синтаксис для того, чтобы фактически договориться о длине строки; такие "под-согласования" могли бы включать поля для минимально, максимально и желательных длин строки. Важно то, что такие расширенные согласования никогда не должны начинаться, пока "стандартные" переговоры не привели к тому, что обе стороны могут понимать расширенный синтаксис.

В итоге, WILL XXX посылается одной из двух сторон, для того чтобы показать желание (предложение) стороны исполнять опцию XXX, DO XXX и DON'T XXX являются подтверждением и отвержением опции XXX соответственно, на запрос WILL XXX; аналогично, DO XXX отправляется для того, чтобы показать желание другой стороны (т.е. получателя DO) начать исполнять опцию XXX, WILL XXX и WON'T XXX являются подтверждением и отвержением опции XXX соответственно, на запрос DO XXX. Так как ВСТ - это то, что остается когда никакие опции не включены, ответы DON'T и WON'T гарантируют что соединение останется в состоянии которым обе стороны могут управлять. Таким образом, все хосты могут реализовать свои TELNET процессы так, чтобы они вообще не знали об опциях которые не поддерживаются, просто возвращая отвержение (т.е. отказываясь от опции) на любой запрос опции, которую данный процесс не может понять.

Протокол TELNET был сделан максимально симметричным по отношению к связке пользователь-сервер, для того, чтобы он легко и естественно покрывал случаи пользователь-пользователь и сервер-сервер. Желательно, но не обязательно, чтобы опции сохраняли этот принцип. В любом случае явно признается, что симметрия - это принцип, а не правило.

Сопутствующий документ "TELNET Option Specifications" предназначен для того, чтобы черпать из него информацию о процедуре написания новых опций.

Виртуальный Сетевой Терминал

Виртуальный Сетевой Терминал (ВСТ) является двунаправленным символьным устройством. У ВСТ есть принтер и клавиатура. Принтер отвечает за входящие данные, а клавиатура производит исходящие данные, которые передаются по TELNET соединению и если необходимо "эхо" - то эти данные так же передаются и на принтер ВСТ. Предполагается, что "эхо" не будет передаваться по сети (хотя существуют опции, которые позволяют включать "удаленный" режим эха операции, но хост не обязан поддерживать эту опцию). Набор символов - это семибитовый USASCII в восьмиразрядном поле, кроме изменений описанных в данном документе. Любое преобразование кодировки и анализ времени - это локальные проблемы и не затрагивают ВСТ.

Передача данных

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

1. Насколько позволяет локальный размер буфера, данные должны накапливаться на том хосте, где они вводятся, до тех пор пока не будет готова к передаче полная строка данных или пока не будет подан явный локальный сигнал к передаче. Этот сигнал может быть сгенерирован процессом или человеком.
   Причиной этого правила является высокая стоимость обработки входящих сетевых прерываний для некоторых хостов, а так же заданное спецификацией ВСТ "эхо" которое не должно передаваться через cеть. Таким образом кажется разумным буферизовать некоторое количество данных на стороне их источника. Многие системы предпринимают некоторые действия по обработке в конце каждой входящей строки (например, устройства построчной печати) и таким образом передача данных должна быть инициирована в конце строки. С другой стороны, пользователю или процессу может иногда понадобиться передать данные, которые не заканчиваются переводом строки и поэтому необходимо предусмотреть методы, которыми можно передать все буферизированные локальные данные немедленно.
2. Когда процесс завершил отправку данных на принтер ВСТ и не имеет никакого очередного ввода с клавиатуры ВСТ для дальнейшей обработки (т.е., в случае когда процесс на одном конце TELNET соединения не может продолжить без входящих данных с другой стороны) он должен передать команду Go Ahead (GA).
   Это правило не является обязательным и не требует, чтобы команда GA отправлялась в конце каждой строки, так как серверы обычно не требуют специального сигнала (в дополнение к концу строки или другим локально определенным символам) чтобы начать обработку. Правильнее будет сказать, что команда TELNET GA сделана, чтобы помочь локальному компьютеру пользователя управлять физическим полудуплексным терминалом (например, IBM 2741) у которого есть "блокируемая" клавиатура. Описание этого терминала может помочь в понимании правильного использования команды GA.
   Соединение терминал-компьютер всегда находится под контролем пользователя или компьютера. Ни один не может в одностороннем порядке захватить контроль над другим. На стороне терминала аппаратные средства реализованы так, чтобы отдавать контроль всякий раз, когда "строка" закончена (т.е. когда клавиша "конец строки" нажата пользователем). И когда это происходит, присоединенный (локальный) компьютер обрабатывая входные данные, решает, должен ли генерироваться вывод и если не должен, возвращает контроль терминалу. Если вывод должен генерироваться, то контроль сохраняется за компьютером пока все данные не будут переданы.
   Трудности использования терминала такого типа по сети очевидны. "Локальный" компьютер более не в состоянии решить, сохранять ли контроль или нет после того, как был обнаружен сигнал конца строки; это решение может быть принято только "удаленным" компьютером, который обрабатывает данные. Поэтому команда TELNET GA обеспечивает механизм, посредством которого "удаленный" (сервер) компьютер может сообщить "локальному" (пользователю) компьютеру, что настало время передачи управления пользователю терминала. Это должно быть передано тогда и только тогда, когда пользователь должен контролировать терминал. Отметим, что преждевременная отправка команды GA, может привести к блокированию вывода, так как пользователь, вероятно, будет предполагать, что передающая система сделала паузу и поэтому он вряд ли введет перевод строки вручную.

Вышесказанное, конечно, не относится к направлению соединения пользователь-сервер. В этом направлении, GA можно отправить в любой время, но эта команда в этом направлении никогда не должна посылаться. Кроме того, если TELNET соединение используется для коммуникации типа процесс-процесс, то команду GA нельзя отправлять ни в одном из направлений. И в заключении, для соединения терминал-терминал, команда GA может не потребоваться в одном или обоих направлениях. Если хост планирует поддерживать соединение типа терминал-терминал, предполагается, что такой хост предоставит пользователю возможность вручную сообщить, когда нужно отправить команду GA; это требование не является обязательным для реализующего сторону типа "процесс".

Отметим, что симметричная модель TELNET требует, по крайней мере концептуально, чтобы ВСТ присутствовал на каждом конце TELNET соединения.

Стандартное представление управляющих функций

Как уже говорилось во Введении к этому документу, основная цель протокола TELNET - это обеспечить стандартный сетевой интерфейс терминальным устройствам и терминал-ориентированным процессам. Ранний опыт с этим типом соединения показал, что определенные функции осуществимы для большинства серверов, а вот методы вызова этих функций достаточно широко различаются. Для человека, который взаимодействует с несколькими серверными системами, эти отличия представляют достаточно большое неудобство. Поэтому ниже будет приведено стандартное представление для пяти функций. Эти стандартные представления являются стандартом, но не требуются в обязательном порядке (за исключением функции Interrupt Process (IP), которая может понадобиться другим протоколам, которые используют TELNET); то есть система, которая не предоставляет функцию локальным пользователям не должна предоставлять ее и сетевым пользователям и может обрабатывать стандартное представление для функции как пустую команду (No-operation). С другой стороны, система, которая предоставляет функцию локальному пользователю, обязана предоставлять ту же самую функцию и сетевому пользователю, который передает стандартное представление для функции.

Interrupt Process (IP)

Многие системы предоставляют функцию которая приостанавливает, прерывает, аварийно прекращает или обрывает деятельность пользовательского процесса. Эта функция часто используется, когда пользователь полагает, что его процесс находится в бесконечном цикле или когда был активизирован нежелательный процесс. IP - это стандартное представление для вызова этой функции. Необходимо отметить, что IP может потребоваться другим протоколам, которые используют TELNET, и поэтому эта функция должна быть реализована, если такие протоколы поддерживаются реализацией.

Abort Output (AO)

Многие системы предоставляют функцию, которая позволяет процессу, который генерирует вывод, завершаться (или достигнуть той же самой точки останова, которой он бы достиг, если бы добрался до завершения), но без отправки вывода на пользовательский терминал. Затем, эта функция обычно очищает любой уже произведенный вывод, но еще фактически не напечатанный (или отображенный) на терминале пользователя. AO - это стандартное представление для того, чтобы вызвать эту функцию. Например, некоторая подсистема могла бы принять команду пользователя, послать длинную текстовую строку на терминал пользователя как ответ, и наконец сообщить о готовности принять следующую команду, посылая символ "prompt" (упреждая его ) на пользовательский терминал. Если бы AO была получена во время передачи текстовой строки, то реализация должна былв бы подавить остаток текстовой строки, но передать символ prompt упреждающие. (Это отличается от действия, которое могло быть предпринято, при получении IP; IP мог бы вызвать подавление текстовой строки и выход из подсистемы.)

Следует отметить, что серверные системы, которые предоставляют эту функцию должны иметь в виду, что могут быть внешние к системе буфера (сетевые или на пользовательском локальном хосте) которые должны быть очищены; соответствующий способ сделать так, это передать сигнал "Synch" (описанный ниже) пользовательской системе.

Are You There (AYT)

Многие системы предоставляют функцию которая предоставляет пользователю видимое (например, напечатанное) доказательство, что система функционирует и выполняется. Эта функция может быть вызвана пользователем, когда система неожиданно "затихает" на продолжительное время, из-за непредвиденно (для пользователя) длительных вычислений, необычно тяжелой системной нагрузки, и т.д. AYT - стандартное представление, чтобы вызвать эту функцию.

Erase Character (EC)

Многие системы предоставляют функцию, которая удаляет последний символ перед не удаляемым символом или "позицией печати" из потока данных поставляемого пользователем. Эта функция обычно используется, чтобы редактировать ввод с клавиатуры, когда были сделаны ошибки при печати. EC - стандартное представление для того, чтобы вызвать эту функцию.

Примечание: "Позиция печати" может содержать несколько символов, которые являются результатом наложений, или последовательностей, таких как <char1> BS <char2>...

Erase Line (EL)

Многие системы предоставляют функцию, которая удаляет все данные в текущей "строке" ввода. Эта функция обычно используется, чтобы редактировать ввод с клавиатуры. EL стандартное представление для того, чтобы вызвать эту функцию.

Сигнал "Synch"

Многие системы с разделением времени (многозадачные системы) предоставляют механизмы, которые позволяют пользователю терминала восстанавливать управление над "бесконечным" процессом; функции IP и AO, описанные выше, являются примерами этих механизмов. Такие системы, когда они используются локально, имеют доступ ко всем сигналам которые вводит пользователь, являются ли они обычными символами или специальными сигналами, такими как поддерживаемая телетайпом кнопка "BREAK" или IBM 2741 кнопка "ATTN". Это не всегда так, когда терминалы подключены к системе через сеть; сетевые механизмы могут заставить такой сигнал быть забуферизированным в другом месте, например на хосте пользователя.

Чтобы решить эту проблему, в TELNET был введен механизм "Synch". Сигнал Synch включается в TCP Urgent notification (срочное уведомление) вместе с TELNET командой DATA MARK. Срочное уведомление, которое не подвергается дополнительному управлению сетевыми механизмами, управляющие TELNET соединением, используется, чтобы вызвать специальную обработку потока данных процессом, который получает эти данные. В этом режиме поток данных будет немедленно просканирован на предмет "интересных" сигналов как описано ниже, отказываясь от пришедших данных. TELNET команда DATA MARK (DM) является меткой синхронизации в потоке данных, которая указывает, что некоторый специальный сигнал уже попался и получатель может возвратиться к нормальной обработке потока данных.

Synch отправляется через TCP отправкой операции с флагом Urgent и DM как последним октетом данных.

Когда несколько Synch отправляются как непрерывная последовательность, срочные уведомления могут быть объединены. Невозможно посчитать количество срочных уведомлений, так как количество полученных будет меньше или равно количеству отправленных. В обычном режиме, DM не имеет действия; в срочном режиме, он сообщает конец срочной (urgent) обработки.

Если TCP указывает на конец срочных (urgent) данных раньше, чем будет найден DM, TELNET должен продолжить специальную обработку потока данных, пока не встретиться DM.

Если TCP указывает на то, что срочные (urgent) данные еще есть, после того как найдет DM, то такое может случиться из-за следующего Synch. TELNET должен продолжить специальную обработку данных, пока другой DM не будет найден.

"Интересные" сигналы определены, чтобы быть: стандартными TELNET представлениями IP, AO и AYT (но не EC или EL); локальными аналогами этих стандартных представлений; всеми другими TELNET командами; другими определенными по месту сигналами которые могут задействоваться без задержки сканирования потока данных.

Так как один из эффектов механизма SYNCH - это отказ от всех символов (исключая TELNET команды) между отправителем Synch и получателем, то этот механизм определен как стандартный путь очистки данных. Например, если пользователь в терминале передает AO, сервер, который получает AO (если он вообще обеспечивает эту функцию) должен вернуть пользователю Synch.

В итоге, так же как TCP Urgent notification требуется уровень TELNET как сигнал out-of-band, так и другим протоколам использующим TELNET, могут понадобиться TELNET команды, которые могут рассматриваться как out-of-band сигналы на различном уровне.

В соответствии с соглашением последовательность [IP,Synch] должна использоваться как такой сигнал. Например, предположим, что некоторый другой протокол, который использует TELNET, определяет строковую строку STOP аналогично TELNET команде AO. Предположим, что пользователь этого протокола желает, чтобы сервер обработал строку STOP, но соединение блокировано, потому что сервер обрабатывает другие команды. Пользователь должен проинструктировать свою систему:

1. Отправить символ TELNET IP;
2. Отправить последовательность TELNET SYNCH, которая состоит из:
   Отправки Data Mark (DM) как единственного символа который посылается в срочном режиме TCP.
3. Отправка символьной строки STOP; и
4. Отправка аналога TELNET DM для другого протокола, если требуется.

Пользователь (или процесс действующий от его имени) должен передать последовательность TELNET SYNCH на шаге 2, чтобы гарантировать, что TELNET IP пройдет на серверном интерпретаторе TELNET.

Срочное уведомление должно разбудить процесс TELNET; IP должен разбудить следующий высокоуровневый процесс.

Принтер и клавиатура ВСТ

Принтер ВСТ имеет неопределенную ширину каретки и длину страницы и может произвести представление всех 95 USASCII график символов (коды с 32 по 126). Только следующие из 33 управляющих кодов USASCII (от 0 до 31, а так же 127), и 128 открытых кодов (128-255) имею смысл для принтера ВСТ:

Название	Код	Описание
NULL (NUL)	0	Нет операции
Line Feed (LF)	10	Переводит принтер на следующую строку печати, оставаясь на той же горизонтальной позиции.
Carriage Return (CR)	13	Перемещает принтер к левой границе текущей строки.

Кроме того, следующие коды должны быть определены, но не требуют эффекта от принтера ВСТ. Ни на какое из концов TELNET соединения не может предполагать, что другая сторона будет что-то предпринимать при получении или передачи следующего:

Название	Код	Описание
BELL (BEL)	7	Производит аудио или видеосигнал (но НЕ перемещает головку принтера).
Back Space (BS)	8	Перемещает головку принтера на один символ по направлению к левой границе.
Horizontal Tab (HT)	9	Перемещает принтер на следующую остановку горизонтальной табуляции. Остается неопределенным как сторона определяет и устанавливает эти остановки табуляции.
Vertical Tab (VT)	11	Перемещает принтер на следующую остановку вертикальной табуляции. Остается неопределенным как сторона определяет и устанавливает эти остановки табуляции.
Form Feed (FF)	12	Перемещает принтер к верхней части следующей страницы, оставаясь на той же горизонтальной позиции.

Все остальные коды не должны заставлять ВСТ предпринимать какие либо действия.

Последовательность "CR LF", как определено, заставит ВСТ перейти на крайнюю левую позицию следующей строки печати (так же как, например, последовательность "LF CR"). Однако, есть много систем и терминалов которые не обрабатывают CR и LF независимо, и нужно потратить некоторые усилия, чтобы смоделировать этот эффект. (Например, у некоторых терминалов нет независимого CR от LF, но на таких терминалах можно реализовать CR через backspacing.) Поэтому, последовательность "CR LF" должна обрабатываться как единый символ "новая строка" и использоваться всякий раз, когда требуется их объединенное действие; последовательность "CR NUL" должна использоваться, где требуется требуется только возврат каретки; и использования символа CR следует избегать в других контекстах. Это правило дает гарантию системам, которые должны решить, выполнять ли функцию "новая строка" или выполнять множественный backspace когда TELNET поток содержит символ CR, принять рациональное решение.

Примечание: Последовательности "CR LF" или "CR NUL" должны использоваться в обоих направлениях (в режиме ASCII по умолчанию), для сохранения симметрии ВСТ. И даже в том случае если известно (например, с удаленным эхом или эффектом подавления опции Go Ahead), что символы не передаются на реальный принтер, для согласованности, протокол требует, чтобы NUL был вставлен после CR, не сопровождаемого переводом строки в потоке данных. Обратная сторона того, что NUL будет получен в потоке данных после CR (если отсутствуют согласованные опции, которые определяют иное поведение), это то, что NUL должен быть удален до применения ВСТ к локальному набору символов.

Клавиатура ВСТ должна имеет клавиши, или комбинации клавиш, или последовательности клавиш для воспроизведения всех 128 кодов USASCII. Отметим, что хотя некоторые из них не будут иметь никакого эффекта для принтера ВСТ, клавиатура ВСТ способна их генерировать.

В доплнение к этим кодам, клавиатура ВСТ должна быть способна к генерации следующих дополнительных кодов, исключая, как было описано, определенные, но не требуемые значения. Фактическое определение кодов для этих "символов" находится в разделе "Команды TELNET", потому, что они рассматриваются как данность и являются в некотором сиысле универсальными и должны быть доступны даже когда поток данных интерпретируется в другой кодировке.

Название	Описание
Synch	Эта клавиша позволяет пользователю очищать свой информационный канал на другой стороне. Активация этой клавиши отправляет DM (смотри раздел команд) в поток данных и TCP Urgent notification которое связанно с DM.
Break (BRK)	Этот код предоставляется из-за того, что он вне набора USASCII, который в настоящее время используется на многих локальных системах. Этот код предназначен для указания того, что нажата одна из кнопок "Break" или "Attention". Стоит отметить, что это определено, чтобы обеспечить 129-ый код для систем, которые этого требуют, но не как синоним для представления стандартного IP.
Interrupt Process (IP)	Приостанавливает, прерывает, аварийно прекращает или завершает процесс к которому подключен ВСТ. Кроме того, он может быть использован как часть out-of-band сигнала для других протоколов, которые используют TELNET.
Abort Output (AO)	Позволяет текущему процессу выполниться до конца, но не отправляет его вывод пользователю. Так же отправляет сигнал Synch пользователю.
Are You There (AYT)	Отправляет назад на ВСТ некоторый видимое доказательство того, что AYT был получен.
Erase Character (EC)	Получатель должен удалить последний символ, предшествующий "неудаляемому символу" или "позиции печати", из потока данных.
Erase Line (EL)	Получатель должен удалить символы из потока данных до (но не включая) последней последовательности "CR LF".

Смысл этих "дополнительных" клавиш, а так же исполнительных элеменов принтера в том, что они должны представлять естественное расширение отображения, которое обязательно должно присутствовать в "ВСТ" и "локальной системе". Так же как байт данных ВСТ 68 (104 в восьмеричной системе) должен быть отображен в локальный код для "заглавной D", так же и символ EC должен быть отображен в то, что локально отвечает за функцию "удаление символа". Далее, так же как отображение для 124 (174 в восьмеричной системе) в некоторых системах интерпретируется несколько произвольно как символ "вертикальной полосы", так и символ EL может иметь несколько произвольную трактовку отображения (или не иметь отображения вообще) если не имеется никакой локальной функции "Стирания строки". Подобное истинно и для других исполнительных элементов формата: если терминал имеет "вертикальную табуляцию", то отображение для VT очевидно, а если терминал не имеет вертикальной табуляции, то еффект VT непредсказуем.

Структура TELNET команд

Все команды TELNET состоят по крайне мере из двухбайтовой последовательности: эскейп символа "Interpret as Command" (IAC) и кода команды. Команды, отвечающие за договоренности по опции, являются трехбайтовыми последовательностями, где третий байт является кодом опции. Такой формат был выбран для более полного использования "пространства данных" - при общении с базовым ВСТ, и соответственно колизии байт данных с получаемыми командами сведены к минимуму. С текущей структурой только IAC требует удвоения, чтобы он воспринимался как данные, а другие 255 кодов могут быть отправлены как есть.

Далее идет определение TELNET команд. Отметим, что эти коды и кодовые последовательности, имеют соответствующий смысл только когда идут сразу за IAC.

Название	Код	Описание
SE	240	Конец параметров подчиненных договоренностей.
NOP	241	Нет операции.
Data Mark	242	Часть потока данных Synch. Эта команда всегда сопровождается TCP Urgent notification.
Break	243	ВСТ символ BRK.
Interrupt Process	244	Функция IP.
Abort output	245	Функция AO.
Are You There	246	Функция AYT.
Erase character	247	Функция EC.
Erase Line	248	Функция EL.
Go ahead	249	Сигнал GA.
SB	250	Указывает на то, что все что идет далее, является подчиненными договоренностями обозначенной опции.
WILL (option code)	251	Указывает на желание исполнять или подтверждает, что сейчас исполняется указанная опция.
WON'T (option code)	252	Указывает на отказ начать или продолжить исполнять указанную опцию.
DO (option code)	253	Запрос на то, чтобы другая сторона исполнила или подтвердила исполнение указанной опции.
DON'T (option code)	254	Требование на то, чтобы другая сторона остановила исполнение или подтвердила то, что указанная опция более не исполняется.
IAC	255	Байт данных 255.

Установление соединения

TELNET TCP соединение устанавливается между пользовательским портом U и серверным портом L. Сервер слушает свой порт L для того, чтобы установить такие соединения. Так как соединение TCP - это полный дуплекс и идентифицируется парой портов, сервер может участвовать одновременно во многих соединениях вовлекающих его порт L и различные пользовательские порты U.

Назначение порта

Если протокол используется для удаленного доступа пользователя к сервисам хоста (т.е. удаленный терминальный доступ) то он назначается на порт 23 (27 в восьмеричной системе). Т.е. L=23.

Применения

Исторически Telnet служил для удалённого доступа к интерфейсу командной строки операционных систем. Впоследствии его стали использовать для прочих текстовых интерфейсов, вплоть до игр MUD и анимированного ASCII-art. Теоретически, даже обе стороны протокола могут являться программами, а не человеком.

Иногда клиенты telnet используются для доступа к другим протоколам на основе транспорта TCP, см. #Telnet и другие протоколы.

Протокол telnet используется в управляющем соединении telnet ftp.example.net ftp для выполнения отладки и экспериментов не только возможно, но и правильно (в отличие от применения клиентов telnet для доступа к HTTP, IRC и большинству других протоколов).

Безопасность

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

Telnet и другие протоколы

В среде специалистов по технологиям internet распространено мнение, что клиент Telnet пригоден для осуществления ручного доступа (например, в целях отладки) к таким протоколам прикладного уровня как IRC, POP3 и прочим текст-ориентированным протоколам на основе транспорта TCP. Однако, использование клиента telnet в качестве клиента TCP вызывает следующие нежелательные эффекты:

• Клиент может передать данные, которые Вы не вводили (опции Telnet);
• Клиент не будет принимать октет \377;
• Клиент будет искажать октет \377 при передаче;
• Клиент вообще может отказаться передавать октеты со старшим битом 1.

Такие программы как Перевод строки, вводимый из Unix-системы, будет передан одним символом LF, в то время как названные протоколы требуют CR LF как разделитель строки — впрочем, большинство серверов удовлетворяются и одним LF, хотя по стандарту делать это не обязаны. Обычный клиент Telnet по умолчанию передаёт любой перевод строки именно как CR LF. Наиболее корректным решением для отладочного доступа к прикладным протоколам (кроме FTP и, собственно, Telnet) является использование клиента

Ссылки

• RFC 854 TELNET protocol specification
• RFC 855 TELNET option specifications
• RFC 856 TELNET binary transmission
• RFC 857 TELNET echo option
• RFC 858 TELNET suppress Go Ahead option
• RFC 859 TELNET status option
• RFC 860 TELNET timing mark option
• RFC 861 TELNET extended options - list option
• RFC 885 Telnet end of record option
• RFC 1041 Telnet 3270 regime option
• RFC 1073 Telnet Window Size Option
• RFC 1079 Telnet terminal speed option
• RFC 1091 Telnet terminal-type option
• RFC 1096 Telnet X display location option
• RFC 1184 Telnet linemode option
• RFC 1205 5250 Telnet interface
• RFC 1372 Telnet remote flow control option
• RFC 2217 Telnet Com Port Control Option
• RFC 2941 Telnet Authentication Option
• RFC 2942 Telnet Authentication: Kerberos Version 5
• RFC 2943 TELNET Authentication Using DSA
• RFC 2944 Telnet Authentication: SRP
• RFC 2946 Telnet Data Encryption Option
• RFC 4248 The telnet URI Scheme
• RFC 4777 IBM's iSeries Telnet Enhancements