Сравнение HTTP и FTP для передачи файлов


125

Каковы преимущества (или ограничения) одного перед другим при передаче файлов через Интернет?

(Мне известны безопасные формы обоих протоколов. Я хотел бы услышать сравнение на личном опыте с точки зрения производительности, надежности, ограничений размера файла и т. Д.)

Ответы:


99

Вот сравнение производительности этих двух. HTTP более отзывчив к запросам-ответам для небольших файлов, но FTP может быть лучше для больших файлов при правильной настройке. Обычно FTP считался более быстрым. FTP требует, чтобы канал управления и состояние поддерживалось помимо состояния TCP, а HTTP - нет. Перед передачей данных по FTP выполняется 6 пакетов, а в HTTP - только 4.

Я думаю, что правильно настроенный TCP-уровень больше повлияет на скорость, чем разница между протоколами прикладного уровня. В Sun Blueprint Understanding Tuning TCP есть подробности.

Вот еще одно хорошее сравнение индивидуальных характеристик каждого протокола.


22
+1 хороший ответ. Я думаю, что день FTP прошел, он уже не имеет большого значения. Это также абсолютная свинья для реализации.
skaffman

7
Какой размер подразумевается под «маленькими» или «большими» файлами?
Urbycoz

В сравнение производительности ссылка указывает на анализ ожидаемых выгод от реализации P-HTTP - T / TCP, а также S-TCB. Ни где не упоминается FTP. Кроме того, неправильно настроенная ссылка не работает.
Trisped

@Trisped вы читали ссылку для сравнения производительности? Существует 12 ссылок на FTP, и в самом первом разделе говорится: «Протокол HTTP изначально был разработан для уменьшения неэффективности FTP ...», а затем продолжается объяснение. Я также обновил ссылку «Общие сведения о настройке TCP» ... похоже, Oracle выбросила все старые технические документы Sun Blueprints.
Джон Эллинвуд

2
16 августа 1996 года ... правда? Даже в своем ответе 2009 года вы не могли ожидать, что это будет репрезентативным для текущего положения дел. -1
user541686 04

29

Я только что протестировал передачу файлов по FTP и HTTP:

  • более двух очень хороших соединений с сервером
  • используя тот же файл .zip размером 1 ГБ
  • в одинаковых сетевых условиях (проверено одно за другим)

Результат:

  • через FTP: 6 минут
  • используя HTTP: 4 минуты
  • с использованием параллельного загрузчика http ( fdm): 1 минута

Итак, в "реальной жизни":

1) HTTP быстрее FTP при загрузке одного большого файла.

2) HTTP может использовать параллельную загрузку фрагментов, что делает его в 6 раз быстрее, чем FTP, в зависимости от условий сети.


18
Это кажется очень анекдотичным.
spenibus

5
@anecdotal он предоставил цифры (факты из исследования), которые пока менее анекдотичны, чем любой другой ответ.
user1133275

Воспроизводятся ли времена хотя бы приблизительно?
masterxilo

Несколько дней назад я попытался загрузить файлы размером 90 МБ с помощью http, сбой сети на 2 МБ. Но с ftp (тот же сервер, тот же файл, та же сеть через мобильную точку доступа) загрузка прошла успешно. Не знаю почему.
Рахмат Ихсан

1
ftp работает быстрее для отдельных файлов из-за меньших накладных расходов. Если ваше тестирование дало другой ответ, попробуйте другой клиент (или, что менее вероятно, другой сервер). http не может загружаться быстрее, чем максимальная скорость передачи данных, и любой параллельный вариант, используемый для попытки превысить это значение, приведет к накладным расходам протокола. Против Мультифайлы могут передаваться друг за другом на линейной скорости по FTP без дополнительных затрат протокола. Параллельный вариант FTP использует несколько TCP-соединений, которые обычно превосходят одноточечные соединения (например, SMB3.1 vSMB2.1, 3.x может использовать множественное соединение).
Астара

27

Многие брандмауэры отбрасывают исходящие соединения, которые не относятся к портам 80 или 443 (http и https); некоторые даже разрывают подключения к тем портам, которые не являются HTTP (S). FTP может быть разрешен или запрещен, не говоря уже об активных / PASV режимах.

Кроме того, HTTP / 1.1 позволяет намного лучше выполнять частичные запросы («отправлять только с байта 123456 до конца файла»), условные запросы и кеширование («отправлять только при изменении содержимого / при изменении даты последнего изменения») и сжатия содержимого. (GZIP).

HTTP намного проще использовать через прокси.

Судя по моим анекдотическим свидетельствам, HTTP легче заставить работать с сброшенными / медленными / нестабильными соединениями; например, нет необходимости (повторно) устанавливать сеанс входа в систему перед (повторным) инициированием передачи.

OTOH, HTTP не имеет состояния, поэтому вам придется самостоятельно выполнять аутентификацию и отслеживать, «кто что и когда сделал».

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

Обратите внимание, что HTTP / 2 предлагает еще больше оптимизаций, в то время как протокол FTP не видел обновлений в течение десятилетий (и даже расширения для FTP не очень популярны среди пользователей). Итак, если вы не передаете файлы через машину времени, HTTP, похоже, победил.

(Касательно: есть протоколы, которые лучше подходят для передачи файлов, например rsyncBitTorrent, но они не так важны, тогда как HTTP - это везде ™)


13

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

Если вы все же решите использовать FTP, обязательно прочтите об Активном и Пассивном FTP .

С точки зрения производительности, в конце концов, они оба выбрасывают файлы напрямую через TCP-соединения, поэтому должно быть примерно одинаково.


-5

Оба они используют TCP в качестве транспортного протокола, но HTTP использует постоянное соединение, что улучшает производительность TCP.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.