Скорость не является важной разницей между FTP и остальными.
ceejayoz
2
Я не уверен, почему за это проголосовали не по теме. Это, безусловно, очень важно для моей работы в качестве профессионального системного администратора - почему при передаче файлов не использовалась полоса пропускания всего пути соединения?
Дэн
Вы можете компенсировать разницу скоростей SFTP, используя несколько соединений TCP, управляемых LFTP, и зеркальную подсистему, использующую SFTP, не жертвуя безопасностью. Он может даже использовать несколько потоков для одного большого файла.
Аарон
Ответы:
29
Если у вас есть сеть быстро широкой области вы увидите , что sftpи scpпримерно с той же скоростью, что медленно. Они оба страдают от проблем с производительностью в основном openssh. На современном оборудовании это происходит не из-за накладных расходов на шифрование, а скорее из-за проблем с реализацией openssh - он реализует свой собственный механизм внутреннего управления окнами, который нарушает быстрые соединения.
Эти проблемы становятся более очевидными при соединении на большие расстояния (с более высокой задержкой), но я испытывал медлительность даже в локальных сетях.
Они хорошо документированы, и исправления доступны для решения проблемы. Исправление любого конца соединения может помочь; в идеале вы должны исправить оба конца. Для получения дополнительной информации и исправлений см. Высокопроизводительный SSH в Питтсбургском суперкомпьютерном центре.
Кстати, издержки шифрования тоже могут стать проблемой, как только проблема окон будет решена. Патчи также исправили это.
Между тем, вы обнаружите, что ftpэто крайне небезопасно; он отправляет пароли в виде простого текста.
ftpsЯ думаю, что оборачивает протокол FTP в SSL. это, вероятно, быстрее, чем непатентованный SFTP / SCP.
Последнее замечание: по моему опыту, клиент WinSCP (по крайней мере иногда) мучительно медленный. Я не знаю почему, но, основываясь на их FAQ, я не единственный, у кого была эта проблема. Так что, если вы работаете с Windows, и это кажется медленным, попробуйте другой клиент. Даже с непатентованным сервером openssh вы можете сделать намного лучше с другим клиентом. Я не уверен, какие хорошие клиенты, к сожалению.
В заключение. Тот, кто знает, о чем они говорят. Да, FTPS - это в основном FTP в SSL. SFTP / SCP всегда будет работать медленнее, чем при использовании FTP
Jason
Есть ли у вас какие-либо идеи, почему я получаю 300 кбит / с с помощью scp, а примерно 10 Мбит / с (почти максимальная скорость) с помощью sftp? Это не похоже на «примерно одинаковую скорость». Это более 100 Мбит / с Ethernet.
Graywolf
Лучше всего предположить, что ваш scp является ошибочной реализацией (например, WinSCP), но ваш sftp - нет. Даже если они находятся в одной оболочке GUI, они могут отличаться внутри.
Дэн Притц
Дэн, есть идеи, почему этот патч SSH не применяется к основному OpenSSH? Очевидно, что это на 1-2 порядка лучше (> 10x даже в 100 Мбит / с локальной сети), так почему же это не новый стандарт OpenSSH? Как мы можем сделать это так?
Габриэль Стейплз
Насколько я понимаю, PSC отправил патчи людям openbsd (которые пишут openssh). Они не были заинтересованы. Я слышал смутные заявления о том, что ни у кого из людей openbsd не было подключений с высокой пропускной способностью, и они не замечали каких-либо проблем и / или обязательно полагали, что существует настоящая проблема. Это было несколько лет назад, и это слух, поэтому я не могу ручаться за его точность.
Дэн
4
В целом все протоколы будут работать примерно одинаково. Скорее всего, вы будете ограничены скоростью вашей сети или диска, а не протоколом.
В более старых версиях OpenSSH (SFTP / SCP) использовался фиксированный размер окна, который ограничивал бы скорость в сетях с высокой задержкой (скажем, трансатлантических). Существует набор исправлений для решения этой проблемы, называемый HPN (высокопроизводительные сети), и он включен в большинство современных установок OpenSSH.
Если вы работаете в такой ситуации, как гигабитный или более быстрый канал локальной сети и более медленный процессор, SFTP / SCP может столкнуться с узким местом. Вы сможете сказать, потому что процесс ssh / scp / sftp будет использовать 100% процессора на отправляющем или получающем хостинге. Если вы используете более новую версию OpenSSH (6.4+), вы можете включить многопоточную версию шифра AES, которая сможет использовать более 1 ядра для обработки шифрования и с меньшей вероятностью будет ограничена ЦП, а не диском или пропускная способность сети.
Если вы управляете как отправляющей, так и принимающей стороной, OpenSSH 6+ также имеет опциональный режим «NONECIPHER». Он использует обычное шифрование / ключи и т. Д. Для входа на удаленную машину, но затем переходит к незашифрованному соединению для фактического копирования файла. Это снимет нагрузку на процессор. В NONECIPHER встроены средства защиты, которые не позволяют получить оболочку без шифрования.
В конце концов, протокол не должен быть ограничением по скорости, хотя более старые версии ssh действительно имеют проблемы с каналами с высокой задержкой.
Полезно знать, что по умолчанию теперь установлены патчи, хотя похоже, что redhat явно отказался от этого ( access.redhat.com/site/solutions/53215 ). Также обратите внимание, что трансатлантическая латентность на самом деле не так уж велика. Текущий пинг rtts: umich -> Стэнфорд (Калифорния): 89мс. umich -> Кембридж (Великобритания): 134мс. Кроме того, не является ли сочетание задержки и пропускной способности причиной проблемы? поэтому более низкая задержка, но более высокая пропускная способность каналов все еще может иметь проблемы.
Дэн Притц
3
Исходя из издержек шифрования, я бы сказал, что обычный FTP, вероятно, имеет немного лучшую производительность, чем другие протоколы, но, вероятно, он незначителен. Я бы сначала использовал протокол, который обеспечивает необходимую вам безопасность, а затем беспокоился о пропускной способности.
При этом вам нужно будет установить тест, чтобы найти реальные цифры. Все выше только мое мнение. Если вы тестируете производительность локально, настройте сервер в своей сети. Если конечное использование будет через Интернет, проверьте с внешнего хоста.
Снижение производительности - это порядки величин, а не незначительные. Ближе к 10x, чем в 2 раза медленнее. Я был удивлен сам.
Гомибуши
2
Как всегда, Google содержит ответы: FTP v / s SFTP v / s FTPS, в
котором говорится, что FTP> FTPS> SFTP
FTP также оказывается быстрее, чем SCP в чужом тесте ( http://www.lysesoft.com/support/forums /viewtopic.php?f=5&t=542 ) но я бы порекомендовал попробовать это на себе.
Так что просто настройте SCP и FTP на любом случайном устройстве в вашей сети, затем запустите обычную передачу файлов и посмотрите, сколько времени потребуется для обоих
почему вы говорите, что FTP - это интернет-протокол и SCP для локальной сети?
Дэн Притц
5
Ах, я вижу, вы получили это из связанной статьи eHow. eHow не так. Оба протокола были разработаны для использования в Интернете. В статье есть несколько других ошибок; писатель явно не знает, о чем говорит.
Дэн Притц
Теперь, когда я думаю об этом, вы правы, наверное, мне следовало проверить.
1
Такие сайты, как eHow, никогда не знают, о чем говорят.
Ответы:
Если у вас есть сеть быстро широкой области вы увидите , что
sftpиscpпримерно с той же скоростью, что медленно. Они оба страдают от проблем с производительностью в основном openssh. На современном оборудовании это происходит не из-за накладных расходов на шифрование, а скорее из-за проблем с реализацией openssh - он реализует свой собственный механизм внутреннего управления окнами, который нарушает быстрые соединения.Эти проблемы становятся более очевидными при соединении на большие расстояния (с более высокой задержкой), но я испытывал медлительность даже в локальных сетях.
Они хорошо документированы, и исправления доступны для решения проблемы. Исправление любого конца соединения может помочь; в идеале вы должны исправить оба конца. Для получения дополнительной информации и исправлений см. Высокопроизводительный SSH в Питтсбургском суперкомпьютерном центре.
Кстати, издержки шифрования тоже могут стать проблемой, как только проблема окон будет решена. Патчи также исправили это.
Между тем, вы обнаружите, что
ftpэто крайне небезопасно; он отправляет пароли в виде простого текста.ftpsЯ думаю, что оборачивает протокол FTP в SSL. это, вероятно, быстрее, чем непатентованный SFTP / SCP.Последнее замечание: по моему опыту, клиент WinSCP (по крайней мере иногда) мучительно медленный. Я не знаю почему, но, основываясь на их FAQ, я не единственный, у кого была эта проблема. Так что, если вы работаете с Windows, и это кажется медленным, попробуйте другой клиент. Даже с непатентованным сервером openssh вы можете сделать намного лучше с другим клиентом. Я не уверен, какие хорошие клиенты, к сожалению.
источник
В целом все протоколы будут работать примерно одинаково. Скорее всего, вы будете ограничены скоростью вашей сети или диска, а не протоколом.
В более старых версиях OpenSSH (SFTP / SCP) использовался фиксированный размер окна, который ограничивал бы скорость в сетях с высокой задержкой (скажем, трансатлантических). Существует набор исправлений для решения этой проблемы, называемый HPN (высокопроизводительные сети), и он включен в большинство современных установок OpenSSH.
Если вы работаете в такой ситуации, как гигабитный или более быстрый канал локальной сети и более медленный процессор, SFTP / SCP может столкнуться с узким местом. Вы сможете сказать, потому что процесс ssh / scp / sftp будет использовать 100% процессора на отправляющем или получающем хостинге. Если вы используете более новую версию OpenSSH (6.4+), вы можете включить многопоточную версию шифра AES, которая сможет использовать более 1 ядра для обработки шифрования и с меньшей вероятностью будет ограничена ЦП, а не диском или пропускная способность сети.
Если вы управляете как отправляющей, так и принимающей стороной, OpenSSH 6+ также имеет опциональный режим «NONECIPHER». Он использует обычное шифрование / ключи и т. Д. Для входа на удаленную машину, но затем переходит к незашифрованному соединению для фактического копирования файла. Это снимет нагрузку на процессор. В NONECIPHER встроены средства защиты, которые не позволяют получить оболочку без шифрования.
В конце концов, протокол не должен быть ограничением по скорости, хотя более старые версии ssh действительно имеют проблемы с каналами с высокой задержкой.
источник
Исходя из издержек шифрования, я бы сказал, что обычный FTP, вероятно, имеет немного лучшую производительность, чем другие протоколы, но, вероятно, он незначителен. Я бы сначала использовал протокол, который обеспечивает необходимую вам безопасность, а затем беспокоился о пропускной способности.
При этом вам нужно будет установить тест, чтобы найти реальные цифры. Все выше только мое мнение. Если вы тестируете производительность локально, настройте сервер в своей сети. Если конечное использование будет через Интернет, проверьте с внешнего хоста.
источник
Как всегда, Google содержит ответы:
FTP v / s SFTP v / s FTPS, в
котором говорится, что FTP> FTPS> SFTP
FTP также оказывается быстрее, чем SCP в чужом тесте ( http://www.lysesoft.com/support/forums /viewtopic.php?f=5&t=542 ) но я бы порекомендовал попробовать это на себе.
Так что просто настройте SCP и FTP на любом случайном устройстве в вашей сети, затем запустите обычную передачу файлов и посмотрите, сколько времени потребуется для обоих
источник