Caricamento HTTP vs FTP

Question

Sto costruendo un sito Web di grandi dimensioni in cui i membri potranno caricare contenuti (immagini, video) fino a 20 MB di dimensioni (forse un po 'meno 15 MB, non abbiamo ancora definito un limite di caricamento finale ma sarà tra i 10-25 MB).

La mia domanda è, devo andare con HTTP o FTP caricare in questo caso. Ricorda che l'80-90% dei caricamenti sarà di dimensioni più piccole, come cca 1-3 MB, ma di volta in volta alcuni membri vorranno anche caricare file di grandi dimensioni (10 MB +).

Il caricamento HTTP è abbastanza affidabile per file di grandi dimensioni o devo andare con FTP? C'è una notevole differenza di velocità tra HTTP e FTP durante il caricamento dei file?

Sto chiedendo perché sto usando Zend Framework che ha già l'adattatore HTTP per i caricamenti di file, nel caso in cui scelgo FTP, dovrei scrivere il mio adattatore per questo.

Grazie!

Answer 1

HTTP mette decisamente meno di un onere per i vostri clienti. Molti luoghi hanno proxy o firewall che bloccano tutto il traffico FTP (dentro o fuori).

Answer 2

Non vuoi anche essere sarcastico, ma File Transfer Protocol devo essere più affidabile sul trasferimento di file :)

Answer 3

disponibilità delle risorse/utilizzo è più di un problema di affidabilità o la velocità. Ogni upload consuma risorse - thread/memoria/etc - sul tuo server web per tutta la durata del caricamento. Se il traffico di caricamento del contenuto è significativo per i file di grandi dimensioni, sarebbe preferibile utilizzare FTP semplicemente per liberare il server HTTP in modo da essere più reattivo alle richieste di pagina.

Answer 4

è http caricando abbastanza affidabile per tali file di grandi dimensioni

Uno dei principali vantaggi di FTP sarebbe la capacità di riprendere arrivi abortiti. La maggior parte dei server e client FTP supporta questo, sebbene non sia sempre attivato. Mentre con HTTP, è teoricamente possibile utilizzare intestazioni speciali, ma un normale client (cioè il browser) non lo supporta.

Un altro vantaggio sarebbe il caricamento collettivo: molto semplice in FTP, non così in HTTP.

Ma perché non offrire semplicemente entrambe le opzioni? HTTP per coloro che sono dietro a proxy o che non possono/non possono utilizzare un client FTP e FTP per le persone che devono caricare caricamenti di grandi dimensioni o di grandi dimensioni su connessioni non affidabili.

Answer 5

Il grande vantaggio di HTTP è che supera i firewall ed è molto facile da crittografare --- basta utilizzare HTTPS sulla porta 443 anziché HTTP sulla porta 80. Entrambi passano attraverso proxy e firewall. E in questi giorni è piuttosto facile caricare un file da 20 MB su HTTP/HTTPS usando un POST.

Il problema con HTTP è che non è riavviabile per i caricamenti. Se si ottiene l'80% del file inviato e si verifica un errore, sarà necessario riavviare all'inizio. Ecco perché i fornitori utilizzano sempre più caricatori e downloader basati su flash, java o javascript. Questi sistemi possono vedere quanto del file è stato inviato, inviare un MAC per assicurarsi che sia arrivato correttamente e inviare di nuovo le parti mancanti.

Un MAC è più importante di quanto si possa pensare. I checksum TCP sono solo a 32 bit, quindi c'è una probabilità di 1 su 4 miliardi di errore che non viene rilevato. Ciò accade potenzialmente molto con l'internet di oggi.

Answer 6

FTP consumerà meno larghezza di banda di HTTP, poiché quest'ultimo dovrà codificare (base64) il contenuto binario in testo normale, aumentando così la dimensione di trasferimento totale. (per 1/3).

Tuttavia, il consumo di larghezza di banda potrebbe non essere necessariamente la preoccupazione principale, rispetto ad altri fattori come l'usabilità e la sicurezza, in cui prevalgono HTTP.

Answer 7

Sicuramente, optare per l'approccio HTTP come il resto delle persone qui. La ragione di ciò è ciò che hai detto sulla maggior parte dei file che vanno da uno a tre megabyte.

Il problema è per il "resto", così:

Avete preso in considerazione consentendo agli utenti di inviare file di dimensioni maggiori tramite e-mail a uno script demone che ottiene i messaggi di posta elettronica e carica i messaggi di posta elettronica per l'account associato con il mittente? Oppure c'è la soluzione del flash uploader, in un approccio di tipo facebook.