Почему максимальная скорость передачи файлов FileZilla SFTP ограничена 1,3 МБ / с вместо насыщения доступной полосы пропускания? rsync и WinSCP еще медленнее
Я загружаю с сервера, и максимальная скорость загрузки составляет 1,3 МБ / с с помощью FileZilla, но я могу начать одновременную загрузку, и они также будут загружаться со скоростью 1,3 МБ / с. Так почему я не могу загрузить только один файл со скоростью более 1,3 МБ / с и приблизиться к насыщению доступной полосы пропускания (~6+ МБ / с)?
Я знаю, что могу использовать какой-нибудь другой SFTP-клиент, который поддерживает сегментированные загрузки, такие как lftp, знаете о других хороших программах с открытым исходным кодом?
Но я все еще хочу знать, что ограничивает загрузку одного файла всего 1,3 МБ / с, это какое-то техническое ограничение с TCP и буферами и т. Д. Или какая-то проблема конфигурации? Я проверил и, конечно же, для FileZilla не включено никакого регулирования трафика.
Также я попытался rsync, и это было хуже, чем FileZilla/SFTP. Я также попробовал WinSCP, и он был самым медленным независимо от метода SCP/SFTP. Так что при 1,3 МБ / с постоянная передача FileZilla довольно хороша по сравнению с другими методами передачи.
Если у кого-то есть хорошее объяснение того, почему скорость передачи данных составляет 1,3 МБ / с, мне бы очень хотелось знать, и возможно ли это увеличить, не прибегая к использованию сегментированной загрузки. Сервер работает под управлением OpenSSH 6.7p1 (Debian), клиент - FileZilla в Windows.
ОБНОВЛЕНИЕ: В ответ на информацию Мартина (см. Его ответ ниже) я добавляю, что пинг от 180 мс до 190 мс довольно постоянен между сервером и клиентом, который загружает. Также использование процессора очень низкое, максимум 2% до 8%. Я попробовал с последней версией winscp 5.73 и с режимом sftp я получил 555kb/s и около 805kb/s максимум с режимом scp. Принимая во внимание, что если я запускаю вторичную параллельную передачу в Filezilla, я также получаю постоянные 1,3 МБ / с.
Так может ли задержка 180 мс на сервер быть математически ограничивающим фактором, о чем немного коснулись Мартин и Майкл? Или еще можно обвинить что-то еще, что я могу улучшить пропускную способность? Если нет, я был бы признателен, если бы кто-нибудь знал какой-либо другой (например, lftp, но хорошо работает в Windows) загрузчик с открытым исходным кодом, который безопасен и поддерживает сегментированную загрузку.
3 ответа
Есть три общих фактора, которые влияют на скорость передачи:
Пропускная способность - очевидный фактор, который, очевидно, не ваша проблема.
Сетевая задержка / задержка - SFTP - это пакетно-ориентированный протокол. При загрузке клиент SFTP отправляет запрос "чтения" серверу SFTP, ожидает ответа, добавляет возвращенные данные в локальный файл; и повторяется, до конца файла.
Даже если ваше соединение быстрое, если сервер находится далеко (или медленно), для возврата данных требуется время. Если клиент тратит это время на бесполезное ожидание, ваша скорость передачи будет низкой.
Большинство клиентов SFTP (включая FileZilla и WinSCP) преодолевают эту проблему, запрашивая большой кусок файла в каждом отдельном запросе "чтение" и отправляя (помещая в очередь) несколько запросов "чтение", не ожидая ответа на предыдущий. Например, WinSCP может запрашивать до 32 блоков по 32 КБ каждый, что в сумме составляет 1 МБ (это значения по умолчанию). Но если существует большое расхождение между пропускной способностью и задержкой в сети, даже этот 1 МБ может быть слишком мал для насыщения пропускной способности.
Базовый протокол TCP может страдать от аналогичной проблемы. Таким образом, дело не только в том, насколько эффективен сам SFTP-клиент, но и в том, насколько эффективен базовый уровень TCP.
Смотрите также Bandwidth-delay product в Википедии.
Я не думаю, что это ваша проблема, по крайней мере, если вы использовали последнюю версию WinSCP для тестов. В последних выпусках произошли некоторые улучшения, которые позволяют WinSCP использовать соединения с высокой задержкой так же эффективно, как FileZilla.
CPU - SFTP, будучи зашифрованным, интенсивно использует CPU. Если у вас относительно медленный процессор, по сравнению с большой пропускной способностью, передача может быть ограничена тем, что ваш процессор не может зашифровать (или расшифровать в случае загрузки) данные так быстро, как ваша сеть способна их передать.
Обычные SFTP-клиенты не могут распределять шифрование / дешифрование между ядрами ЦП, поэтому фактически емкость одного ядра ЦП ограничивает скорость передачи.
Используйте диспетчер задач Windows, чтобы увидеть, максимально ли используется одно из ядер во время передачи.
У меня тоже была эта проблема.
Я использовал диспетчер задач, чтобы установить высокий приоритет.
Теперь я получаю до 5 МБ / с
Я недавно попробовал в той же самой сети с Windows 10 и, возможно, более новую версию FileZilla, и я получил до 7 МБ / сек передачи с того же сервера! Затем я проверил с RSYNC внутри виртуальной машины и получил также 7 МБ / с. Теперь я "почти уверен", что проблема заключается в брандмауэре COMODO, который я установил в этой системе Windows 7.
Очевидно, что даже если вы "отключите" его, все, что он делает, - это не применяет правила, а замедляет сетевой стек. Я установил / реплицировал эту систему Windows 7 внутри виртуальной машины, и я постараюсь полностью "удалить" Comodo CIS Premium (антивирус + брандмауэр) и подтвердить здесь. Я должен также упомянуть на этой машине, что я также заметил, что время от времени прерывистая задержка пингует некоторые системы в моей сети, где все другие системы между ними были стабильны <1 мс. Таким образом, информация о продукте с задержкой пропускной способности очень хорошая, но в моем случае я смог получить filezilla и rsync на скорости 7 МБ / с (что в основном насыщает мою доступную пропускную способность) в другой установке, той же локальной и удаленной сети.