Когда хорошо использовать FTP?
По моему опыту, я вижу много схем архитектуры, которые делают широкое применение FTP как носитель для соединения архитектурных компонентов.
Поскольку кто-то, кто не принимает архитектурные решения, но склонен смотреть на схемы архитектуры, мог любой объяснять, что значение имеет использование FTP, где это является соответствующим и при передаче данных, поскольку файлы являются хорошей идеей.
Я получаю это часто существуют унаследованные системы, которые просто должны проложить себе путь - хотя любое историческое понимание было бы интересно также
Я вижу привлекательность в передаче файлов (особенно, если это - то, какие потребности быть переданным), из-за простоты и знакомства и задаются вопросом, идет ли обоснование вне этого.
Править: Благодаря тем, которые указывают, что SFTP предпочтителен, однако, мой вопрос более широк, чем желание рекомендации для протокола передачи файлов. Извините за беспорядок.
7 ответов
Когда лучше использовать FTP?
До изобретения SFTP.
Обращение к редактированию (он же более широкий вопрос в этом вопросе)
Все сводится к предполагаемому использованию. Посмотрите на свою ситуацию и определите
- Какие данные я перемещаю?
- В каком формате они изначально генерируются? (PDF-файлы на диске, текстовый вывод из сценариев веб-сервера и т. Д.)
- Как потребляются данные?
- Когда потребляются данные? (Мгновенно по прибытии, запланированные пакетные задания?)
- Какая среда связи соединяет генератор данных и получатель данных?
Например:
Процесс генерирует документы PDF, записывая их в локальный массив raid. У вас есть другой компьютер, предназначенный для печати всех PDF-файлов, созданных на множестве серверов, подключенных к локальной Gigabit LAN через задание cron, запуск которого запланирован на полночь.
Учитывая, что данные, скорее всего, будут слишком большими, чтобы все они поместились в ОЗУ на сервере печати, имеет смысл использовать SFTP для передачи файлов PDF, чтобы их можно было захватить с диска во время печати.
Другой пример:
Машине необходимо специальным образом захватить большое количество небольших файлов с машины, проанализировать их и сохранить результаты в базе данных. В этом случае использование SFTP для перемещения их с диска обратно на другой диск для немедленного чтения и помещения в базу данных просто глупо. Нет причин, по которым файлы меньшего размера не поместятся в ОЗУ до тех пор, пока они не будут проанализированы и помещены в базу данных, и, следовательно, SFTP, вероятно, не является лучшим решением.
Обмен данными на основе файлов (например, через FTP, SFTP, SCP ...) хорош для
- передачи больших объемов данных
- сценариев пакетных операций
- асинхронного обмена данными
Нет ничего плохого в использовании файлов. Это хорошо изученная зрелая технология, которую легко применять, легко контролировать и отлаживать.
Я полагаю, что безопасность и отключенные сети или сетевые сегменты могут иметь значение. У меня было несколько проектов, в которых кому-то нужно было импортировать данные из другой системы, а FTP - простой / безопасный способ получить данные через брандмауэр. Как правило, вы можете запланировать его автоматический запуск, и большинство специалистов по сетевой безопасности будут в порядке с открытыми портами FTP.
Если вам нужно отправить физическое письмо в самый захолустный населенный орган, трудно превзойти почтовую службу 2000-летней давности. Если вам нужно отправить файл в место захолустья, трудно превзойти 40-летний сервис Postel.
Если безопасность не имеет значения, тогда может быть полезен FTP.
Однако, учитывая современные возможности, я бы, вероятно, никогда не использовал бы его, выбрав вместо него SFTP / SCP / rsync или HTTP (возможно, с WebDAV). Во-первых, у всех этих протоколов есть варианты повышения безопасности (HTTP, по крайней мере, через SSL). Кроме того, это более простые протоколы. У FTP есть неприятная проблема, заключающаяся в том, что фактические данные передаются по отдельному соединению, а не по командам управления, что затрудняет защиту от брандмауэра. Кроме того, в непассивном режиме это соединение осуществляется от сервера к клиенту, что делает брандмауэр почти кошмаром. Если есть устаревшие потребности в взаимодействии, это может быть полезно, но клиентские программы и библиотеки HTTP легко доступны, поэтому я бы просто использовал их в наши дни.
Некоторые системы lecacy используют папки для передачи данных в формате XML или CSV и т. Д., В этих случаях файлы необходимо записывать на диск. При интеграции с другой системой вне сети / в Интернете имеет смысл сделать их доступными на FTP-сайте. Более новые системы могут использовать WebServices или другие "беспроводные" технологии, чтобы сократить время сохранения на диск. Возможно, что если эти файлы очень большие, FTP может быть лучшим решением.
В некоторых отраслях, например, в полиграфической промышленности, большие файлы PDF проходят через различные рабочие процессы, в которых файлы PDF обрабатываются, обрабатываются и т. Д. В рамках этого рабочего процесса. В полиграфической промышленности использование папок (и, в свою очередь, FTP) является обычным явлением, и они обычно называют их «горячими папками»
FTP - это простой, кроссплатформенный способ передачи файлов, если у вас есть надежное соединение и не требуется абсолютно никакой безопасности (не обманывайтесь тем, что он спрашивает вас о паролях - там нет никакой реальной безопасности).
Очень часто людям действительно нужна безопасность, но они совершают ошибку, используя FTP, потому что считают, что так и должно быть. Лучшим способом решения этой проблемы обычно является использование SFTP (мне нравится реализация OpenSSH) или передача данных с помощью безопасного веб-сервиса.
Конечно, правильная реализация SFTP означает, что пользователям придется правильно генерировать, хранить и обмениваться ключами, а также понимать, как работает доверие. Зачастую это требует слишком больших усилий, поэтому люди предпочитают идти простым путем и использовать FTP. Как по мне, это печально.