Глава 20 FTP
Глава 20 FTP
Эта глава посвящена протоколу FTP, настройке сервера FTP, проблемам конфигурации и безопасности сервера.
Протокол FTP
Протокол FTP (File Transfer Protocol, протокол передачи файлов) предназначен для передачи файлов в сети Интернет. Этот протокол был разработан на заре эры Интернета и по сию пору остается востребованным и актуальным. Конечно, он несколько устарел, частично функции передачи файлов взял на себя Web-протокол HTTP, но, несмотря на это, протокол FTP, похоже, будет использоваться еще долгое время.
Передача файлов заключается в копировании целого файла с одного компьютера на другой. Для использования FTP-сервиса необходимо иметь учетную запись на сервере для авторизованного доступа, или воспользоваться анонимным доступом к FTP (anonymous FTP).
Протокол FTP, в отличие от большинства других протоколов, для пересылки файла использует два TCP-соединения. Одно соединение собственно для пересылки файла, а второе – для управления процессом передачи (управляющее соединение). Порт 20 предназначен для пересылки данных, а порт 21 для управляющего соединения. FTP-протокол может использовать как TCP-соединение, так и UDP-соединение.
Представление данных
Протокол передачи файлов допускает различные способы представления файлов и управления передачей. Ниже приведены критерии, от выбора которых зависит корректность передачи файлов по протоколу FTP.
Тип файла
Протокол должен знать, каков тип передаваемого файла. От этого зависит корректное представление его на компьютере (и в операционной системе) получателя.
• ASCII-файлы. Текстовый файл передается как NVT ASCII. При этом требуется, чтобы программа-отправитель конвертировала текстовый файл в NVT ASCII, а программа-получатель производила обратное преобразование. Конец каждой строки передается в виде NVT ASCII-символа возврата каретки (CR), после которого следует перевод строки (LF). Если отправитель текстового файла установит тип файла как бинарный – программы не будут преобразовывать передаваемый файл. Это вызывает проблемы несовместимости между текстовыми файлами DOS/Windows и текстовыми файлами UNIX. В DOS/Windows принято конец текстовой строки обозначать парой символов «возврат каретки/перевод строки» (CR LF), а в UNIX – перевод строки (LF).
• EBCDIC-файлы. Альтернативный способ передачи текстовых файлов, когда на обоих концах системы EBCDIC.
• Бинарные файлы. Данные между FTP-сервером и клиентом передаются как непрерывный поток битов.
• Локальный тип файлов. Способ передачи бинарных файлов между компьютерами, которые имеют различный размер байта. Количество битов в байте определяется отправителем. Обычно не используется.
Управление форматом
Применяется только для передачи ASCII– и EBCDIC-файлов.
• Nonprint. Файл не содержит информацию вертикального форматирования.
• Telnet format control. Файл содержит управляющие символы вертикального форматирования telnet, которые интерпретируются принтером.
• Fortran carriage control. Первый символ каждой строки это Fortran-символ управления форматированием.
Структура
Способы передачи структуры данных приведены ниже.
• Структура файла. Пересылаемый файл воспринимается в виде непрерывного потока байтов.
• Структура записи. Эта структура используется только в случае текстовых файлов.
• Структура страницы. Каждая страница передается с номером страницы (не рекомендуется использовать эту структуру).
Режим передачи
Определяет способ передачи файла по соединению данных.
• Потоковый режим. Передача файла осуществляется как поток байтов.
• Блочный режим. Передача файла осуществляется как последовательность блоков. Блок имеет управляющий заголовок и собственно пересылаемые данные.
• Режим сжатия. При передаче осуществляется замена неоднократно встречающихся повторяющихся байтов на байт и число его повторений.
Как видите, протокол FTP поддерживает большое количество представлений данных. Однако в реальной жизни большинством программного обеспечения наиболее часто используется нижеприведенное ограниченное подмножество представлений:
• тип файла – ASCII или двоичный;
• управление форматом – только nonprint;
• структура – только структура файла;
• режим передачи – только потоковый режим.
Управляющие команды FTP
Управляющие команды и ответы передаются по управляющему соединению между клиентом и сервером в формате NVT ASCII. В конце каждой строки присутствует пара символов «возврат каретки/перевод строки» (CR/LF).
В полном наборе команд насчитывается более 30-ти. В табл. 20.1 приведены наиболее часто используемые команды. Полный список команд можно посмотреть в соответствующем RFC.
Таблица 20.1. Управляющие команды протокола FTP
Ответы на управляющие FTP-команды
Ответы на управляющие FTP-команды состоят из трехзначного числа в формате ASCII и необязательного текстового сообщения, которое следует за числом.
Каждая из трех цифр в коде ответа имеет собственное значение. Расшифровка первой и второй цифр кода приведена в табл. 20.2.
Таблица 20.2. Значения первой и второй цифр в коде ответа на управляющие команды
Третья цифра дает уточняющее определение сообщению об ошибке. В табл. 20.3 приведены соответствующие коды и пояснения.
Таблица 20.3. Значения третьей цифры в коде ответа на управляющие команды
Обычно каждая FTP-команда генерирует однострочный ответ. Если необходим ответ, состоящий из нескольких строк, то первая строка содержит дефис вместо пробела после трехзначного кода отклика, а последняя строка содержит тот же самый трехзначный код отклика, за которым следует пробел.
Управление соединением
Использовать соединение данных можно тремя способами:
1. Отправка файлов от клиента к серверу.
2. Отправка файлов от сервера к клиенту.
3. Отправка списка файлов или каталогов от сервера к клиенту.
Третий способ необходимо пояснить. FTP-сервер посылает список файлов по соединению данных – при таком использовании канала данных появляется возможность избежать любых ограничений в строках, накладывающихся на размер списка каталога, и несколько упрощает обмен информацией.
Управляющее соединение остается в активизированном состоянии все время, пока установлено соединение клиент-сервер, но соединение данных может устанавливаться и отключаться по необходимости. Рассмотрим, как выбираются номера портов для соединения данных, и кто осуществляет активное открытие, а кто пассивное.
Основной режим передачи – потоковый режим. В этом режиме конец файла обозначает закрытие соединения данных. Из этого вытекает, что для передачи каждого файла требуется новое соединение данных. Обычная процедура выглядит следующим образом:
1. Создание соединения данных осуществляется клиентом.
2. Клиент выбирает динамически назначаемый номер порта на компьютере клиента для своего конца соединения данных и осуществляет пассивное открытие с этого порта.
3. Клиент посылает номер порта на сервер по управляющему соединению с использованием команды port.
4. Сервер принимает номер порта с управляющего соединения и осуществляет активное открытие на этот порт компьютера клиента. Сервер всегда использует порт 20 для соединения данных.
Сервер всегда осуществляет активное открытие соединения данных. Обычно сервер также осуществляет активное закрытие соединения данных, за исключением тех случаев, когда клиент отправляет файл на сервер в потоковом режиме, который требует, чтобы клиент закрыл соединение.
Если клиент не выдает команду port, сервер осуществляет активное открытие на тот же самый номер порта, который использовался клиентом для управляющего соединения.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКДанный текст является ознакомительным фрагментом.
Читайте также
Глава 17 DNS
Глава 17 DNS DNS – это Доменная Система Имен (Domain Name System). DNS преобразует символические имена машин в IP-адреса и наоборот – из IP-адреса в символическое имя. Для чего это нужно? Во-первых, человеку легче запомнить осмысленное имя – типа vasya.ru чем 195.66.195.42, а для компьютера проще
Глава 20 FTP
Глава 20 FTP Эта глава посвящена протоколу FTP, настройке сервера FTP, проблемам конфигурации и безопасности сервера.Протокол FTPПротокол FTP (File Transfer Protocol, протокол передачи файлов) предназначен для передачи файлов в сети Интернет. Этот протокол был разработан на заре эры
ГЛАВА 14
ГЛАВА 14 Переменные среды и интерпретатора shellЧтобы продуктивно работать с интерпретатором shell, нужно уметь управлять переменными этого интерпретатора. Переменными интерпретатора shell являются наименования, которым присваиваются значения. В качестве значений может
ГЛАВА 15
ГЛАВА 15 Использование кавычекВ главе 14 обсуждались методы работы с переменными и операции подстановки. Чаще всего ошибки в использовании кавычек возникают при выполнении подстановок переменных в сценариях. Кавычки оказывают существенное влияние на формирование
ГЛАВА 16
ГЛАВА 16 Понятие о shell–сценарииВ shell–сценарий может включаться одна или несколько команд; здесь нет общепринятых правил. Зачем же создавать целый сценарий ради двух–трех команд? Все зависит от предпочтений пользователя.В этой главе рассматриваются следующие
ГЛАВА 17
ГЛАВА 17 Проверка условийПри создании сценария уточняется идентичность строк, права доступа к файлу или же выполняется проверка численных значений. На основе результатов проверки предпринимаются дальнейшие действия. Проверка обычно осуществляется с помощью команды test.
ГЛАВА 18
ГЛАВА 18 Управляющие конструкцииВсе функциональные сценарии должны предлагать возможности по выбору возможных вариантов. При определенных условиях сценарии должны выполнять обработку списков. Этим вопросам посвящена настоящая глава. Кроме того, в ней описывается
ГЛАВА 19
ГЛАВА 19 Функции интерпретатора shellДо сих пор весь программный код сценариев данной книги выполнялся последовательно от начала до конца программы. Подобный подход неплох, но при этом некоторые фрагменты кода, рассмотренного в наших примерах, дублируются в пределах
ГЛАВА 21
ГЛАВА 21 Создание экранного выводаС помощью shell–сценариев можно создавать профессионального вида экраны, позволяющие реализовать интерактивное взаимодействие пользователя с системой. Для этого достаточно располагать цветным монитором и использовать команду tput.В
ГЛАВА 22
ГЛАВА 22 Создание экранного вводаКогда речь идет об экранном вводе, или вводе данных, подразумевают ввод информации (в нашем случае с помощью клавиатуры), а затем — проверку достоверности введенных данных. Если данные удовлетворяют неким критериям, они
ГЛАВА 23
ГЛАВА 23 Отладка сценариевОдной из самых сложных задач при создании shell–сценариев является их отладка. Желательно, чтобы пользователь, выполняющий эту задачу, получил консультации на данном этапе. Чтобы избежать распространенных ошибок, достаточно следовать указанному
ГЛАВА 24
ГЛАВА 24 Встроенные команды интерпретатора shellВ предыдущих главах нам уже встречались конструкции, встроенные в интерпретатор shell Напомним, что речь идет о командах, которые не находятся в каталоге /bin или usr/bin, а встроены в интерпретатор Bourne shell. Скорость выполнения
ГЛАВА 25
ГЛАВА 25 Дальнейшее изучение конструкции "документ здесь"При рассмотрении стандартного потока ввода и вывода, а также циклов while уже обсуждалась конструкция "документ здесь". Описывались методика пересылки электронной почты и способы формирования экранов меню, но
ГЛАВА 26
ГЛАВА 26 Утилиты интерпретатора shellВ этой главе рассматриваются следующие темы: • создание датируемых имен файлов и временных файлов; • сигналы; • команда trap и способы перехвата сигналов; • команда eval; • команда
ГЛАВА 28
ГЛАВА 28 Сценарии уровня выполненияЕсли при загрузке системы вам нужно автоматически запустить приложение, службу или сценарий либо корректно завершить их работу при перезапуске системы, то необходимо создать сценарий уровня выполнения. Почти все варианты системы Linux, а
ГЛАВА 29
ГЛАВА 29 Сценарии cgiВ настоящее время, когда практически на каждом ПК установлен Web–сервер, глава, посвященная сценариям cgi, органически вписывается в книгу по shell–программированию.В главе будут рассмотрены следующие темы: • базовые сценарии cgi; • использование