HTTP vs carga de FTP

Estoy construyendo un gran sitio web donde los miembros podrán cargar contenido (imágenes, videos) de hasta 20MB de tamaño (tal vez un poco menos de 15MB, aún no hemos establecido un límite de carga final pero será entre 10-25 MB).HTTP vs carga de FTP

Mi pregunta es, ¿debería ir con la carga HTTP o FTP en este caso. Tenga en cuenta que el 80-90% de las subidas serán de menor tamaño, como cca 1-3MB, pero de vez en cuando algunos miembros también querrán cargar archivos de gran tamaño (10MB +).

¿La carga HTTP es lo suficientemente confiable para archivos tan grandes o debería usar FTP? ¿Hay una notable diferencia de velocidad entre HTTP y FTP al cargar archivos?

Pregunto porque estoy usando Zend Framework que ya tiene un adaptador HTTP para subir archivos, en caso de que elija FTP, tendría que escribir mi propio adaptador para él.

Gracias!

Fuente

2009-08-06 Richard Knop

HTTP definitivamente supone una carga menor para sus clientes. Muchos lugares tienen proxies o firewalls que bloquean todo el tráfico FTP (dentro o fuera).

Fuente

2009-08-06 13:12:29

Existen varias razones técnicas para utilizar FTP a través de HTTP, pero creo que la experiencia del usuario las supera a todas. –

No Wanto ser sarcástico, pero Protocolo de transferencia de archivos debe ser más fiable sobre la transferencia de archivos :)

Fuente

2009-08-06 13:22:28

+13

No lo es. Es solo más viejo. – vy32

la disponibilidad de recursos/uso es más de un problema de fiabilidad o la velocidad. Cada carga consume recursos - hilo/memoria/etc - en su servidor web durante la carga. Si el tráfico de carga de contenido es significativo para archivos grandes, sería mejor usar FTP simplemente para liberar su servidor HTTP y responder mejor a las solicitudes de página.

Fuente

2009-08-06 13:25:02 ScottTx

Aún tendría que ejecutarse en la misma máquina, por lo que no habría ningún beneficio automático a menos que la implementación específica de FTP sea más eficiente/performante que una carga HTTP en ese servidor HTTP específico. O si usa algún tipo de almacenamiento compartido, también podría tener un servidor HTTP de carga dedicado por separado, por lo que no hay razón para preferir uno u otro. –

¿Por qué crees que estos tendrían que ejecutarse en la misma máquina? – ScottTx

Es de suponer que el servidor HTTP necesita acceder a los archivos cargados. –

es http subir lo suficientemente confiable para este tipo de archivos de gran tamaño

Una ventaja importante de FTP sería la capacidad de reanudar las subidas abortados. La mayoría de los servidores FTP y clientes lo admiten, aunque no siempre está activado. Mientras que con HTTP, es teóricamente posible usar encabezados especiales, pero un cliente normal (es decir, navegador) no lo admitirá.

Otra ventaja serían las cargas masivas: muy simple en FTP, pero no en HTTP.

¿Pero por qué no simplemente ofrecen ambas opciones? HTTP para aquellos que están detrás de proxies o no pueden/no pueden usar un cliente FTP, y FTP para las personas que tienen que subir muchas o grandes cargas a través de conexiones no confiables.

Fuente

2009-08-06 14:01:46

Las cargas FTP no se realizarían con un cliente FPT. Se realizaría a través del navegador web en código PHP. El único problema es que tendría que escribir mi propia clase de adaptador para cargas FTP (porque Zend Framework actualmente solo admite HTTP), lo que me llevaría algún tiempo y tengo una fecha límite. –

No veo cómo la implementación de la parte del servidor tiene algo que ver con qué cliente se usa. Webbrowsers no necesariamente soportan la carga FTP en absoluto (Firefox no lo hace, aunque creo que hay un complemento). Pero si no puede usar un servidor FTP existente, definitivamente no es una buena idea implementarlo usted mismo. –

La gran ventaja de HTTP es que va más allá de los firewalls y es muy fácil de cifrar: solo use HTTPS en el puerto 443 en lugar de HTTP en el puerto 80. Ambos pasan por proxies y firewalls. Y en estos días es muy fácil cargar un archivo de 20 MB a través de HTTP/HTTPS utilizando un POST.

El problema con HTTP es que no se puede reiniciar para las cargas. Si obtiene el 80% del archivo enviado y luego hay una falla, deberá reiniciar al principio. Es por eso que los proveedores utilizan cada vez más cargadores y descargadores basados en Flash, basados en Java o basados en JavaScript. Estos sistemas pueden ver cuánto del archivo se ha enviado, enviar un MAC para asegurarse de que ha llegado correctamente y volver a enviar las partes que faltan.

Un MAC es más importante de lo que piensas. Las sumas de comprobación TCP son solo de 32 bits, por lo que hay una probabilidad de 1 en 4.000 millones de que no se detecte un error. Eso potencialmente sucede mucho con Internet de hoy.

Fuente

2009-08-06 14:06:05 vy32

Es cierto que los POST de HTTP no se pueden reiniciar, pero Flash y Javascript no pueden hacer HTTP PUT con archivos como Java. –

Sí, y mi respuesta dice que los proveedores utilizan cada vez más cargadores flash y basados en Java porque son reiniciables. – vy32

¿El puerto 433 no es más típicamente HTTPS en lugar de 437? –

-5

FTP consumirá menos ancho de banda que HTTP, ya que este último necesitará codificar (base64) el contenido binario en texto sin formato para aumentar así el tamaño total de la transferencia. (por 1/3).

Sin embargo, el consumo de ancho de banda puede no ser necesariamente la mayor preocupación, en comparación con otros factores como la usabilidad y la seguridad, en los que prevalece HTTP.

Fuente

2009-08-06 14:06:06 hongliang

¿qué? base64 la carga? no, no. utilizando multipart/form-data sube como binario. –

Definitivamente, opto por el enfoque HTTP como el resto de la gente aquí. La razón de esto es lo que ha dicho sobre la mayoría de los archivos que son de uno a tres megabytes.

El problema es que el "descanso", por lo que:

¿ha considerado lo que permite a los usuarios enviar archivos grandes a través de correo electrónico a un script demonio que recibe los mensajes de correo electrónico y descarga los mensajes de correo electrónico a la cuenta asociada a la ¿remitente? O existe la solución de la carga de flash, en un enfoque de Facebook.

Fuente

2009-08-06 19:07:37

HTTP vs carga de FTP

Respuesta

Cuestiones relacionadas