Терминальные приложения

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

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

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

В сетях TCP/IP существуют три приложения, позволяющие осуществить терминальный заход.

1. Программа Rlogin и протокол происходят из OC Berkeley Unix 4.2BSD и первоначально обеспечивала взаимодействие только между Unix системами, впоследствии эта программа была перенесена и на другие операционные системы.

2. Telnet - стандартное приложение, которое присутствует практически в каждой реализации TCP/IP. Оно может быть использовано для связи между хостами, работающими под управлением различных операционных систем. Telnet использует согласование опций клиента и сервера, чтобы определить, какие характеристики терминала присутствуют с той и с другой стороны. Данные передаются в открытой форме.

3. ssh- приложение терминального доступа, обеспечивающее передачу данных в шифрованной форме.

Протокол rlogin

Rlogin был предназначен для захода удаленным терминалом между Unix хостами. Поэтому он проще, чем Telnet, так как не требуется определения параметров, которые для одной и той же операционной системы известны заранее и для клиента, и для сервера.

Запуск приложения

Rlogin использует одно TCP соединение между клиентом и сервером. После того как TCP соединение установлено, между клиентом и сервером осуществляется следующая последовательность действий.

 

Клиент отправляет серверу четыре строки:

(a) нулевой байт

(b) имя пользователя на хосте клиента, заканчивающееся нулевым байтом

(с) имя пользователя на хосте сервера, заканчивающееся нулевым байтом

(d) тип терминала пользователя, за которым следует слэш (/), затем следует скорость терминала, и все это заканчивается нулевым байтом.

Необходимо отправить именно два имени пользователя, потому что пользователи не обязаны иметь одинаковые имена на разных хостах.

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

Сервер отвечает нулевым байтом.

У сервера есть опция, с помощью которой он может запросит пароль. Это осуществляется как обычный обмен данными по Rlogin соединению - специальные протоколы не применяются. Сервер отправляет клиенту строку (которую клиент отображает на терминале), чаще всего эта строка выглядит как Password:. Если клиент не вводит пароль в течение определенного времени (обычно 60 секунд), сервер закрывает соединение.

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

Все что вводится в ответ на приглашение сервера ввести пароль, передается в виде открытого текста. Символы введенного пароля посылаются так, как они есть. Каждый, кто может прочитать пакеты в сети, может прочитать любой пароль. Последующие реализации Rlogin клиента, например в 4.4BSD, используют Kerberos для шифрации при передаче по сети.

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

Существуют команды, которые могут быть отправлены от клиента к серверу и от сервера к клиенту.

Управление потоком

По умолчанию управление потоком обычно осуществляет Rlogin клиент. Клиент распознает ASCII символы STOP и START (Control-S и Control-Q), которые вводятся пользователем, и останавливает или стартует вывод на терминал.

Если это не сделано, каждый раз, когда мы вводим Control-S, чтобы остановить вывод на терминал, символ Control-S отправляется по сети к серверу, и сервер прекращает писать в сеть, однако данные (размер данных может достигать размера окна) могут быть уже выданы сервером в сеть и будут отображены на терминале, перед тем как вывод будет остановлен. Сотни или тысячи байт данных могут прокрутиться на экране, перед тем как вывод будет остановлен. На рисунке 26.3 показан подобный сценарий.

Рисунок 26.3 Функционирование Rlogin соединения в случае, если сервер поддерживает обмен STOP/START.

 

Для интерактивных пользователей подобная задержка отклика на ввод символа Control-S нежелательна.

Однако, иногда приложения, запущенные на сервере, должны интерпретировать каждый байт ввода, и они не хотят, чтобы клиент использовал символы Control-S и Control-Q каким-то особенным образом. В подобном случае сервер может сообщить клиенту, поддерживает ли он контроль потока данных или нет.

Прерывание от клиента

Проблема, напоминающая управление потоком данных, возникает, когда пользователь вводит символ прерывания (обычно DELETE или Control-C), чтобы прекратить процесс, запущенный на сервере. В этом случае также одно полное окно данных в канале между сервером и клиентом будет передано клиенту, до тех пор пока символ прерывания проделает свой путь по соединению в другом направлении. Мы хотим, чтобы символ прерывания остановил или прервал вывод данных на экран так быстро, как это возможно.

Изменения размера окна

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

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

Команды от сервера к клиенту

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

Когда сервер отправляет команду клиенту, он входит в режим срочности, при этом последний байт срочных данных это и есть байт команды от сервера. Когда клиент получает уведомление о режиме срочности, он читает из соединения и сохраняет данные до тех пор, пока не будет получен байт с командой (последний байт срочных данных). Данные, которые сохранил клиент, могут быть выданы на терминал или проигнорированы, в зависимости от команды.

 

Байт	Описание
0х02	Сбросить вывод. Клиент отбрасывает все данные, принятые от сервера, до командного байта (последний байт срочных данных). Клиент также отбрасывает все данные, сбуферизированные и предназначенные для вывода на терминал. Сервер посылает эту команду, когда пользователь ввел символ прерывания.
0х10	Клиент прекращает контролировать поток данных.
0х20	Клиент возобновляет контроль потока данных.
0х80	Клиент немедленно отвечает отправкой серверу текущего размера окна и уведомляет сервер, если в будущем размер окна изменится. Сервер обычно отправляет эта команду немедленно после установления соединения.

Команды Rlogin, передаваемые от сервера клиенту.

 

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

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

Команды от клиента к серверу

Определена только одна команда, передаваемая от клиента к серверу: это отправка серверу текущего размера окна. Изменение размера окна отправляется серверу только по получению от сервера команду 0x80.

В этом случае клиент должен иметь возможность пометить команду, чтобы она не были переданы приложению, запущенному на сервере. Клиент помечает команду с помощью отправки 2-х байт равных 0xff, за которыми следуют два специальных флаговых байта.

Для команды, управляющей размером окна, два флаговых байта это ASCII символы s. Затем следуют четыре 16-битных значения: количество символов в строке (обычно 25), количество символов в столбце (обычно 80), количество пикселей по оси X и количество пикселей по оси Y. Часто два последних 16-битных значения равны 0, так как большинство приложений, запускаемых Rlogin сервером, определяют размер экрана в символах, а не в пикселях.

Подобная форма представления команд называется командами в полосе (in-band signaling), так как командные байты передаются в обычном потоке данных. Байты, выделяющие команды из потока данных (0xff) выбраны таким образом, чтобы нажатие какой-либо клавиши не могло их сгенерировать. У подобной формы представления команд есть свои недостатки. Если мы сможем сгенерировать два последовательных байта равных 0xff с клавиатуры, за которыми будут следовать два ASCII символа s, следующие 8 введенных байт будут восприняты как размеры окна.

Команды Rlogin от сервера к клиенту называются командами, выходящими за полосу (out-of-band signaling).

Так как команды в полосе (in-band signaling) передаются от клиента к серверу, сервер должен просматривать каждый байт, принятый от клиента, в поисках двух последовательных байтов 0xff. В случае команд выходящих за полосу (out-of-band signaling) , которые передаются от сервера к клиенту, клиенту нет необходимости просматривать данные, которые он получает от сервера, до тех пор пока сервер не перейдет в режим срочности. Даже в режиме срочности клиенту необходимо только просмотреть байт, на который указывает указатель срочности. Так как соотношение количества байт, передаваемых в двух направлениях (от клиента к серверу и от сервера к клиенту), составляет примерно 1:20, то возникает необходимость использовать команды в полосе (in-band signaling) для небольшого потока данных (от клиента к серверу), и команды, выходящие за полосу (out-of-band signaling), для более загруженного потока данных (от сервера к клиенту).

Способы прекращения работы клиента

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

1. Точка прекращает работу клиента.

2. Символ конца файла (обычно Control-D) прекращает работу клиента.

3. Символ подавления (обычно Control-Z) приостанавливает работу клиента.

4. Символ задержанного подавления (обычно Control-Y) задерживает только ввод клиента. При этом все вводимое с клавиатуры интерпретируется программой, запущенной на хосте клиента, однако все отправленное Rlogin сервером клиенту появляется на терминале. Это может быть использовано, когда на сервере запущено задание, которое займет много времени, и необходимо знать, когда и что оно выдаст, однако на клиенте необходимо запустить другую программу.

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

Протокол Telnet

Telnet был разработан для работаты между хостами под управлениием любых операционных систем, а также с любыми терминалами. Его спецификация определяет терминал, который может являться наиболее общим, и который называется виртуальным сетевым терминалом (NVT - network virtual terminal). NVT это воображаемое устройство, находящееся на обоих концах соединения, у клиента и сервера, с помощью которого устанавливается соответствие между их реальными терминалами. Таким образом, операционная система клиента должна определять соответствие между тем типом терминала, за которым работает пользователь, с NVT. В свою очередь, сервер должен устанавливать соответствие между NVT и теми типами терминалов, которые он (сервер) поддерживает.

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

NVT ASCII

Термин NVT ASCII означает 7-битный вариант U.S. ASCII набора символов, который используется в семействе протоколов Internet. Каждый 7-битный символ отправляется как 8-битный байт со старшим битом установленным в 0.

Конец строки передается как двухсимвольная последовательность - CR (возврат каретки - carriage return), затем следует LF (пропуск строки - linefeed). В протоколах FTP, SMTP, Finger и Whois используют NVT ASCII для ввода команд клиента и откликов сервера.

Команды Telnet

Telnet использует команды в полосе (in-band signaling) в обоих направлениях. Байт 0xff (255 десятичный) называется IAC, "интерпретировать как команду". Следующий байт является командным байтом. Для того чтобы послать байт данных равный 255, отправляются два последовательных байта равных 255. (Выше было указано, что поток данных имеет формат NVT ASCII, то есть используются 7-битные значения, а это означает, что байт данных равный 255 не может быть отправлен посредством Telnet. Однако существует опция Telnet, описанная в RFC 856 [Postel and Reynolds 1983b], которая, позволяет передавать 8-битные данные.)

 

Имя	Код (десятичный)	Описание
EOF	236	конец файла
SUSP	237	подавить текущий процесс (управление задачами)
ABORT	238	прекратить процесс
EOR	239	конец записи
SE	240	конец подопции
NOP	241	пустая операция
DM	242	маркер данных
BRK	243	прерывание
IP	244	прервать процесс
AO	245	прекратить вывод
AYT	246	вы здесь?
EC	247	escape символ
EL	248	стереть строку
GA	249	идем дальше
SB	250	начало подопции
WILL	251	обсуждение опции (рисунок 26.9)
WONT	252	обсуждение опции
DO	253	обсуждение опции
DONT	254	обсуждение опции
IAC	255	байт данных 255

Команды Telnet, предваряемые IAC (255).

 

Большинство из этих команд используется достаточно редко.

Обсуждение опций

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

Каждая сторона может послать один из четырех различных запросов для любой заданной опции.

 

1. WILL. Отправитель хочет включить эту опцию для себя.

2. DO. Отправитель хочет, чтобы получатель включил эту опцию.

3. WONT. Отправитель хочет выключить эту опцию для себя.

4. DONT. Отправитель хочет, чтобы получатель выключил опцию.

 

Так как правила Telnet позволяют стороне принять или отклонить запрос на включение опции (случаи 1 и 2), однако требуют, чтобы она всегда удовлетворяла запрос на выключение опции (случаи 3 и 4), из этих четырех возможных случаев может получиться шесть комбинаций:

 

	Отправитель		Получатель	Описание
1.	WILL	-> <-	DO	отправитель хочет включить опцию получатель говорит ДА
2.	WILL	-> <-	DONT	отправитель хочет включить опцию получатель говорит НЕТ
3.	DO	-> <-	WILL	отправитель хочет, чтобы получатель включил опцию получатель говорит ДА
4.	DO	-> <-	WONT	отправитель хочет, чтобы получатель включил опцию получатель говорит НЕТ
5.	WONT	-> <-	DONT	отправитель хочет выключить опцию получатель должен сказать ДА
6.	DONT	-> <-	WONT	отправитель хочет, чтобы получатель выключил опцию получатель должен сказать ДА

Шесть сценариев обсуждения опции Telnet.

 

Обсуждение опции занимает 3 байта: IAC байт, за которым следует байт WILL, DO, WONT или DONT, затем ID байт, указывающий на ту опцию, которую необходимо включить или выключить. Таким образом, может быть обсуждено 40 опций. Описания опций и их кодирование специфицировано в нескольких документах RFC (Request for Comments). Примерами могут служить:

 

ID опции (десятичный)	Имя	RFC
1	эхо	857
3	запрещение команды go ahead	858
5	статус	859
6	маркер времени	860
24	тип терминала	1091
31	размер окна	1073
32	скорость терминала	1079
33	удаленный контроль потоком данных	1372
34	линейный режим (linemode)	1184
36	переменные окружения	1408

Коды опций Telnet.

 

Обсуждение опции Telnet, как и многое другое в протоколе Telnet, процесс симметричный. Каждая сторона может начать процесс обсуждения опции. Однако заход удаленным терминалом не является симметричным процессом. Клиент решает свои задачи, а сервер свои. Некоторые опции Telnet применимы только к клиенту (например, требование включить линейный режим (linemode)), а некоторые предназначены только для сервера.

Обсуждение подопций

Некоторые опции требуют большего количества информации, нежели просто "включить" (enable) или "выключить" (disable). Например, установка типа терминала: для того чтобы клиент мог идентифицировать тип терминала, он должен отправить ASCII строку. Чтобы обработать эти опции, применяется обсуждение подопций.

Если клиент просит включить опцию, отправляя 3-байтовую последовательность

 

<IAC, WILL, 24>

 

где 24 (десятичное) это идентификатор опции типа терминала. Если получатель (сервер) говорит ДА, его ответ будет выглядеть как

 

<IAC, DO, 24>

 

Затем сервер посылает

 

<IAC, SB, 24, 1, IAC, SE>

 

спрашивая о типе терминала клиента. SB это команда, которая сообщает о начале подопций (suboption-begin). Следующий байт равный 24 указывает на то, что это подопция типа терминала. (SB всегда следует за номером опции, к которой относятся подопции.) Следующий байт равный 1 означает "отправьте ваш тип терминала". Перед командой конец подопций (suboption-end) должен опять стоять IAC, так же как и перед командой SB. Клиент отвечает командой

 

<IAC, SB, 24, 0, 'I', 'B', 'M', 'P', 'C', IAC, SE>

 

в случае, если его тип терминала ibmpc. Четвертый байт равный 0 означает "у меня следующий тип терминала". ("Официальный" список приемлемых типов терминалов находится в Assigned Numbers RFC, однако для Unix систем приемлем любой тип терминала, поддерживаемый сервером. Обычно это терминалы, поддерживаемые базами termcap или terminfo.) Типы терминалов, указываемые в подопциях Telnet, пишутся большими буквами и обычно преобразуются в маленькие буквы уже сервером.

Полудуплексный, символ за один раз, строка за один раз или линейный режим (Linemode)?

Существуют четыре режима, в которых функционирует большинство Telnet клиентов и серверов: 

1. Полудуплексный.

Этот режим используется редко. (NVT по умолчанию это полудуплексное устройство, которое требует исполнения команды GO AHEAD (GA) от сервера, перед тем как будет принят ввод от пользователя. Ввод пользователя отображается локальным эхом от NVT клавиатуры на NVT принтер, таким образом, от клиента к серверу посылаются только полные строки.)

2. Символ за один раз.

Именно таким образом работает Rlogin. Каждый вводимый символ отправляется серверу отдельно от других. Сервер отражает эхом большинство символов, если только у приложения на сервере не отключено отражение эхом.

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

Для того чтобы сервер мог войти в этот режим, у него должна быть включена опция SUPPRESS GO AHEAD. Обсуждение этой опции осуществляется следующим образом: клиент посылает DO SUPPRESS GO AHEAD (требуя от сервера, чтобы тот включил опцию), или сервер посылает WILL SUPPRESS GO AHEAD клиенту (спрашивая о возможности включить эту опцию для самого себя). Затем сервер осуществляет WILL ECHO, спрашивая о возможности включить отражение эхом.

3. Строка за один раз.

Часто это называется "kludge line mode", потому что его реализация приходит от чтения между строк в RFC 858. Этот RFC декларирует, что должны присутствовать обе опции ECHO и SUPPRESS GO AHEAD, чтобы обеспечить ввод символа за один раз с удаленным эхом. Таким образом, если какая-либо из этих опций не включена, Telnet находится в режиме строка за один раз.

4. Линейный режим (linemode).

В данном случае этот термин означает реальную опцию linemode, определенную в RFC 1184 [Borman 1990]. Эта опция обсуждается клиентом и сервером и корректирует все недостатки в режиме строка за один раз. Новые реализации поддерживают эту опцию.

 

Сигнал синхронизации (Synch)

Telnet использует команду Data Mark в качестве сигнала синхронизации который передается в виде срочных данных TCP. Команда DM это метка синхронизации в потоке данных, которая сообщает принимающему о необходимости вернуться в обычный режим работы. Он может быть отправлен в любом направлении по Telnet соединению.

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

Управление клиентом

Как и в случае Rlogin клиента, Telnet клиент так же позволяет пообщаться с ним, вместо того чтобы отправлять пользовательский ввод серверу. Стандартный символ, позволяющий осуществить переход в режим управления клиентом (escape), это Control-] (control и правая квадратная скобка, что обычно печатается как "^]"). При этом клиент выводит приглашение, обычно выглядящее как "telnet>". В ответ на это приглашение можно вводить команды, что позволяет сменить характеристики сессии или напечатать какую-либо информацию. Команда help поддерживается большинством Unix клиентов и отображает все доступные команды.

Протокол FTP

Данный протокол является стандартом Internet для передачи файлов. RFC 959 [Postel and Reynolds 1985] является официальной спецификацией FTP. Это один из старейших протоколов, до массового распространения HTTP именно на этот протокол приходилась основная часть трафика интернета.

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

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

FTP отличается от других приложений тем, что он использует два TCP соединения для передачи файла.

Первое - управляющее соединение устанавливается как обычное соединение клиент-сервер. Сервер осуществляет пассивное открытие на заранее известный порт FTP (21) и ожидает запроса на соединение от клиента. Клиент осуществляет активное открытие на TCP порт 21. Управляющее соединение существует все время, пока клиент общается с сервером. Это соединение используется для передачи команд от клиента к серверу и для передачи откликов от сервера

Второе - соединение для передачи данных открывается каждый раз, когда осуществляется передача файла между клиентом и сервером.

Процессы, участвующие в передаче файлов.

 

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

Представление данных

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

Первый пункт выбора: Тип файла.

Возможны следующие варианты

А - ASCII файлы (по умолчанию). Текстовый файл передается по соединению данных как NVT ASCII. При этом требуется, чтобы отправитель конвертировал локальный текстовый файл в NVT ASCII, а получатель конвертировал NVT ASCII в текстовый файл. Конец каждой строки передается в виде NVT ASCII символа возврата каретки, после чего следует перевод строки. Это означает, что получатель должен просматривать приходящий поток байт в поисках пары символов CR, LF.

Б - EBCDIC файлы (Extended Binary Coded Decimal Interchange Code — расширенный двоично-десятичный код обмена информацией; произносится «эб-си-дик». Разработанная IBM восьмибитная кодировка для мэйнфреймов). Альтернативный способ передачи текстовых файлов, когда на обоих концах системы использована кодировка EBCDIC.

С - Двоичные или бинарные файлы. Данные передаются как непрерывный поток битов.

Д - Локальный тип файлов. Способ передачи бинарных файлов между хостами, которые имеют различный размер байта. Количество битов в байте определяется отправителем. Для систем, которые используют 8-битные байты, локальный тип файла с размером байта равным 8 эквивалентен бинарному типу файла.

 

Второй пункт выбора: Управление форматом. Применяется только для ASCII и EBCDIC файлов. Варианты следующие:

А - Nonprint. (по умолчанию) Файл не содержит информацию вертикального формата.

Б - Telnet format control. Файл содержит управляющие символы вертикального формата Telnet.

С - Fortran carriage control. Первый символ каждой строки это Fortran символ управления формата.

 

Третий пункт выбора: Структура. Возможны три варианта.

А - Структура файла (по умолчанию). Файл воспринимается в виде непрерывного потока байтов. Файл не имеет внутренней структуры.

Б - Структура записи. Эта структура используется только в случае текстовых файлов (ASCII или EBCDIC).

С - Структура страницы. Каждая страница передается со своим номером, что позволяет получателю хранить страницы в случайном порядке. Практически не поддерживается. 

Последний, четвертый пункт выбора: Режим передачи. Указывает на то, как файл передается по соединению данных.

А - Режим потока (по умолчанию). Файл передается как поток байтов. Для файловой структуры конец файла указывает на то, что отправитель закрывает соединение данных. Для структуры записи специальная 2-байтовая последовательность обозначает конец записи и конец файла.

Б - Режим блоков. Файл передается как последовательность блоков, перед каждым из них стоит один или несколько байт заголовков.

С - Сжатый режим. Простое кодирование неоднократно встречающихся повторяющихся байт. В текстовых файлах обычно сжимаются пустые строки или строки из пробелов, а в бинарных строки из нулевых байт.  

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

Самые распространенные Unix реализации FTP клиента и сервера предоставляют следующий выбор:

• Тип: ASCII или двоичный.

• Управление форматом: только nonprint.

• Структура: только файловая структура.

• Режим передачи: только потоковый режим.

Это ограничивает нас одним из двух режимов: ASCII или двоичный.

 

Команды FTP

Команды и отклики передаются по управляющему соединению между клиентом и сервером в формате NVT ASCII. В конце каждой строки команды или отклика присутствует пара CR, LF.

Клиент FTP может воспользоваться двумя командами Telnet - это команда прерывания процесса (<IAC, IP>) и Telnet сигнал синхронизации, использующий режим срочности (<IAC, DM> в режиме срочности). Эти команды используются для прекращения передачи файла или для того, чтобы отправить серверу запрос в процессе передачи.

Имеется также более 30 различных FTP команд, состоящих из 3 или 4 байт, а именно из заглавных ASCII символов, некоторые с необязательными аргументами. Приведем некоторые из них в таблице:

 

Команда	Описание
ABOR	прервать предыдущую команду FTP и любую передачу данных
LIST список файлов	список файлов или директорий
PASS пароль	пароль на сервере
PORT n1,n2,n3,n4,n5,n6	IP адрес клиента (n1.n2.n3.n4) и порт (n5 x 256 + n6)
QUIT	закрыть бюджет на сервере
RETR имя файла	получить (get) файл
STOR имя файла	положить (put) файл
SYST	сервер возвращает тип системы
TYPE тип	указать тип файла: A для ASCII, I для двоичного
USER имя пользователя	имя пользователя на сервере

Распространенные FTP команды.

 

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

FTP отклики

Отклики состоят из 3-циферных значений в формате ASCII, и необязательных сообщений, которые следуют за числами. Цифровые значения предназначены программному обеспечению, а дополнительная строка может быть выведена пользователю. Каждая из трех цифр в коде отклика имеет собственный смысл. Значения первых и вторых цифр в коде отклика представлены ниже.

 

Отклик	Описание
1yz	Положительный предварительный отклик. Действие началось, однако необходимо дождаться еще одного отклика перед отправкой следующей команды.
2yz	Положительный отклик о завершении. Может быть отправлена новая команда.
3yz	Положительный промежуточный отклик. Команда принята, однако необходимо отправить еще одну команду.
4yz	Временный отрицательный отклик о завершении. Требуемое действие не произошло, однако ошибка временная, поэтому команду необходимо повторить позже.
5yz	Постоянный отрицательный отклик о завершении. Команда не была воспринята и повторять ее не стоит.
x0z	Синтаксическая ошибка.
x1z	Информация.
x2z	Соединения. Отклики имеют отношение либо к управляющему, либо к соединению данных.
x3z	Аутентификация и бюджет. Отклик имеет отношение к логированию или командам, связанным с бюджетом.
x4z	Не определено.
x5z	Состояние файловой системы.

Значения первой и второй цифр в 3-циферном коде отклика.

 

Третья цифра дает дополнительное объяснение сообщению об ошибке. Ниже приведены некоторые типичные отклики с возможными объясняющими строками.

• 125 Соединение данных уже открыто; начало передачи.

• 200 Команда исполнена.

• 214 Сообщение о помощи (для пользователя).

• 331 Имя пользователя принято, требуется пароль.

• 425 Невозможно открыть соединение данных.

• 452 Ошибка записи файла.

• 500 Синтаксическая ошибка (неизвестная команда).

• 501 Синтаксическая ошибка (неверные аргументы).

• 502 Нереализованный тип MODE.

Обычно каждая FTP команда генерируют отклик в одну строку. Например, команда QUIT сгенерирует следующий отклик: 221 Goodbye.

 

Если необходим отклик в несколько строк, первая строка содержит дефис вместо пробела после 3-циферного кода отклика, а последняя строка содержит тот же самый 3-циферный код отклика, за которым следует пробел

 

Управление соединением

Использовать соединение данных можно тремя способами.

1. Отправка файлов от клиента к серверу.

2. Отправка файлов от сервера к клиенту.

3. Отправка списка файлов или директорий от сервера к клиенту.

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

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

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

1. Создание соединения данных осуществляется клиентом, потому что именно клиент выдает команды, которые требуют передать данные (получить файл, передать файл или список директории).

2. Клиент выбирает динамически назначаемый номер порта на хосте клиента для своего конца соединения данных и осуществляет пассивное открытие с этого порта.

3. Клиент посылает этот номер порта на сервер по управляющему соединению с использованием команды PORT.

4. Сервер принимает номер порта с управляющего соединения и осуществляет активное открытие на этот порт хоста клиента. Сервер всегда использует порт 20 для соединения данных.

 

На рисунке показано состояние соединений на третьем шаге процесса. Порт клиента управляющего соединения имеет номер 1173, а порт клиента для соединения данных назначен с номером 1174. Команда, посылаемая клиентом - PORT, а ее аргументы это шесть десятичных цифр в формате ASCII, разделенные запятыми. Четыре первых числа - это IP адрес клиента, на который сервер должен осуществить активное открытие (140.252.13.34 в данном примере), а следующие два - это 16-битный номер порта. Так как 16-битный номер порта формируется из двух цифр, его значение в этом примере будет 4 x 256 + 150 = 1174.

Команда PORT, передаваемая по управляющему соединению FTP.

На следующем рисунке показано состояние соединений, когда сервер осуществляет активное открытие соединения данных. Конечная точка сервера - это порт 20.

FTP сервер осуществляет активное открытие соединения данных.

 

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

Если клиент не выдает команду PORT, сервер осуществляет активное открытие на тот же самый номер порта, который использовался клиентом для управляющего соединения (1173 в данном примере). В этом случае все работает корректно, так как номера порта сервера для двух соединений различны: один 20, другой 21. Однако современные реализации не используют эту возможность.

Анонимный FTP

Популярной формой использования FTP является анонимный FTP (anonymous FTP). Если эта форма поддерживается сервером, она позволяет любому получить доступ к серверу и использовать FTP для передачи файлов. С помощью анонимного FTP можно получить доступ к огромному объему свободно распространяемой информации. В качестве имени пользователя в этом случае обычно используется "anonymous", а пароля адрес электронной почты пользователя.

Анонимный FTP с неизвестного IP адреса

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