Ну давай по существу. Проблемы в FTP глубоко исторические и отрицать их бессмысленно.Во-первых: Этот протокол не подходит для использования в современном интернете
Ну то есть он работает, но весьма посредственно. Возможно в 70-е, когда IP адресов хватало всем, файлы и скорости были маленькими, оно считалось нормальным. Сейчас нет.
С тех пор, например, была похоронена модель OSI. Её не существует в современном интернете. Все эти разделения на уровни остались только как жаргон, в реальности у нас "коммутаторы" в датацентрах строят L3 сеть по BGP, чтобы передать там тунели VXLAN и генерирувуют мосты с физическими портами, собирать VRF, причем всё это динамически. Про файрволы и NAT думаю рассказывать не надо. Его пассивный режим, который позволяет пройти через файрвол на самом деле рушит основную логику FTP, о том что на запрос в Control Plane вы получаете входящий коннект в Data Plane с передачей файла.
Во-вторых: он рассчитан на использование в рамках суперсервера Internet Daemon, который по-факту мёртв (если не считать Microsoft IIS)
Изначальная идея в том, что ядро ОС приняв запрос на порт 21 должно передать его на FTP-демон или драйвер, обслуживающий протокол FTP в ядре. В Microsoft попытались реализовать это, был провал. Переписали на юзерспейсную реализацию в IIS 7.5 и вот оно как-то живет. Полноценной и быстрой реализации в FTP поверх inetd я не видел. Наоборот, все пихают его как самодостаточный демон или приложение, обслуживающий сам себя. То есть с точки зрения архитектуры написания приложения "широкополосность" с разделением data plane от control plane для оптимизации производительности не используется.
В-третьих: он использует сессии для передачи файлов и с точки зрения HA/LB - это жесть.
Ну то есть, попробуйте мне сделать отказоустойчивый FTP сервер с балансировкой нагрузки, как раз по корпоративному принципу. Его "балансировщик" будет работать примерно также как SIP B2BUA и напоминать будет SIP Proxy. Кстати, архитектура у них примерно одинаковая.
Для банальной отказоустойчивой передачи файлов в протоколе FTP вам нужно слишком много.
HTTP-way
1. Создать сессию и тем самым вы привязаны к конкретному серверу целиком по вашему source.
2. Вам нужнен отдельный мониторинг, чтобы понять загруженность. Просто так раскидать коннекты по количеству не дадут вам балансировку по пропускной способности.
SIP-way
1. Вам нужно написать отдельный отказоустойчивый сервис для работы с Control Plane, который будет выполнять роль диспетчера-координатора по файловым серверам
2. Отдельно написать реализацию FTP, которая понимает такую координацию
В первом случае не понятно, почему бы просто не использовать HTTP, а во втором случае в самом протоколе FTP не предусмотрена Back To Back логика с терминированием сессий, как в SIP.
Да, существуют FTP reverse proxy решения. Но это ALG, а не решение для отказоусточивости и балансировки. Я уже не говорю про то какой же они мусор.
В-четвёртых: безопасность
FTP повторил историю с SMTP, у обоих мертвы неявные реализации поверх TLS, а явные (современный FTPS и ESMTP) используют команду для апгрейда сессии из незащищенной в защищенную. Справедливости ради SMTPS остался как Submission-вариант на 465-ом порту, но для основного потока обмена почтой он не используется. Равно как и старые порты 989-990 существуют и если клиент реализует FTP таким способом, то никто вам не запретит.
Проблема в том, что как и в случае с ESMTP вам любой DPI вырежет эту команду из потока. В случае же продолжения использования FTPS через неявные порты 989/990 вы еще больше усложняете задачу балансировки нагрузки и отказоустойчивости. SIPS таких проблем не имеет, потому что понимает на уровне топологии понимает, что такое B2BUA или как его называет молодежь (Session Border Controller).
Просто научитесь пользоваться протоколом WebDAV
1. Он проходит файрволы и NATбез всяких ухищрений с Application Level Gateway на роутере.
2. Он быстрее работает, если у вас большой объем маленьких файлов на передачу. Вместо того чтобы создавать по новому соединению на каждый файл WebDAV пропустит их через одно соединение.
3. У вас есть стандартизированная поддержка компрессии на лету во всех клиентах, по стандарту её нету
4. У вас есть возможность вынести аутентификацию на отдельный сервис OAuth2/SAML2 или использовать Kerberos в отличии от единственно возможного варианта в FTP, который аналогичен HTTP Basic с передачей логина и пароля по сети в потенциально незащищенной сессии, потому что TLS там не обязателен
5. WebDAV поддерживает частичную догрузку измененных данных в файле. В FTP вы вынуждены перепослать весь файл целиком, если его кусочек изменился
6. Оно работает через обычные реверс-прокси сервера и вы можете как угодно его балансировать и делать отказоустойчивым
7. Его проще админить чем FTP.
