Загрузка HTTP и FTP

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

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

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

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

Благодаря!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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