Я вручную копирую файл на сервер, а тот же - на SFTP-сервер. Файл равен 140 МБ.
FTP: у меня скорость arround 11MB/s
SFTP: у меня скорость arround 4.5MB/s
Я понимаю, что файл должен быть зашифрован перед отправкой. Это единственное влияние на передачу файлов? (и на самом деле это не совсем время передачи, а время шифрования).
Я удивлен такими результатами.
Я являюсь автором HPN-SSH, и меня попросил комментатор здесь, чтобы взвесить. Я бы хотел начать с нескольких фоновых элементов. Во-первых, важно помнить, что SSHv2 - это мультиплексированный протокол - несколько каналов по одному TCP-соединению. Таким образом, каналы SSH по существу не знают о базовом алгоритме управления потоком, используемом TCP. Это означает, что SSHv2 должен реализовать свой собственный алгоритм управления потоком. Наиболее распространенная реализация в основном повторяет скользящие окна. Это означает, что у вас есть скользящее окно SSH, расположенное поверх скользящего окна TCP. Конечные результаты заключаются в том, что эффективный размер буфера приема является минимальным количеством принимаемых буферов двух раздвижных окон. У фонда OpenSSH есть максимальный размер буфера приема 2 МБ, но это действительно заканчивается ближе к ~ 1.2 МБ. Большинство современных ОС имеют буфер, который может расти (используя автонастройку приемных буферов) до эффективного размера 4 МБ. Почему это имеет значение? Если размер буфера приема меньше, чем продукт задержки полосы пропускания (BDP), вы никогда не сможете полностью заполнить канал независимо от того, насколько быстро ваша система.
Это осложняется тем фактом, что SFTP добавляет еще один уровень управления потоком в элементы управления потоком TCP и SSH. SFTP использует концепцию выдающихся сообщений. Каждое сообщение может быть командой, результатом команды или массовым потоком данных. Выдающиеся сообщения могут соответствовать конкретному размеру дейтаграммы. Таким образом, вы получаете то, что вы могли бы подумать, как еще один буфер приема. Размер этого буфера приема - размер дейтаграммы * максимальные выдающиеся сообщения (оба из которых могут быть установлены в командной строке). По умолчанию 32k * 64 (2MB). Поэтому при использовании SFTP вы должны убедиться, что буфер приема TCP, буфер приема SSH и буфер приема SFTP имеют достаточный размер (не слишком большой или у вас могут быть проблемы с буферизацией в интерактивных сеансах).
HPN-SSH напрямую адресует проблему буфера SSH, имея максимальный размер буфера около 16 МБ. Что еще более важно, буфер динамически растет до нужного размера, опросив запись proc для размера буфера TCP-соединения (в основном высунув отверстие между слоями 3 и 4). Это позволяет избежать избыточного буферизации практически во всех ситуациях. В SFTP мы увеличиваем максимальное количество невыполненных запросов до 256. По крайней мере, мы должны это делать - похоже, что это изменение не распространялось, как ожидалось, на набор патчей 6.3 (хотя это в 6.2. Я исправлю это в ближайшее время). Не существует версии 6.4, потому что 6.3 исправляет чистоту против 6.4 (это однострочное исправление безопасности от 6.3). Вы можете получить набор патчей от sourceforge.
Я знаю, что это звучит странно, но правильное определение размеров буферов было самым важным изменением с точки зрения производительности. Несмотря на то, что многие считают, что шифрование не является реальным источником низкой производительности в большинстве случаев. Вы можете доказать это себе, передавая данные в источники, которые все более далеки (с точки зрения RTT). Вы заметите, что чем дольше RTT, тем ниже пропускная способность. Это ясно указывает на то, что это проблема с производительностью, зависящей от RTT.
В любом случае, с этим изменением я начал видеть улучшения до 2-х порядков. Если вы понимаете TCP, вы поймете, почему это повлияло на ситуацию. Это не касается размера дейтаграммы или количества пакетов или чего-либо подобного. Это целиком, потому что для эффективного использования сетевого пути у вас должен быть буфер приема, равный количеству данных, которые могут находиться в пути между двумя хостами. Это также означает, что вы не видите никакого улучшения, если путь недостаточно быстрый и достаточно длинный. Если BDP меньше 1,2 МБ, HPN-SSH может не иметь для вас никакого значения.
Распараллеливаемый шифр AES-CTR - это повышение производительности на системах с несколькими ядрами, если вам нужно иметь полное шифрование до конца. Обычно я предлагаю людям (или иметь контроль над сервером и клиентом), чтобы использовать переключатель шифрования NONE (зашифрованная проверка подлинности, объемные данные передаются в ясном виде), поскольку большинство данных не все настолько чувствительны. Однако это работает только в неинтерактивных сеансах, таких как SCP. Он не работает в SFTP.
Есть и другие улучшения производительности, но не так важно, как правильное определение размеров буферов и работы с шифрованием. Когда я получу какое-то свободное время, я, вероятно, смогу связать процесс HMAC (в настоящее время самый большой показатель производительности) и сделать некоторые более мелкие работы по оптимизации.
Итак, если HPN-SSH настолько потрясающе, почему OpenSSH не принял его? Это долгая история и люди, которые знают команду OpenBSD, вероятно, уже знают ответ. Я понимаю многие из их причин - это большой патч, который потребует дополнительной работы с их целью (и они представляют собой небольшую команду), они не заботятся о производительности как безопасности (хотя нет никаких последствий для безопасности для HPN-SSH ) и т.д. и т.д. Однако, хотя OpenSSH не использует HPN-SSH Facebook. Так делают Google, Yahoo, Apple, самый большой исследовательский центр обработки данных, НАСА, НОАА, правительство, военные и большинство финансовых учреждений. В этот момент он довольно хорошо проверен.
Если у кого-то есть вопросы, не стесняйтесь спрашивать, но я не могу быть в курсе событий на этом форуме. Вы всегда можете отправлять мне почту через адрес электронной почты HPN-SSH (google it).
ОБНОВЛЕНИЕ: Как отметил комментатор, проблема, которую я изложил ниже, была исправлена за некоторое время до этого поста. Однако я знал о проекте HP-SSH и попросил автора взвесить. Как они объясняют в (справедливо) наиболее востребованном ответе, шифрование не является источником проблемы. Yay для электронной почты и люди умнее меня!
Ух ты, годовалый вопрос только с неправильными ответами. Однако я должен признать, что предположил, что замедление было связано с шифрованием, когда я задал себе тот же вопрос. Но задайте себе следующий логический вопрос: как быстро ваш компьютер может зашифровать и расшифровать данные? Если вы думаете, что скорость примерно равна 4,5 Мбит/с, о которых сообщает OP (0,56 МБ или примерно половина емкости 5,5-дюймового дискеты!), Несколько раз ударите себя, выпейте кофе и задайте себе тот же вопрос снова.
По-видимому, это связано с тем, что является недосмотром в выборе размера пакета или, по крайней мере, тем, что автор LIBSSH2 говорит,,
Характер SFTP и его ACK для каждого небольшого фрагмента данных, который он отправляет, заставляет начальную наивную реализацию SFTP сильно страдать при отправке данных по сетям с высокой задержкой. Если вам придется ждать несколько сотен миллисекунд для каждых 32 КБ данных, то быстрых передач SFTP никогда не будет. Такая наивная реализация - это то, что libssh2 предлагал до и включая libssh2 1.2.7.
Таким образом, снижение скорости происходит из-за крошечного размера пакета x обязательных ответов ack для каждого пакета, что явно безумно.
Проект Высокопроизводительный SSH/SCP (HP-SSH) предоставляет набор исправлений OpenSSH, который, очевидно, улучшает внутренние буферы, а также распараллеливает шифрование. Тем не менее, обратите внимание, что даже непараллельные версии работали на скоростях выше незашифрованных скоростей 40 Мбит/с, полученных некоторыми комментаторами. Исправление включает в себя изменение способа, которым OpenSSH вызывал библиотеки шифрования, а не шифр, и между AES128 и AES256 нулевая разница в скорости. Шифрование занимает некоторое время, но оно маргинально. Это могло иметь значение еще в 90-х, но (как и скорость Java против C) это просто не имеет значения.
Несколько факторов влияют на скорость передачи SFTP:
Шифрование имеет не только cpu, но и некоторые сетевые служебные данные.
Есть все виды вещей, которые могут это сделать. Одна из возможностей - "Формирование трафика". Обычно это делается в офисных средах для резервирования полосы пропускания для важных для бизнеса операций. Это также может быть сделано веб-хостинговой компанией или вашим интернет-провайдером по очень сходным причинам.
Вы также можете настроить его дома очень просто.
Например, может существовать правило резервирования минимальной полосы пропускания для FTP, в то время как SFTP может подпадать под правило "все остальное". Или может быть ограничение пропускной способности для SFTP, но кто-то еще использует SFTP одновременно с вами.
Итак: Где вы передаете файл с и?
SFTP не FTP через SSH, это другой протокол и похож на SCP, он предлагает больше capabilities.
Для сравнения я попытался передать изображение диска ntfs 299GB с ноутбука i5, работающего с Raring Ringtail Ubuntu alpha 2 live cd, на рабочий стол i7 с Ubuntu 12.04.1. Зарегистрированные скорости:
через wifi + powerline: scp: 5 МБ/с (40 Мбит/с)
по сравнению с Gigabit Ethernet + netgear G5608 v3:
scp: 44 МБ/с
sftp: 47 МБ/с
sftp -C: 13MB/sec
Таким образом, по хорошей гигабитной ссылке sftp немного быстрее, чем scp, быстрые процессоры с быстрыми темпами 2010-го года кажутся достаточно быстрыми для шифрования, но сжатие не выигрыш во всех случаях.
По причине плохой связи gigabit ethernet, у меня был sftp, намного превосходящий scp. Что-то о том, что scp является очень частым, см. "Scp UNBELIEVABLY slow" на comp.security.ssh с 2008 года: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/ldPV3msFFQw http://fixunix.com/ssh/368694-scp-unbelievably-slow.html
Ваши результаты имеют смысл. Поскольку FTP работает по нешифрованному каналу, он быстрее, чем SFTP (который является подсистемой поверх протокола SSH версии 2). Также помните, что SFTP - это протокол на основе пакетов, в отличие от FTP, который основан на команде.
Каждый пакет в SFTP зашифровывается перед записью в исходящий сокет от клиента и впоследствии дешифруется при его получении сервером. Этот курс ведет к медленным скоростям передачи, но очень безопасный перевод. Использование сжатия, такого как zlib с SFTP, улучшает время передачи, но все равно он не будет находиться где-то рядом с текстовым FTP. Возможно, лучше сравнить сравнение SFTP с FTPS, которые используют шифрование?
Скорость для SFTP зависит от шифрования, используемого для шифрования/дешифрования, используемого сжатия, например. zlib, размеры пакетов и размеры буфера, используемые для подключения сокета.
SFTP почти всегда будет значительно медленнее, чем FTP или FTPS (обычно на несколько порядков). Причина различия заключается в том, что протоколу SSH2 присуще множество дополнительных пакетов, шифрования и рукопожатия, о которых не нужно беспокоиться. FTP - это очень простой и сравнительно простой протокол, практически не требующий дополнительной передачи данных, и этот протокол был специально разработан для быстрой передачи файлов. Шифрование замедлит работу FTP, но не до уровня SFTP.
SFTP работает по SSH2 и гораздо более подвержен задержкам в сети и ограничениям ресурсов компьютера и клиента. Эта повышенная восприимчивость обусловлена дополнительным подтверждением связи данных, связанным с каждым пакетом, передаваемым между клиентом и сервером, и дополнительной сложностью, присущей декодированию пакета SSH2. SSH2 был разработан как замена для Telnet и других небезопасных удаленных оболочек, а не для очень высокоскоростной связи. Гибкость, которую обеспечивает SSH2 для безопасной упаковки и передачи практически любого типа данных, также вносит значительный вклад в протокол и усложняет его.
Однако все еще возможно получить скорость передачи данных в несколько МБ/с между клиентом и сервером, используя SFTP, если присутствуют подходящие условия сети. Ниже приведены элементы, которые необходимо проверить при попытке максимизировать скорость передачи SFTP:
Есть ли в вашей сети брандмауэр или сетевое устройство для проверки или регулирования трафика SSH2? Это может замедлить ход событий. Проверьте настройки брандмауэра. У нас есть пользователи, которые сообщают, что решают очень медленные передачи файлов SFTP, изменяя правила брандмауэра. SFTP-клиент, который вы используете, может иметь большое значение. Попробуйте несколько разных клиентов SFTP и посмотрите, если вы получите разные результаты. Сетевая задержка сильно повлияет на SFTP. Если ссылка, по которой вы находитесь, имеет высокую степень задержки, то это будет проблемой для быстрых переводов. Насколько мощен сервер? Шифрование с SFTP очень интенсивно. Убедитесь, что у вас достаточно мощный компьютер, который не перегружен во время передачи файлов SFTP (высокая загрузка ЦП).
Узнать больше: https://support.cerberusftp.com/hc/en-us/articles/203333215-Why-is-SSH2-SFTP-so-much-slower-than-FTP-and-FTPS-
Да, шифрование добавляет некоторую нагрузку на ваш процессор, но если ваш процессор не является древним, это не должно затрагивать столько, сколько вы говорите.
Если вы включите сжатие для SSH, SCP на самом деле быстрее FTP, несмотря на шифрование SSH (если я помню, в два раза быстрее, чем FTP для файлов, которые я пытался). Я фактически не использовал SFTP, но я считаю, что он использует SCP для фактической передачи файлов. Поэтому, пожалуйста, попробуйте это и сообщите нам: -)