Quando è opportuno utilizzare l'FTP?

Question

Nella mia esperienza vedo molti diagrammi di architettura che fanno ampio uso di FTP come mezzo per collegare componenti architettonici.

Come qualcuno che non prende decisioni architettoniche ma tende a guardare i diagrammi dell'architettura, qualcuno potrebbe spiegare qual è il valore dell'uso di FTP, dove è appropriato e quando il trasferimento dei dati come file è una buona idea.

Ottengo che ci sono spesso i sistemi legacy che solo bisogno di lavorare in questo modo - anche se tutta la comprensione storica Sarebbe interessante anche

posso vedere l'attrazione di trasferimento dei file (soprattutto se questo è ciò che deve essere trasferito) a causa della semplicità e familiarità e meraviglia se il ragionamento va oltre.

Modifica: Grazie a coloro che sottolineano che SFTP è preferibile, tuttavia la mia domanda è più ampia di quanto si desideri una raccomandazione per un protocollo di trasferimento file. Dispiace per la confusione.

Answer 1

Quando è opportuno utilizzare l'FTP?

Prima dell'invenzione di SFTP.

---

Affrontare la modifica (aka la questione più ampia in questa domanda)

Tutto si riduce all'uso previsto. Guarda la tua situazione e determina

• Quali dati sono in movimento?
• In che formato è generato in modo nativo? (PDF su disco, output testuale da script webserver, ecc.)
• Come vengono consumati i dati?
• Quando vengono consumati i dati? (Immediatamente all'arrivo, lavori batch pianificati?)
• Quale supporto di connettività collega il generatore di dati e il consumatore di dati?

Ad esempio:

Un processo genera documenti PDF da loro scrivendo a un raid-array locale. Hai un altro PC dedicato alla stampa di tutti i PDF generati da una moltitudine di server connessi a una LAN Gigabit locale tramite un cron job pianificato per essere eseguito a mezzanotte.

Dato che i dati molto probabilmente sono troppo grandi per tutti seduti nella RAM sul server di stampa, ha senso utilizzare SFTP per trasferire i PDF in modo che possano essere afferrati dal disco mentre vengono stampati.

Un altro esempio:

Una macchina ha bisogno di afferrare un gran numero di piccoli file da una macchina in un modo ad hoc, li analizzare e memorizzare i risultati in un database.In questo caso, usare SFTP per spostarli dal disco, tornare su un altro disco per essere immediatamente letti e inseriti in un DB è semplicemente sciocco. Non c'è motivo per cui i file più piccoli non si adattino alla RAM fino a quando non vengono analizzati e inseriti nel database e quindi SFTP probabilmente non è la migliore soluzione.

Answer 2

Immagino che la sicurezza e le reti scollegate o i segmenti di rete possano entrare in gioco. Ho avuto vari progetti in cui qualcuno ha bisogno di importare dati da un sistema diverso, e FTP è un modo facile/sicuro per ottenere i dati attraverso il firewall. In genere è possibile programmarlo per l'esecuzione automatica e la maggior parte degli addetti alla sicurezza di rete funzionerà correttamente con le porte FTP aperte.

Answer 3

Alcuni sistemi di lecacy utilizzano cartelle per trasferire dati come XML o CSV ecc. In questi casi i file devono essere scritti su disco. Se si effettua l'integrazione con un altro sistema al di fuori della rete/su Internet, è opportuno renderli disponibili su un sito FTP. I sistemi più recenti possono utilizzare WebServices o altre tecnologie "over the wire" per ridurre il salvataggio su disco. È possibile che se questi file sono molto grandi, l'FTP potrebbe essere una soluzione migliore.

In alcuni settori, ad esempio nel settore della stampa, i file PDF di grandi dimensioni sono percorsi attraverso vari flussi di lavoro in cui i file PDF vengono elaborati, manipolati ecc. Attraverso questo flusso di lavoro. Nel settore della stampa, l'uso di cartelle (ea sua volta FTP) è comune e si riferiscono a questi come "Hot-Folders"

Answer 4

FTP è un modo semplice e multipiattaforma per trasferire file se si dispone di una connessione affidabile e non ha assolutamente bisogno di alcuna sicurezza (non fatevi ingannare chiedendovi delle password - non c'è una vera sicurezza lì).

Un sacco di volte, le persone hanno effettivamente bisogno di sicurezza, ma commettono l'errore di usare l'FTP perché credono che sia ciò che è fatto. Il modo migliore per farlo è di solito usare SFTP (mi piace l'implementazione di OpenSSH), o passare i dati usando un servizio web sicuro.

Ovviamente, una corretta implementazione di SFTP significa che gli implementatori dovranno generare, archiviare e scambiare correttamente le proprie chiavi e capire come funziona la fiducia. Spesso questo è troppo sforzo per loro, quindi la gente tenderà a seguire la strada facile e usare FTP. Un po 'triste se me lo chiedi.

Answer 5

Se è necessario inviare una lettera fisica al locale più arretrato, è difficile battere il servizio 2000 year old postal. Se è necessario inviare un file in una posizione di capacità backwater, è difficile battere uno 40 year old Postel service.

Answer 6

Se la sicurezza non è importante, l'FTP può essere utile.

Tuttavia, date le opzioni moderne, probabilmente non lo userei mai, optando invece per SFTP/SCP/rsync o HTTP (eventualmente con WebDAV). Per prima cosa, questi protocolli hanno tutte le opzioni per una migliore sicurezza (HTTP almeno via SSL). Inoltre, sono protocolli più semplici. FTP ha la cattiva idea che i dati effettivi vengano trasferiti su una connessione separata rispetto ai comandi di controllo, il che rende il firewall più difficile. Inoltre, in modalità non passiva, quella connessione è da server a client, rendendo il firewall quasi un incubo. Se esistono esigenze di interoperabilità legacy, potrebbe essere utile, ma le librerie dei programmi client HTTP & sono prontamente disponibili, quindi la userei solo in questi giorni.

Answer 7

comunicazione basata su file (come via FTP, SFTP, SCP ...) è buono per

• trasferire grandi quantità di dati
• scenari operativi lotti
• comunicazione asincrona

Non c'è niente di sbagliato nell'usare i file. È una tecnologia matura ben conosciuta, facile da applicare, facile da monitorare e da eseguire il debug.