Протоколы Интернета и электронной почты
После обсуждения базовых протоколов мы можем подняться на более высокий уровень. Протоколы HTTP и FTP охватывают уровни 5—7 модели OSI.
FTP — File Transfer Protocol
FTP используется для копирования файлов с сервера и на сервер, а также для получения списка файлов и каталогов на сервере. FTP — это протокол прикладного уровня, базирующийся на TCP. Команды FTP включаются в блок данных TCP-сообщения.
Модель приложения с FTP-сервером и клиентом проиллюстрирована на следующем рисунке. Приложение-клиент представляет пользовательский интерфейс и создает FTP-запрос в соответствии с запросом пользователя и спецификацией FTP. FTP-команда посылается приложению-серверу через TCP/IP, и интерпретатор на сервере соответственно интерпретирует FTP-команду. В зависимости от FTP-команды в FTP-ответе клиенту возвращается с сервера список файлов или конкретный файл:
Протокол FTP имеет следующие характеристики:
Надежная передача данных через TCP
Анонимный доступ или аутентификация пользователя по имени и паролю
Файлы отправляются в ASCII-коде в форме, поддерживаемой целевой платформой, или как неизмененные двоичные данные.
FTP-команды можно сгруппировать в следующие категории:
Команды контроля доступа
В FTP-командах контроля доступа указывается имя пользователя (USER) и пароль (PASS), установки могут изменяться (REIN), и соединение может быть закончено (QUIT).
Команды параметров передачи
FTP-передачу можно конфигурировать с помощью команд параметров передачи. Эти команды поддерживают изменение ASCII-кода на двоичный код, сжатие данных, изменение портов для отправки.
Команды FTP-сервиса
Копирование файлов с сервера (RETR), копирование файлов на сервер (STOR), удаление файлов (DELE), переименование файлов (RNTO), создание каталогов (MKD) и запрос списка файлов (LIST) — вот некоторые команды FTP-сервиса.
Протокол FTP определен в RFC 959.
FTP-клиенты
Установка имени пользователя anonymous означает пользователя-гостя. Ответ 230 от сервера указывает, что соединение установлено и можно командой dir получить список файлов на сервере. Получив команду dir, программа ftp отправляет на сервер команду FTP LIST. Команда cd может применяться для смены директории на сервере, а команда get копирует файл клиенту, отправляя команду FTP RETR. Для закрытия соединения утилита ftp использует команду bye:
HTTP — Hypertext Transfer Protocol
HTTP — основной протокол, используемый Web-приложениями. Как и FTP, HTTP является надежным протоколом, и надежность его достигается благодаря использованию TCP. Как и FTP, HTTP также используется для передачи файлов через сеть. Но он в отличие от FTP обладает такими средствами, как кэширование, идентификация приложения-клиента, поддержка разных дополнений в формате MIME и т. д. Эти средства устанавливаются в заголовке HTTP.
Для демонстрации работы, выполняемой браузером Интернета, когда он запрашивает файлы из Web-сервера, мы можем имитировать браузер приложением telnet. Для запуска этого приложения введите telnet в диалоговом окне Run меню Start, и вы увидите приглашение Microsoft Telnet. Введите set local_echo (set localecho для Windows XP), чтобы введенные программы отображались локально. Если не устанавливать эту опцию, команды, которые мы отправляем на сервер, не будут отображаться приложением telnet.
Теперь можно соединиться с Web-cepвeром командой open. Команда open msdn.microsoft.com 80 создает TCP-соединение с портом 80 сервера на msdn.microsoft.com. Приложение telnet использует по умолчанию порт 23, следовательно, надо указать порт для HTTP-запроса. По умолчанию HTTP-сервисы предоставляются портом 80 Web-сервера.
Как только соединение инициировано, можно послать на Web-cepвep HTTP-запрос. Простой запрос состоит из строки запроса, которую нужно завершить двумя нажатиями на клавишу Enter (две последовательности CR-LF). Такая строка запроса может выглядеть, как: GET /default.asp HTTP/1.0. Сервер возвращает HTTP-ответ, содержащий информацию о статусе.
Как видно, элементарный HTTP-запрос состоит лишь из одной строки. Однако полный HTTP-запрос будет состоять из строки запроса с дополнительными заголовками и данными.
В строке запроса можно указывать такие HTTP-команды, как GET, HEAD и POST. И GET, и POST запрашивают данные от сервера. Команда GET включает параметры запроса в URL, а в команде POST параметры находятся в блоке данных. Команда HEAD означает, что мы просто хотим узнать, когда был изменен запрашиваемый файл, чтобы проверить, находится ли в кэше новейшая его версия.
За строкой запроса могут следовать общие заголовки, заголовки запроса и заголовок сущности. Информация, помещаемая в заголовки, позволяет клиенту сообщать серверу об используемом браузере и предпочтительных языках, отправлять файл cookie или запрашивать только изменившиеся файлы. В примере с telnet мы уже видели некоторую информацию из заголовков, возвращенную сервером: дату, версию сервера, длину содержания, тип содержания и признаки управления кэшем.
HTTPS — HTTP поверх SSL (Secure Socket Layer)
Для поддержки HTTPS Web-сервер должен установить сертификат, чтобы его можно было идентифицировать. По умолчанию для HTTPS-запросов используется порт 443.
SMTP — Simple Mail Transfer Protocol
SMTP — это протокол, предназначенный для отправки и получения сообщений электронной почты. Он может использоваться для пересылки электронной почты между клиентом и сервером, использующими один и тот же транспортный протокол, или для пересылки сообщений между серверами, использующими разные транспортные протоколы. SMTP имеет возможность пересылать сообщения через среду транспортной службы. Однако SMTP не позволяет читать сообщения с почтового сервера, для этого используются протоколы POP3 и IMAP.
Служба SMTP составляет часть установки Internet Information Server в Windows 2000 и Windows XP.
Стандарт протокола SMTP определен в RFC 821; формат сообщений SMTP определен в RFC 822.
POP3 — Post Office Protocol
Протокол POP3 предназначался для отсоединенной среды. В небольших конфигурациях непрактично поддерживать постоянное соединение с почтовым сервером, например в такой среде, где время соединения нужно оплачивать. При использовании POP3 клиент может обращаться к серверу и извлекать сообщения, которые хранит для него сервер. Когда сообщения считываются клиентом, они обычно (но необязательно) удаляются с сервера.
IMAP — Internet Message Access Protocol
Как и РОРЗ, протокол IMAP предназначен для доступа к почте на почтовом сервере. Аналогично клиентам POP3 клиент IMAP может работать в автономном режиме, в котором почта обрабатывается на локальной машине. По сравнению с клиентами POP3 клиенты IMAP обладают более широкими возможностями в оперативном режиме, например, они могут извлекать только заголовки или только основные части указанных почтовых сообщений, искать конкретные сообщения на сервере и устанавливать флаги, например флаг «ответ отправлен». По существу, IMAP позволяет клиенту обрабатывать удаленный почтовый ящик, как если бы он был локальным.
Протокол IMAP определен в RFC 1730.
NNTP — Network News Transfer Protocol
Протокол NNTP определен в RFC 850, 977 и 1036.
Ftp http что это
Эта статья — попытка описать основные различия между известными протоколами обмена данными FTP и HTTP.
Мы активно используем оба протокола в нашем основном продукте — корпоративном мессенджере MyChat уже много лет, и за это время столкнулись со многими заблуждениями и непониманием работы этих двух фундаментальных протоколов обмена файлами в Интернете.
Если вы увидите какие-то ошибки или неточности, напишите об этом на форуме.
Дисклэймер: в английском языке есть два термина: “upload” и “download”. В русском нет хороших аналогов, поэтому для файлов, которые мы отдаём с клиента на сервер, применяем слово “заливать” (upload), а для файлов, которые забираем на клиент с сервера — используем слово “скачивать” (“download”).
Оба протокола используются для скачивания и заливки файлов в Интернете и локальных сетях. Для текста и бинарных данных. Оба протокола работают поверх TCP/IP. Но между ними есть несколько серьёзных различий.
Скорость передачи
Наверное, самый распространённый вопрос: что быстрее для передачи файлов, FTP или HTTP?
Что делает FTP быстрым?
Что делает HTTP быстрым?
В конечном итоге чистый результат, конечно, зависит от конкретных деталей, но я бы сказал, что для одиночных статических файлов вы не сможете увидеть ощутимую разницу.
Для одиночного файла небольшого размера и медленного соединения FTP покажет себя лучше. При получении нескольких файлов подряд (особенно небольших размеров) HTTP обычно показывает лучший результат.
Возраст
FTP (RFC959) появился за десять лет до того, как был придуман HTTP. В то время FTP был единственным протоколом в Интернете. Первые зачатки того, что впоследствии стало документом RFC959, можно найти в далёком 1971 году.
Заливка
Оба протокола умеют это делать. У FTP есть команда «append», HTTP исповедует подход «вот вам данные, а вы сами разбирайтесь, что с ними делать», то есть, никаких команд по управлению заливаемыми файлами нет.
Следует сказать, что существует протокол WebDAV, построенный поверх HTTP, который позволяет работать с файлами в традиционной манере, будто они находятся на вашем локальном устройстве.
Форматы ASCII, EBCDIC или бинарный
FTP имеет представление о формате файла, поэтому может передавать данные как в ASCII, так и в двоичном виде (raw bytes). HTTP же всегда отправляет файлы в двоичном виде. Таким образом, FTP умеет преобразовывать данные «на лету», если они передаются между системами с разными архитектурами (Windows/Linux/мэйнфрэймы).
Например, если отправитель использует одну схему для кодирования конца строки («EOL» — End-Of-Line), а получатель — другую, то FTP сделает так, что они друг друга поймут. Unix использует только символ NL (newLine x0A), а MS Windows два символа подряд, CR и LF (CarriageReturn и LineFeed — x0D0A). EBCDIC перекодировки используются на старых мэйнфреймах.
HTTP, в противовес FTP, предоставляет метаданные для файлов, «Content-Type». Таким образом, метаданные могут использоваться клиентами для интерпретации содержимого.
Заголовки
Передача файлов через HTTP всегда включает в себя набор заголовков, в которых находятся метаданные. FTP никогда не передаёт никаких заголовков. В связи с этим, при передаче большого количества мелких файлов, их заголовки будут составлять значительную часть трафика. В заголовках HTTP находится информация о дате и времени модификации файлов, кодировке символов, имени сервера и его версии и т.п.
Пайплайны или конвейеры
HTTP поддерживает конвейерную обработку данных. Это означает, что клиент может запросить новую передачу файлов до того, как закончится предыдущая, что даёт возможность убрать задержки при закачке нескольких документов подряд. TCP пакеты, таким образом, будут оптимизированы для максимальной скорости передачи.
Что-то подобное, хотя и не совсем похожее, есть и в FTP. Это поддержка множественных запросов для параллельного получения файлов в одном управляющем соединении. Конечно, для этого нужно использовать новые TCP соединения для передачи бинарных данных, по одному для каждого файла, однако, далеко не все FTP серверы поддерживают такие возможности.
FTP команды/ответы
FTP клиент может отправлять на сервер множество команд и получать на них ответы от сервера. Даже передача одного файла включает в себя целую серию таких простых команд. Это, конечно, негативно сказывается на скорости, потому что каждая команда требует обработки на двух сторонах: клиенте и сервере. Из-за этого возникают задержки. HTTP передачи данных – это преимущественно, только один запрос и один ответ (для каждого файла). Получение одного файла через FTP иногда может занимать до десятка команд и ответов между клиентом и сервером.
Два соединения
Одна из самых больших проблем для FTP в реальной работе — это использование двух соединений. Первое — для отправки управляющих команд, а второе — для передачи содержимого файла. Для этой цели он каждый раз открывает отдельный поток TCP. Если вы передаёте 100 файлов, по очереди будут открыты и закрыты 100 TCP соединений.
Файрволы и NAT
FTP использует два соединения: управляющее и для передачи данных. Соединение для данных может идти в двух направлениях, и использовать динамические номера портов. Это добавляет головной боли администраторам и зачастую требует от файрволов понимания специфики функционирования FTP на уровне сетевого протокола, чтобы обеспечить нормальную работу.
Это также означает, что если обе стороны соединения находятся за NAT, вы, скорее всего, не сможете пользоваться FTP.
Кроме того, NAT убивает незанятые соединения, через которые длительное время не было передачи данных. Поэтому, во время долгих передач по FTP на медленных каналах связи мы оказываемся в ситуации, когда соединение оказывается разорванным, потому что NAT решил, что оно уже неактивно.
Чтобы такого не происходило, приходится время от времени отправлять фиктивные пустые команды, чтобы соединение поддерживалось в «живом» состоянии. Результат — небольшой, но лишний трафик.
Активный и пассивный режимы
FTP открывает второе соединение в активном или пассивном режиме. Если работает активный режим (соединение инициирует сервер) — будут проблемы с соединением в сложных сетях, потому что такое соединение невозможно через NAT. Поэтому, в большинстве случаев используется пассивный режим (passive mode), когда соединение происходит только со стороны клиента.
Зашифрованные управляющие соединения
Поскольку брандмауэры должны уметь «разбирать по косточкам» управляющее соединение FTP, чтобы дать возможность корректно открывать второе соединение для передачи бинарных данных, существует огромная проблема с зашифрованными соединениями (FTP-SSL или FTPS). Как только управляющее соединение становится зашифрованным, файрвол уже не в состоянии интерпретировать его команды, чтобы понимать, когда и как следует разрешить второе соединение между клиентом и сервером для передачи бинарных данных.
К тому же, разработка самого стандарта FTPS заняла слишком много времени, что привело к одновременному существованию нескольких гибридных версий, плохо совместимых между собой.
Схемы авторизации
У FTP и HTTP есть несколько документированных методов аутентификации. Оба протокола предлагают базовую аутентификацию обычным текстом (логин/пароль). Однако, для HTTP существуют несколько часто используемых методов проверки, которые не отправляют пароль в виде обычного текста, в отличие от FTP.
Скачивание
Оба протокола умеют это делать. У обоих протоколов были проблемы при скачивании файлов с размером, больше чем 2 гигабайта, но это уже в прошлом. В современных клиентах и серверах, на современных операционных системах этой проблемы больше нет.
Диапазоны/возобновление скачивания
FTP поддерживает скачивание и закачку, а также восстановление разорванных соединений и продолжение передачи в обеих направлениях. HTTP может похвастаться только восстановлением при скачивании, а при заливке файлов на сервер восстановление оборванного соединения и продолжение заливки часто оказываются невозможными.
В противовес FTP, HTTP поддерживает более продвинутые диапазоны для скачивания.
Также у FTP есть проблемы при возобновлении соединений при заливке или скачивании файлов, начиная с сегмента, большего, чем 2 GB.
Постоянные соединения
HTTP клиент может держать одно постоянное соединение с сервером для любого количества передач файлов.
FTP должен создавать новое соединение для каждой новой передачи. Многократные выполнения новых подключений плохо сказываются на производительности из-за необходимости «рукопожатий» (handshakes) для TCP соединений.
Кодирование HTTP-чанков
Во избежание закрытия соединения, когда у вас нет возможности сообщить удалённой стороне о том, что передача файла уже завершена, в HTTP было введено так называемое кодирование передаваемых блоков (чанков) с данными.
Во время передачи отправляющая сторона отдаёт поток данных блоками (размер блока + сами данные) до тех пор, пока они не закончатся, а потом передаёт блок с нулевой длиной, чтобы просигнализировать о конце файла.
Помимо того, что соединение не нужно закрывать и открывать заново для новых файлов, ещё одним очевидным плюсом такой схемы есть возможность обнаружения преждевременных аварийных отключений в процессе передачи.
Сжатие
HTTP предоставляет серверу и клиенту возможность договориться и выбрать один из алгоритмов сжатия. Алгоритм gzip является, пожалуй, наиболее широко используемым. Есть более современный brotli, но он ещё не полностью поддерживается разными серверами и клиентами, хотя даёт лучшее сжатие (до +20%), особенно на текстовых html, javascript и css файлах.
FTP предоставляет официальное встроенное RLE сжатие, однако оно обычно неэффективно для большинства бинарных и текстовых данных. Есть много дополнительных «хакерских» реализаций для сжатия FTP трафика, но ни одна из них не стала официальной и широко используемой.
FTP поддерживает технологию для передачи данных с одного сервера на другой, как будто бы передачу ведет непосредственно сам клиент. Однако на большинстве серверов эта возможность закрыта из-за проблем с безопасностью, так как протокол FXP был недостаточно хорошо спроектирован.
И HTTP, и FTP отлично работают с IPv6, однако изначально в оригинальной спецификации протокола FTP не было поддержки IPv6, и из-за этого множество серверов до сих пор не имеют нужных команд для его включения. Это также касается межсетевых экранов между клиентами и серверами, которые должны понимать FTP.
Виртуальный хостинг на основе имени
Используя HTTP 1.1, вы легко можете разместить множество сайтов на одном сервере, и все они будут различаться по их именам.
В FTP вы вообще не можете использовать виртуальный хостинг на основе имён, пока команда HOST не будет реализована на сервере, с которым вы соединены. Это свежая спецификация, и она ещё мало распространена.
Просмотр каталогов
В FTP можно получить список файлов из папки на удалённом сервере, не скачивая их, в то время как в HTTP нет такой возможности.
Однако, в силу того, что авторы спецификации FTP жили в разное время, команды для получения списка файлов в каталоге (LIST и NLST) не имеют чётко описанного формата вывода. Поэтому авторам FTP клиентов приходится заниматься написание синтаксических анализаторов текста, чтобы попытаться правильно угадать, что за данные им передаёт сервер. Более поздние спецификации (RFC3659) предусматривают новые команды типа MLSD, но они ещё не получили широкого распространения и плохо поддерживаются разными серверами и клиентами.
Списки файлов в каталогах через HTTP обычно передаются текстом в HTML формате, либо с помощью WebDAV, который работает поверх HTTP.
Поддержка прокси
Одно из серьёзных преимуществ HTTP перед FTP — это поддержка прокси, встроенная в него с самого начала. Технология отлажена и очень хорошо работает. Многие протоколы могут быть инкапсулированы внутрь HTTP, как в своеобразный «конверт» для прохождения прокси-серверов.
FTP всегда использовался с прокси серверами, но это никогда не было стандартизировано, и всегда требовало специальных подходов в каждом конкретном случае.
Протокол FTP (SFTP, FTPS) — что это такое, соединение между клиентом и сервером по ФТП
Здравствуйте, уважаемые читатели блога Goldbusinessnet.com. Очередным шагом на пути познания механизма передачи информации в интернете станет изучение FTP, посредством которого можно в том числе работать с любыми файлами на удаленном сервере.
Как и в случае с HTTP (о всех нюансах которого я сообщал тут), базовой составляющей действия этого протокола является взаимодействие «клиент-сервер», подробности которого мы непременно разберем в данной публикации.
Перед нами не стоит цель с головой окунуться в дебри и по косточкам разобрать абсолютно все разделы этой темы, но вот знание основ работы ФТП и его безопасных вариантов SFTP, FTPS, а также туннелирования посредством SSH-соединения может оказать вам практическую пользу в дальнейшем. В процессе повествования я постараюсь избежать ненужных заумных выражений и объяснить все простыми и понятными словами.
Что такое FTP и в чем его отличие от HTTP
Итак, аббревиатура FTP означает «File Transfer Protocol» и переводится с английского на русский как «протокол передачи файлов». Как и HTTP, файловая передача основывается на модели, состоящей из совокупности протоколов TCP/IP (Transmission Control Protocol/Internet Protocol), на которой и базируется современный интернет.
Если HTTP, который также является протоколом, был изначально предусмотрен создателями для осуществления передачи гипертекста (что это такое?) и небольших текстовых файликов, то ФТП служит для «транспортировки» практически любых файлов.
Вообще, чтобы получше понять суть сегодняшней темы и осмыслить те нюансы, которые будут разобраны нами далее, лучше сразу обратить внимание на основные отличия между FTP и HTTP, выделенные в ниже следующей табличке:
ФТП-соединение по умолчанию происходит через port 21, если не установлен другой порт. Важно также отметить, что этот протокол снабжен двоичным (бинарным) режимом передачи, что экономит трафик и сокращает время обмена данными при передачи больших файлов.
Взаимодействие между Клиентом и Сервером по ФТП
Перед тем, как продолжить, необходимо определиться с еще некоторыми терминами, которые будут совсем не лишними для восприятия картины в целом.
FTP server — это сервер, который предусматривает возможность использования протокола передачи файлов. Он обладает определенными особенностями, отличающими его от обычных вэбсерверов, а именно теми, которые в основном также присущи одноименному протоколу и представлены в табличке выше:
Ярким примером ФТП-сервера может служить server хостинга (что означает этот термин), на котором «живет» сайт. Эта информация для вебмастеров не является тайной за семью печатями, но вот тем, кто только планирует заняться сайтостроением, будет как раз к месту.
FTP client — это программа, позволяющая подключиться к удаленному серверу по ФТП и также выполнять на нем необходимые действия с элементами файловой системы. К слову, клиентом вполне может быть браузер, в адресную строку которого следует ввести урл, представляющий собой путь (c протоколом FTP) до определенного каталога или файла на удаленном сервере, в соответствии с общей блок-схемой URL:
Или применить более сложный вариант, ежели используется порт, отличный от 21:
Однако же, использование веб-обозревателя в таком разрезе позволит лишь просмотреть или скачать интересующие файлы. Для того, чтобы в полной мере задействовать все плюсы FTP, в качестве клиента следует применить специализированный софт наподобие Файлзиллы (в этом мануале даны все нужные инструкции по установке, настройке и работе с данной программой):
Чтобы подключиться через уже настроенный клиент FileZilla к удаленному серверу, необходимо ввести название хоста, в качестве которого используется IP-адрес сайта, соответствующий его домену (что такое доменное имя и как его приобрести), имя пользователя, пароль и порт.
Кстати, в статье о Файлзилле дана не только стандартная информация, но и практические советы по устранению ее уязвимости в плане безопасности (несмотря на кучу плюсов, проблемы такого рода у ней есть, впрочем, как и у других программ подобного профиля), поэтому настоятельно рекомендую прочитать этот материал, перейдя по чуть выше предоставленной ссылке.
Но продолжим. Схематически взаимодействие «клиент-сервер» при ФТП-соединении можно наглядно представить следующим образом:
Если расписать этот процесс по пунктам, то получится примерно следующее:
Если пользователь является администратором сайта, который расположен на удаленном сервере, то после аутентификации и подключения он в силах совершать любые возможные действия.
Однако, в интернете довольно много бесплатных ФТП-серверов, по сути являющихся библиотеками разного рода файлов, которые предназначены для хранения и скачивания текстовых документов, музыки, фото, видео, дистрибутивов программ и т.п.
В этом случае зарегистрированный пользователь после авторизации имеет весьма ограниченный доступ к определенным каталогам и может осуществлять только лишь некоторые установленные операции с их содержимым (скажем, просматривать и скачивать файлики).
Кроме стандартного соединения с сервером, предусматривающего ввод данных аутентификации, существует понятие анонимного FTP, когда любой пользователь может подключиться к серверу без предоставления персональных данных. Если при этом использовать браузер в качестве клиента, то адрес доступа к файлу может быть упрощен и представлен так:
На практике при анонимном ФТП обычно в качестве логина для доступа применяется известное в сети слово «anonymous», а в качестве пароля — адрес электронной почты, который, впрочем, в большинстве случаев не проверяется.
Безопасный ФТП (SFTP, FTPS и с использованием SSH)
Этот протокол изначально не задумывался как защищенный, так ка разрабатывался в далеком 1971 году и использовался поначалу лишь в научно-исследовательской сети APRANET, доступ в которую имели только несколько военных объектов и университетов.
Но с развитием Мировой Паутины ее частью стал помянутый APRANET, а, следовательно, и технология FTP перекочевала туда же, поскольку обладала многими преимуществами. Однако, одновременно на несколько порядков возросла опасность несанкционированного доступа.
Поэтому возникла насущная необходимость защиты серверов от различного рода атак. Обычный ФТП не обладает возможностью передачи данных в зашифрованном виде, вследствие чего имена пользователей, пароли, команды и другая информация могут при желании легко и просто быть перехвачены злоумышленниками.
По этой причине были разработаны несколько методов, позволяющих зашифровать передаваемую посредством ФТП информацию. Вкупе все эти способы получили обобщающее и емкое название «Безопасный FTP». Вот какие разновидности протокола соответствуют этому термину:
1. FTPS (FTP + SSL) — фактически это расширение стандартного протокола передачи файлов, которое обеспечено криптографическим протоколом SSL (Secure Sockets Layer — уровень защищенных сокетов). На сегодняшний день более передовым его аналогом является TLS (Transport Layer Security — защита транспортного уровня). При этом есть два метода предоставления безопасности:
1.1. Неявный является устаревшим и использует стандартный протокол, требующий применения SSL или TLS, которые могут обеспечить шифрование информации. При таком методе обязательно нужно использовать порты, отличные от обычных, что создает неудобства, поскольку нарушается совместимость клиентов и серверов, не поддерживающих FTPS.
1.2. Явный — намного более удобный, так как применяет команды стандартного протокола FTP, но при отправке ответа зашифровывает информацию, что позволяет сохранить совместимость, поскольку в этом случае применяются одни и те же порты как для FTPS, так и для FTP. При этом для шифрования данных клиентом отправляется команда «AUTH TLS» или «AUTH SSL».
2. SFTP (SSH FTP) — протокол прикладного уровня для передачи файлов, который работает поверх безопасного канала, его не следует путать с «Simple File Transfer Protocol», имеющего такую же аббревиатуру. Если FTPS является просто расширением FTP, то SFTP это отдельный и никак не связанный с ФТП протокол, который снабжен SSH (Secure Shell — безопасная оболочка).
Главное, в чем заключается его отличие от стандартного ФТП и ФТПС, это то, что СФТП шифрует абсолютно все команды, имена пользователей, пароли и другую конфиденциальную информацию. Так как это совершенно другая конфигурация, клиенты FTP (FTPS) не могут соединиться с SFTP-сервером.
3. FTP через SSH — производит обычную FTP-сессию через SSH-туннель, то есть этот вариант нельзя путать с SFTP, который является отдельным независимым протоколом. Этот метод нельзя назвать стопроцентно безопасным. Почему?
Дело в том, что если несколько SSH-клиентов устанавливают туннель для управляющего канала, который изначально осуществляется через 21 порт (а такая ситуация практически всегда и наблюдается), то защищенным окажется именно этот канал. При передаче же данных клиентское программное обеспечение откроет новые TCP-соединения, которые будут находиться уже вне воздействия защитной оболочки SSH.
Надеюсь, вы не запутались во всех этих вариантах безопасных протоколов. Для того, чтобы как-то облегчить понимание, позволю себе сделать краткое резюме. Объективно обеспечивающим самую высокую степень защиты является SFTP. Немного уступает ему в надежности явный FTPS, однако он более удобен, поскольку дает возможность пользоваться обычными портами. Какой из них выбрать, зависит от вида задачи, которая перед вами стоит и, конечно, настроек сервера.
