FTP ed HTTP Le differenze

AkTaRuS
25 Aprile 2021
5 commenti
Internet

FTP ed HTTP i due protocolli a confronto.

Questo è un tentativo di documentare le differenze principali tra FTP ed HTTP, poiché questo argomento è comunemente richiesto ed insieme ad esso, anche molte idee sbagliate (vere e proprie bugie), volano giro. Se trovi errori o hai altre cose da aggiungere, inviami un’e-mail e contattami tramite il modulo in fondo alla pagina.

Entrambi i protocolli vengono utilizzati per upload e download su Internet, per testo e per binario, entrambi su TCP / IP. Ma tra FTP ed HTTP ci sono molte differenze nei dettagli:

Velocità di trasferimento di FTP ed HTTP

Forse è la domanda più comune: quale è più veloce per i trasferimenti?

Dati tutti i dettagli in questa pagina. Cosa rende FTP più veloce:

Nessun metadato aggiunto nei file inviati, solo il binario grezzo
Codifica mai suddivisa in blocchi “overhead”

Cosa rende HTTP più veloce:

Riutilizzare le connessioni persistenti esistenti migliora le prestazioni TCP
il pipelining rende più veloce la richiesta di più file dallo stesso server
La compressione (automatica) fa sì che vengano inviati meno dati
nessun flusso di comando / risposta riduce al minimo i round trip aggiuntivi

Alla fine il risultato netto ovviamente differisce a seconda dei dettagli specifici, ma direi che per i file statici a scatto singolo non sarai in grado di misurare la differenza. Per un singolo file di piccole dimensioni, potresti ottenerlo più velocemente con FTP (a meno che il server non si trovi a una lunga distanza di andata e ritorno). Quando si ottengono più file, HTTP dovrebbe essere il più veloce.

Età

FTP ( RFC959 ) è apparso circa dieci anni prima dell’invenzione di HTTP. All’epoca l’FTP era l’unico protocollo. Le tracce iniziali di quella che è diventata la RFC 959 si possono trovare già nel 1971 .

Caricare

Entrambi i protocolli offrono caricamenti. FTP ha un comando “append“.

Potrebbe valere la pena notare che WebDAV è un protocollo su HTTP che fornisce capacità “simili a file system”

ASCII / binario / EBCDIC

FTP ha una nozione di formato file, quindi può trasferire dati come ASCII o binari (e altro) dove HTTP invia sempre cose binarie. FTP consente quindi anche conversioni di testo quando i file vengono inviati tra sistemi di diverso tipo:

Se la destinazione utilizza uno schema diverso per la codifica dei caratteri di fine riga, ftp lo correggerà per la destinazione. Ad esempio, unix usa solo un carattere NL (newLine x’0A ‘) e MS windows usa CR e LF (Carriage Return e LineFeed x’0D0A’). EBCDIC specifica che deve essere eseguita una traduzione da ASCII a EBCDIC (utilizzato su vecchi mainframe).

HTTP fornisce metadati con file, Content-Type, che i client usano ma FTP non ha nulla di simile. I metadati possono quindi essere utilizzati dai clienti per interpretare i contenuti di conseguenza.

Intestazioni

I trasferimenti con HTTP includono sempre anche una serie di intestazioni che inviano metadati. FTP non invia tali intestazioni. Quando si inviano file di piccole dimensioni, le intestazioni possono essere una parte significativa della quantità di dati effettivi trasferiti. Le intestazioni HTTP contengono informazioni su cose come la data dell’ultima modifica, la codifica dei caratteri, il nome e la versione del server e altro ancora.

Pipelining

HTTP supporta il pipelining. Significa che un client può richiedere il trasferimento successivo già prima che il precedente sia terminato, il che consente quindi di inviare più documenti senza un ritardo di andata e ritorno tra i documenti, e i pacchetti TCP sono quindi ottimizzati per la velocità di trasferimento.

Qualcosa di correlato, sebbene non simile, è il supporto di FTP per la richiesta di più file da trasferire in parallelo utilizzando la stessa connessione di controllo. Ovviamente si utilizzano nuove connessioni TCP per ogni trasferimento in modo da ottenere metriche di prestazioni diverse. Inoltre, questo richiede che il server supporti questo tipo di operazione (cioè accettare nuovi comandi mentre è in corso un trasferimento), cosa che molti server non lo faranno.

Comando / risposta FTP

FTP coinvolge il client che invia i comandi a cui il server risponde. Un singolo trasferimento può coinvolgere una serie di comandi. Questo ovviamente ha un impatto negativo poiché c’è un ritardo di andata e ritorno per ogni comando. I trasferimenti HTTP sono principalmente solo una richiesta e una risposta (per ogni documento). Il recupero di un singolo file FTP può facilmente ottenere fino a 10 round trip.

Due connessioni

Uno dei maggiori ostacoli all’FTP nella vita reale è l’uso di due connessioni. Utilizza una prima connessione primaria per inviare comandi di controllo e quando invia o riceve dati, apre un secondo flusso TCP a tale scopo.

Firewall e NAT

L’utilizzo di due connessioni da parte dell’FTP, dove la seconda utilizza numeri di porta dinamici e può andare in entrambe le direzioni, dà fastidio agli amministratori del firewall ei firewall devono davvero “capire” FTP a livello di protocollo dell’applicazione per funzionare davvero bene.

Ciò significa anche che se entrambe le parti sono dietro NAT , non puoi usare FTP!

Inoltre, poiché i NAT sono spesso impostati per interrompere le connessioni inattive e la natura dell’FTP fa sì che il canale di controllo rimanga silenzioso durante i trasferimenti FTP lunghi e lenti, spesso finiamo con il canale di controllo che viene interrotto dal NAT a causa dell’inattività.

Attivo e passivo

FTP apre la seconda connessione in modalità attiva o passiva, che sostanzialmente dice quale estremità la avvia. È una decisione del cliente provare in entrambi i casi.

Connessioni di controllo crittografate

Poiché i firewall devono comprendere l’FTP per poter aprire le porte per la connessione secondaria, ecc., C’è un grosso problema con l’FTP crittografato (FTP-SSL o FTPS) poiché la connessione di controllo viene inviata crittografata e i firewall non possono interpretare i comandi che si occupano di creare la seconda connessione. Inoltre, lo standard FTPS ha impiegato molto tempo per “raggiungerlo”, quindi esiste una gamma di versioni ibride in circolazione.

Autenticazioni FTP ed HTTP

FTP ed HTTP hanno documentato un diverso insieme di metodi di autenticazione. Sebbene entrambi i protocolli offrano fondamentalmente utente e password di testo normale per impostazione predefinita, ci sono diversi metodi di autenticazione comunemente usati per HTTP che non inviano la password come testo normale, ma non ci sono tante opzioni (non Kerberos) disponibili per FTP .

Download

Entrambi i protocolli offrono supporto per il download. Entrambi i protocolli avevano problemi con file di dimensioni maggiori di 2 GB, ma quelli sono cronologia per i client e i server moderni sui sistemi operativi moderni.

Intervalli / ripresa

I supportI FTP ed HTTP hanno ripreso i trasferimenti in entrambe le direzioni, ma HTTP supporta intervalli di byte più avanzati.

I trasferimenti ripresi per FTP che iniziano oltre la posizione di 2 GB sono noti per causare problemi in passato, ma dovrebbero essere migliori in questi giorni.

Connessioni persistenti

Per la comunicazione HTTP, un client può mantenere una singola connessione a un server e continuare a utilizzarla per qualsiasi quantità di trasferimenti. FTP deve crearne uno nuovo per ogni nuovo trasferimento di dati. L’esecuzione ripetuta di nuove connessioni è dannosa per le prestazioni a causa della necessità di eseguire sempre nuove strette di mano / connessioni e di ripetere il periodo di avvio lento del TCP e altro ancora.

Codifica in blocchi HTTP

Per evitare di dover chiudere la connessione dati per segnalare la fine di un trasferimento – quando la dimensione del trasferimento non era nota quando è iniziato il trasferimento, è stata introdotta la codifica in blocchi in HTTP.

Durante un trasferimento “chunked encoding“, la parte mittente invia un flusso di blocchi [size-of-data] [data] sul cavo fino a quando non ci sono più dati da inviare e quindi invia un blocco di dimensione zero per segnalare la fine di esso.

Un altro ovvio vantaggio (oltre a dover riaprire nuovamente la connessione per il trasferimento successivo) con la codifica a blocchi rispetto alla semplice chiusura della connessione è la capacità di rilevare interruzioni premature della connessione.

Compressione FTPn ed HTTP

HTTP fornisce un modo per il client e il server di negoziare e scegliere tra diversi algoritmi di compressione. L’algoritmo gzip è forse quello più utilizzato, con brotli che è un’aggiunta recente che spesso comprime i dati ancora meglio.

FTP offre una codifica della lunghezza di esecuzione “incorporata” ufficiale che comprime la quantità di dati da inviare, ma non molto sui normali dati binari. Tradizionalmente è stato anche fatto per FTP utilizzando vari approcci “hacker” che non erano mai stati in nessuna specifica FTP.

FXP

FTP supporta “trasferimenti di terze parti”, spesso chiamati “FXP”. Consente a un client di chiedere a un server di inviare dati a un terzo host, un host che non è lo stesso del client. Questo è spesso disabilitato nei moderni server FTP, anche se a causa delle implicazioni sulla sicurezza.

IPv6

HTTP e FTP supportano entrambi bene ipv6, ma le specifiche FTP originali non avevano tale supporto e ancora oggi molti server FTP non supportano i comandi necessari che lo abiliterebbero. Questo vale anche per i firewall intermedi che devono comprendere l’FTP.

Hosting virtuale basato sul nome

Utilizzando HTTP 1.1, puoi facilmente ospitare molti siti sullo stesso server e sono tutti differenziati per i loro nomi.

In FTP, non puoi fare affatto l’hosting virtuale basato sul nome finché il comando HOST non viene implementato nel server con cui parli e nel client ftp che usi … È una specifica recente senza molte implementazioni.

Elenco Dir

Un’area in cui l’FTP si distingue in qualche modo è che è un protocollo che è direttamente a livello di file. Significa che FTP ha ad esempio comandi per elencare i contenuti delle directory del server remoto, mentre HTTP non ha tale concetto.

Tuttavia, gli autori delle specifiche FTP vivevano in un’epoca diversa, quindi i comandi per elencare i contenuti delle directory (LIST e NLST) non hanno un formato di output specificato, quindi è un problema scrivere programmi per analizzare l’output. Le ultime specifiche (RFC3659) hanno affrontato questo problema con nuovi comandi come MLSD, ma non sono ampiamente implementati o supportati né da server né client.

Gli elenchi di directory su HTTP vengono solitamente eseguiti servendo HTML che mostra il contenuto della directory o utilizzando WebDAV, un protocollo aggiuntivo eseguito “su” o in aggiunta a HTTP.

Supporto proxy

Uno dei maggiori punti di forza per HTTP su FTP è il suo supporto per i proxy, già integrato nel protocollo dal primo giorno. Il supporto ha così tanto successo e ben utilizzato che molti altri protocolli possono essere inviati su HTTP in questi giorni solo per il suo capacità di passare attraverso proxy.

FTP è sempre stato utilizzato anche sui proxy, ma non è mai stato standardizzato ed è stato sempre fatto con molti approcci ad-hoc diversi.

FTP ed HTTP e le loro differenze

Ci sono ulteriori differenze, come la capacità HTTP di eseguire richieste condizionali, negoziare la lingua dei contenuti e molto altro, ma queste non sono abbastanza grandi per essere specificate in questo documento.