Confronto tra HTTP e FTP per il trasferimento di file

Question

Quali sono i vantaggi (o le limitazioni) di uno rispetto all'altro per il trasferimento di file su Internet?

(io sono a conoscenza di forme sicure di entrambi i protocolli. Mi piacerebbe sentire il confronto attraverso esperienze personali in termini di prestazioni, affidabilità, limiti di dimensione del file, ecc)

Answer 1

Ecco un performance comparison dei due. HTTP è più reattivo per la richiesta-risposta di file piccoli, ma FTP può essere migliore per i file di grandi dimensioni se ottimizzato correttamente. FTP era generalmente considerato più veloce. FTP richiede un canale di controllo e lo stato deve essere mantenuto oltre allo stato TCP, ma HTTP non lo fa. Ci sono 6 trasferimenti di pacchetti prima che i dati inizino il trasferimento in FTP ma solo 4 in HTTP.

Penso che uno strato TCP correttamente regolato avrebbe un maggiore effetto sulla velocità rispetto alla differenza tra i protocolli del livello dell'applicazione. The Sun Blueprint Understanding Tuning TCP ha dettagli.

Ecco un'altra good comparison delle singole caratteristiche di ciascun protocollo.

Answer 2

Una considerazione è che FTP può utilizzare porte non standard, che possono rendere difficile ottenere i firewall (specialmente se si utilizza SSL). HTTP è in genere su una porta conosciuta, quindi raramente è un problema.

Se si decide di utilizzare FTP, assicurarsi di leggere su Active and Passive FTP.

In termini di prestazioni, alla fine della giornata stanno entrambi spargendo file direttamente su connessioni TCP, quindi dovrebbero essere pressappoco uguali.

Answer 3

Molti firewall rilasciano le connessioni in uscita che non sono alle porte 80 o 443 (http: & https); alcuni addirittura abbandonano le connessioni a quelle porte che non sono HTTP (S). FTP può o non può essere consentito, per non parlare delle modalità attive/PASV.

Inoltre, HTTP/1.1 consente richieste parziali molto migliori ("invia solo dal byte 123456 alla fine del file"), richieste condizionali e memorizzazione nella cache ("invia solo se il contenuto è cambiato/se la data dell'ultima modifica è cambiata") e compressione del contenuto (gzip).

HTTP è molto più facile da utilizzare tramite un proxy.

Dalla mia prova aneddotica, HTTP è più facile da eseguire con connessioni cadute/lente/instabili; per esempio. non è necessario (ri) stabilire una sessione di accesso prima di (ri) avviare il trasferimento.

OTOH, HTTP è senza stato, quindi devi eseguire l'autenticazione e creare una traccia di "chi ha fatto cosa quando" te stesso.

L'unica differenza di velocità che ho notato è il trasferimento di molti file di piccole dimensioni: HTTP con pipelining è più veloce (riduce i round-trip, specialmente quelli su reti a latenza elevata).

Si noti che HTTP/2 offre ancora più ottimizzazioni, mentre il protocollo FTP non ha visto alcun aggiornamento per decenni (e anche le estensioni per FTP hanno un assorbimento insignificante da parte degli utenti). Quindi, a meno che non si stiano trasferendo file attraverso una macchina del tempo, HTTP sembra aver vinto.

(tangenziali: ci sono protocolli che sono più adatti per il trasferimento di file, come ad esempio rsync o BitTorrent, ma quelli non hanno tanto Mindshare, mentre HTTP è ovunque ™)

Answer 4

Ciascuno di essi utilizza TCP come un protocollo di trasporto, ma HTTP usa una connessione persistente, che migliora le prestazioni del TCP.

Answer 5

Ho appena benchmark un trasferimento di file sia su FTP e HTTP:

• più di due connessioni al server ottime
• che utilizzano lo stesso 1GB file .zip
• nelle stesse condizioni di rete (testati uno dopo l'altro)

il risultato:

• tramite FTP: 6 minuti
• utilizzando il protocollo HTTP: 4 minuti
• usando un software concorrente http downloader (fdm): 1 minuto

Quindi, fondamentalmente in una situazione di "vita reale":

1) HTTP è più veloce di FTP quando si scarica un file di grandi dimensioni.

2) HTTP può utilizzare il download di blocchi paralleli che lo rende 6 volte più veloce dell'FTP a seconda delle condizioni della rete.