FTP vs trasferimento web: perché il browser vince nel 2026

Il trasferimento web via browser ha superato FTP per praticamente ogni flusso di lavoro non legacy. FTP, definito dall'RFC 959 (1985), invia credenziali e contenuti dei file in chiaro attraverso la porta TCP 21 di default. Il trasferimento web moderno gira su HTTPS con TLS 1.3, cripta i payload lato client con AES-256-GCM e non richiede al destinatario alcun setup oltre a un browser. Il contatore di installazioni di FileZilla continua a salire, ma le nuove implementazioni aziendali di FTP in chiaro sono praticamente scomparse. SFTP e FTPS sopravvivono per l'automazione server-to-server; i trasferimenti interattivi tra persone sono passati al web.

Per cosa era stato progettato FTP

FTP presupponeva una rete fidata. La specifica RFC 959 dell'aprile 1985 precede Internet commerciale — NSFNET non è diventato pubblico fino al 1988. La porta 21 trasportava il canale di comando, la porta 20 i dati, e tutto fluiva in modalità ASCII o binaria senza alcuna protezione crittografica. Il NAT traversal era un ripensamento che ha reso necessaria la "modalità passiva" un decennio dopo.

L'età del protocollo si vede nelle sue stranezze. Confusione tra modalità attiva e passiva, connessioni separate per controllo e dati che i firewall odiano, nome utente e password inviati come stringhe in chiaro e nessun controllo di integrità nativo. Un singolo trasferimento attraverso un router malfunzionante può corrompere silenziosamente un archivio .zip senza che emerga alcun errore.

Perché FTP in chiaro è di fatto obsoleto

I browser hanno abbandonato il supporto FTP a ondate. Chrome lo ha rimosso nella versione 95 (ottobre 2021). Firefox lo ha eliminato nella versione 90 (luglio 2021). Safari non lo ha mai supportato davvero in modo interattivo. Questo significa che un link come ftp://files.example.com/report.zip non funziona più per la maggior parte degli utenti — dovrebbero installare FileZilla, Cyberduck o WinSCP solo per recuperare un singolo file.

I framework di conformità hanno completato il lavoro. La sezione 4.2.1 di PCI DSS 4.0 richiede crittografia forte per qualsiasi trasmissione di dati di titolari di carta su reti pubbliche. Le Technical Safeguards di HIPAA 45 CFR 164.312(e)(1) impongono la trasmissione crittografata per le ePHI. FTP in chiaro fallisce in entrambi i casi. Gli auditor lo segnalano immediatamente.

SFTP e FTPS non sono la stessa cosa

Si confondono continuamente. SFTP (SSH File Transfer Protocol) gira su SSH alla porta 22, usa l'autenticazione SSH e non ha alcuna relazione di protocollo con FTP nonostante il nome. FTPS è FTP avvolto in TLS sulla porta 990 (implicita) o sulla porta 21 con AUTH TLS (esplicita). Sono bestie diverse con modalità di fallimento diverse.

SFTP è la scelta migliore per i trasferimenti automatizzati server-to-server — ha una sola connessione, va d'accordo con i firewall e si integra con la gestione delle chiavi SSH che i team già usano per l'infrastruttura. FTPS aggiunge TLS a un protocollo ancora maledetto da due connessioni e complicazioni NAT.

Cosa sostituisce il trasferimento web

Un moderno servizio di trasferimento web gestisce i casi d'uso che FTP ha storicamente coperto:

• Consegne occasionali di file ai clienti (prima un account FTP condiviso)
• Drop di file da fornitori (prima un FTP anonimo con una cartella in ingresso in sola scrittura)
• Scambio di file grandi tra aziende partner (prima una VPN più FTP)
• Distribuzione di software agli utenti finali (prima un mirror FTP pubblico)

La differenza: nessun provisioning di account, nessuna regola firewall, nessuna installazione di software client e crittografia end-to-end di default.

Confronto architetturale

| Dimensione | FTP (in chiaro) | FTPS | SFTP | Trasferimento web | |---|---|---|---|---| | Porte | 21, 20 | 990 o 21 | 22 | 443 | | Crittografia | Nessuna | TLS | SSH | TLS 1.3 + AES-256-GCM lato client | | Client necessario | FileZilla/WinSCP | FileZilla/WinSCP | OpenSSH/WinSCP | Solo browser | | Compatibilità firewall | Scarsa (doppio canale) | Scarsa | Buona | Buona | | Supporto ripresa | Variabile | Variabile | Sì | Sì (tus/chunked) | | Modello auth | Utente/password | Utente/password + cert | Chiavi SSH | Link + password opzionale | | Miglior uso nel 2026 | Deprecato | Integrazioni legacy | Automazione server | Condivisione file tra persone |

La storia della latenza che quasi tutti ignorano

FTP apre una connessione TCP per file nei download in alcuni client. Trasferire 10.000 file piccoli via FTP significa 10.000 handshake TCP. Ecco perché il backup di un repository .git su FTP va a rilento mentre gli stessi dati su HTTP/2 multiplexato finiscono in una frazione del tempo.

HTTPS con HTTP/2 o HTTP/3 (QUIC) multipla molte richieste di file su una singola connessione, abbattendo l'overhead di round-trip. I servizi di trasferimento web che usano upload a chunk con protocolli come tus.io riprendono esattamente dal punto in cui la connessione è caduta, cosa che FTP in chiaro gestisce in modo incoerente tra i vari server.

Dove FTP sopravvive ostinatamente

I sistemi di automazione broadcast spingono ancora contenuti alle stazioni affiliate via FTP perché i playout box di fornitori come Grass Valley o Ross Video sono stati progettati nell'era FTP. I sistemi retail legacy inviano dump .csv notturni dell'inventario alla sede centrale via FTPS. Le istituzioni accademiche gestiscono mirror FTP anonimi per gli archivi software (anche se la maggior parte è migrata a equivalenti basati su HTTPS).

L'automazione server-to-server beneficia specificamente di SFTP. Un job schedulato che deposita backup notturni in una jail SFTP rafforzata con autenticazione a chiave SSH è ancora una buona architettura nel 2026. È l'FTP mediato dall'uomo che sta morendo.

Quando il trasferimento web vince chiaramente

Qualsiasi cosa coinvolga un destinatario non tecnico. I clienti non installeranno FileZilla. Gli auditor esterni non configureranno impostazioni FTPS. I regolatori vogliono ricevute e consegna basata su link. Per un'agenzia PR che invia kit stampa, uno studio legale che scambia discovery o uno studio di design che spedisce file .psd a un cliente, un link nel browser è l'unico metodo di consegna che funziona senza un ticket al supporto IT.

HexaTransfer rappresenta questo cambiamento — carica un file fino a 10 GB, condividi il link, il destinatario scarica dal browser. Nessuna credenziale FTP da creare o revocare.

Postura di sicurezza

FTP in chiaro espone le credenziali a qualsiasi osservatore passivo sulla rete — Wi-Fi aeroportuali, reti d'albergo, infrastrutture d'ufficio condivise. FTPS e SFTP sistemano il trasporto ma consegnano comunque all'operatore del server accesso in chiaro ai contenuti dei file una volta decriptati all'endpoint.

Un servizio di trasferimento web con crittografia zero-knowledge cripta lato client prima che il file lasci il browser. Il server memorizza solo cifrato. Anche una violazione completa del server non espone nulla di utile senza le chiavi per-file contenute nei frammenti degli URL. È una postura materialmente più forte di quella che FTPS può offrire.

Percorso di migrazione

Se stai ancora usando FTP per la consegna di file esterni, la migrazione è di solito semplice. Identifica i flussi (consegne clienti, intake fornitori, scambi partner), scegli un servizio di trasferimento web adatto alle dimensioni e al profilo di conformità, e dismetti il server FTP una volta che il traffico si esaurisce. I job server automatizzati si spostano su SFTP con autenticazione a chiave SSH — quello sopravvive alla transizione.

Verdetto

FTP ha avuto 40 anni di gloria. Ha perso perché lo stack di protocolli web ha risolto ogni problema che FTP risolveva, aggiungendo poi crittografia, compatibilità con i firewall e supporto universale via browser già presenti su ogni dispositivo. Per nuove condivisioni file interattive, usa il web. Per pipeline server automatizzate, usa SFTP. Lascia FTP in chiaro sullo scaffale accanto al fax.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.