Протокол передачи файлов (FTP) причислен к стандарту RFC 959, принятому в октябре 1985 года.

Целью данной спецификации является удовлетворение различных нужд пользователей макси-хостов, мини-хостов, персональных терминалов, а также КДТ (в оригинале TACs - прим. ред.) с помощью простого и легкого в исполнении протокола.

Это взято из Вступления. Кто-нибудь знает, что за КДТ (TAC)? Я нет. Пришлось поискать, так как даже RFC не расшифровывает этот акроним. Лишь с третьего запроса в Google я наконец-то нашёл какой-то странный мануал Cisco IOS, где было написано, что это протокол Контроля Доступа Терминалов к сети (Terminal Access Control protocol). Что бы это ни значило.

Почти. На этом сайте указывается:

Лишь только "КДТ" может использоваться для определения BBN

Контроллер Доступа Терминалов к сети... Ну и что за BBN? Bolt Beranek and Newman? (BBN обычно означает Bulletin Board Network/электронная доска объявлений).

Это и будет являться Контроллером Доступа Терминалов к сети, частью аппаратного обеспечения, сконструированного Bolt Beranek and Newman (сейчас именуемые BBN), которая подсоединяет простые терминалы к сети ARPANET-сети управления перспективных исследовательских программ.

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

Но было бы скучно и глупо разглагольствовать лишь о возрасте протокола - в конце концов, я его старше (хоть и не намного, если брать 1971 год за отправную точку).

Нет, у меня есть более серьёзные причины для унижения FTP.

1. Да, давайте искажать исходную информацию!

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

3.1.1.1. Код ASCII

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

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

Нет никакого разумного оправдания для передачи всех файлов в формате ASCII без учёта их содержимого!

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

2. Клиент должен прислушиваться к соединениям сервера!

Это одно из наиболее удивительных свойств, с которыми мне когда-либо приходилось сталкиваться. Обычно, в модели типа "клиент-сервер", сервер ждёт запросов от клиента. Однако в ФТП не существует чёткого разграничения между клиентом и сервером. Даже в RFC понятие "клиент" не используется. В буквальном смысле. Если вы начнёте искать слово "клиент" в RFC, вы его там не найдёте!

В ФТП не существует чёткого разграничения между клиентом и сервером.

RFC не предоставляет чёткого языка, описывающего данный процесс. Он никогда прямым текстом не скажет "клиент выберет произвольный порт, прослушает его, а затем отошлёт следующие байты серверу, который впоследствии подсоединится к порту клиента". (Очевидно, из-за такого рода доходчивости изложения документ бы не допустили к публикации) Как бы то ни было, таков "активный режим" FTP.

Данный протокол также позволяет клиенту выбрать "пассивный" (PASV) режим, при котором сервер несет ответственность за определение порта и передачу информации клиенту, который затем инициирует второе соединение для собственно передачи файла.

3. Брандмауэр? Что ещё за брандмауэр?

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

Однако в 21-м веке большинство конечных пользовательских машин используют немаршрутизируемые IPv4 адреса, и не только из-за широкого распространения брандмауэров, но и из-за простой нехватки IPv4 адресов в большинстве стран мира за пределами США.

Что случается, когда IP адрес клиента немаршрутизированный? В случае с моим собственным Debian, мой IP адрес 192.168.2.5. Это не настоящий Интернет-адрес - это один из зарегистрированных личных IP адресов, и я подключаюсь к Интернету через NAT-шлюз, который также служит в качестве брандмауэра.

Если же я буду использовать активный режим FTP для подключения своего компьютера к Интернет-хосту через простой протокол NAT, а затем попытаюсь передать файл, то таким образом я говорю FTP-серверу подключить меня к IP-адресу 192.168.2.5 порт X,Y. Так не пойдёт!

Следовательно, хорошо, что мы используем пассивный режим, правда? Клиент с NAT-протоколом может сообщить серверу, чтобы тот выбрал любой порт, прослушал его и сообщил о нём клиенту. Затем клиент может сделать повторное подключение, которое NAT выполнит должным образом.

Вот так. Только если на сервере тоже не стоит брандмауэр.

4. Вы тоже используете брандмауэр? Вот чёрт!

Сейчас очень редко можно столкнуться с ситуацией, когда сервер подключён к Интернету без какого-либо брандмауэра. Во многих случаях данным брандмауэром может служить NAT-шлюз. FTP-сервер может иметь протокол NAT, а стандартные протоколы FTP и порты данных (21 и 20 порты TCP) будут направляться (перенаправляться) брандмауэром на FTP-сервер.

Когда FTP-клиент с активным режимом соединяется с сервером, использующим протокол NAT, всё работает как надо. Клиент выбирает случайный порт, прослушивает его и говорит серверу "подсоедини меня к IP адресу 200,201,202,203 порт/PORT 204,205". Сервер может это сделать; NAT хорошо с этим справляется.

Но если к серверу с протоколом NAT подсоединяется FTP-клиент в пассивном режиме, возникают проблемы! Сервер выбирает случайный порт и говорит клиенту "подсоедини меня к IP-адресу 10,11,12,13 порт 14,15". Но, увы, IP адрес сервера немаршрутизируемый! Клиент не может соединиться с данным IP-адресом.

Очевидно, если и клиент, и сервер используют NAT-протокол, они не смогут установить FTP-соединение друг с другом, независимо от того, в каком режиме они работают (активный либо пассивный). И ни один из них работать не будет!

Если и клиент, и сервер используют NAT-протокол, они не смогут установить FTP-соединение друг с другом.

5. Какой у тебя пароль? xyzzy? Замечательно!

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

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

Ваше имя пользователя и пароль передаются в незашифрованном виде FTP-серверу от FTP-клиента.

Значит, можно провести SSL-сессию втайне, да? Можно просто использовать stunnel для зашифровки всей информации, верно? Что ж, наполовину это так. Помните, что FTP не просто использует единичное соединение клиента с сервером и передаёт информацию в сжатом виде через этот открытый канал. Он открывает новый канал для каждой единичной передачи данных, даже для перечня файлов каталога. Так что если во время передачи управляющее FTP-соединение может работать, и может защитить имя пользователя и пароль от посторонних глаз, информационное соединение всё равно будет незащищённым.

Установка SSL-канала потребовала бы специальных мер как от клиента, так и от сервера. Это был бы полуфункционирующий, созданный из того, что было, способ, намного уступающий методам передачи данных, которые были разработаны в течение двух десятилетий после публикации спецификации FTP.

Если же защита личных данных хоть чуть-чуть вас волнует, то для передачи файлов вы будете пользоваться SCP, а не FTP.

6. Как же мне нравится ждать завершения 10 операций для того, чтобы получить всего один файл!

Для получения одного файла, FTP сервер совершает несчётное количество двухсторонних действий с подтверждением.

1. Клиент создаёт TCP сокет-соединение к контрольному порту FTP-сервера и ждёт TCP-подтверждения.
2. Клиент ожидает отсылки сервером "баннера".
3. Клиент посылает серверу имя пользователя и ждёт его ответа.
4. Клиент посылает серверу пароль и ждёт его ответа.
5. Клиент посылает серверу команду SYST и ждёт его ответа.
6. Клиент посылает серверу команду TYPE I и ждёт его ответа (Это может осуществляться позже, но это должно быть сделано.)
7. Если пользователю нужно изменить директории на сервере, клиент посылает ещё одну команду серверу и ждёт его ответа.
8. (В активном режиме) Клиент посылает серверу команду PORT и ждёт его ответа. В пассивном режиме это будет происходить в обратном направлении, однако это всё ещё один круг.
9. Устанавливается соединение для передачи данных (совершенно новое TCP сокет-соединение с тремя полными двухсторонними подтверждениями).
10. По информационному соединению передаются байты информации.
11. Клиент ждёт отсылки сервером 2хх сообщения через управляющее соединение для подтверждения успешного завершения передачи.
12. Клиент посылает серверу команду QUIT и ждёт завершения работы сервера.

Это десять полных двухсторонних процессов для передачи одного файла, и это если считать TCP сокет-соединения за один процесс! (На деле они намного запутаннее.)

А теперь давайте посмотрим, как это будет выглядеть в случае с HTTP:

1. HTTP клиент устанавливает TCP сокет-соединение с HTTP-сервером.
2. HTTP-клиент отсылает HTTP-серверу команду GET, включая URL, версию HTTP-протокола, виртуальное имя хоста, а также различные дополнительные данные, все сразу, и ждёт ответа от сервера.
3. Третьего шага нету. Ответ, который мы получили, содержит в себе целый поток данных. Дело сделано!

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

При передаче файла HTTP в пять раз эффективнее, чем FTP.

7. В заключение

FTP является устаревшим, незащищённым, медленным и недружелюбным подобием протокола. Ему нет места в Интернете 21 века.

FTP ДОЛЖЕН УМЕРЕТЬ!

GreyCat