Загрузка HTTP и FTP

Я создаю большой веб-сайт, где участникам будет разрешено загружать контент (изображения, видео) размером до 20 МБ (возможно, чуть меньше, чем 15 МБ, мы еще не определились с окончательным пределом загрузки, но это будет где-то между 10-25 МБ).

Мой вопрос: должен ли я идти с загрузкой HTTP или FTP в этом случае. Имейте в виду, что 80-90% загрузок будут меньшего размера, например, 1-3 МБ, но время от времени некоторые участники также захотят загружать большие файлы (10 МБ +).

Является ли загрузка HTTP достаточно надежной для таких больших файлов, или я должен идти с FTP? Есть ли заметная разница в скорости между HTTP и FTP при загрузке файлов?

Я спрашиваю, потому что я использую Zend Framework, у которого уже есть HTTP-адаптер для загрузки файлов, в случае, если я выбираю FTP, мне пришлось бы написать для него свой собственный адаптер.

Спасибо!

Ответ 1

HTTP определенно снижает нагрузку на ваших клиентов. Во многих местах есть прокси или брандмауэры, которые блокируют весь FTP-трафик (в или из).

Ответ 2

Большое преимущество HTTP заключается в том, что он проходит через брандмауэры и очень легко шифруется - просто используйте HTTPS на порту 443 вместо HTTP на порту 80. Оба проходят через прокси и брандмауэры. И в эти дни довольно легко загрузить файлы размером 20 МБ через HTTP/HTTPS с помощью POST.

Проблема с HTTP заключается в том, что она не перезапускается для загрузки. Если вы получите 80% отправленного файла, а затем произойдет сбой, вам нужно будет перезапустить его с самого начала. Именно поэтому поставщики все чаще используют флеш-основе, java-based или javascript-based загрузчики и загрузчики. Эти системы могут видеть, какая часть файла была отправлена, отправить MAC, чтобы убедиться, что он прибыл должным образом, и повторно отправить те части, которые отсутствуют.

MAC более важен, чем вы думаете. Контрольные суммы TCP составляют всего 32 бита, поэтому существует вероятность ошибки 1-в-4 миллиарда. Это потенциально очень часто происходит с сегодняшним интернетом.

Ответ 3

Является ли HTTP-загрузкой достаточно надежной для такие большие файлы

Одним из основных преимуществ FTP будет возможность возобновить отмененные загрузки. Большинство FTP-серверов и клиентов поддерживают это, хотя оно не всегда активировано. В то время как с HTTP, теоретически возможно использование специальных заголовков, но обычный клиент (т.е. Браузер) не будет поддерживать его.

Еще одно преимущество - массовые закачки: очень просто в FTP, а не в HTTP.

Но почему бы не просто предложить оба варианта? HTTP для тех, кто находится за прокси-серверами или не сможет/не может использовать FTP-клиент, и FTP для людей, которым приходится загружать много или больших загрузок по ненадежным соединениям.

Ответ 4

Я не хочу быть саркастичным, но протокол передачи файлов должен быть более надежным при передаче файлов:)

Ответ 5

Доступность/использование ресурсов - это скорее проблема, чем надежность или скорость. Каждая загрузка потребляет ресурсы - поток/память/etc - на вашем веб-сервере на время загрузки. Если трафик загрузки контента значителен для больших файлов, было бы лучше использовать FTP просто, чтобы ваш HTTP-сервер мог более реагировать на запросы страниц.

Ответ 6

Я определенно выбираю подход HTTP, как и остальные люди здесь. Причина этого в том, что вы сказали о том, что большинство файлов имеют от одного до трех мегабайт.

Проблема заключается в "отдыхе", поэтому:

Рассматривали ли вы возможность отправлять более крупные файлы по электронной почте в deamon script, который получает электронные письма и загружает электронные письма в учетную запись, связанную с отправителем? Или есть решение флеш-загрузчика в подходе, подобном facebook.

Ответ 7

FTP будет потреблять меньше полосы пропускания, чем HTTP, поскольку последнему необходимо будет закодировать (base64) двоичный контент в обычный текст, таким образом, увеличить общий размер передачи. (на 1/3).

Однако потребление полосы пропускания необязательно может быть главной проблемой, сравнимой с другими факторами, такими как удобство использования и безопасность, в которых преобладает HTTP.