Почему скорость передачи файлов SFTP в FileZilla ограничена 1,3 МиБ/с вместо использования доступной пропускной способности? rsync и WinSCP даже медленнее.

Я скачиваю с сервера, и скорость загрузки максимальна на уровне 1.3MiB/с с помощью FileZilla, но я могу запускать параллельные загрузки, и они тоже будут загружаться со скоростью 1.3MiB/с. Так почему же я не могу скачать один файл быстрее 1.3MB/s и приблизиться к насыщению доступной ширины канала (~6+MB/s)?

Я знаю, что могу использовать другой SFTP-клиент, поддерживающий сегментированные загрузки, например lftp, знаю о других хороших вариантах, которые являются открытым исходным кодом?

Но я все равно хочу понять, что ограничивает загрузку одного файла до 1.3MB/s, является ли это какой-то технической ограниченностью с TCP и буферами и т.д. или проблемой конфигурации? Я проверил и точно не включено ограничение трафика для FileZilla.

Кроме того, я пробовал rsync, и это было хуже, чем FileZilla/SFTP. Я также пробовал WinSCP, и он был самым медленным, независимо от метода SCP/SFTP. Таким образом, с постоянной передачей 1.3MB/s FileZilla довольно хорош по сравнению с другими методами передачи.

Если у кого-то есть хорошее объяснение, почему скорость передачи достигает 1.3MB/s, я был бы очень признателен, и если возможно увеличить это без использования сегментированных загрузок. Сервер работает на OpenSSH 6.7p1 (Debian), клиент – FileZilla на Windows.

ОБНОВЛЕНИЕ: В ответ на информацию Мартина (см. его ответ ниже) добавляю, что пинг составляет 180 мс до 190 мс, довольно стабильно между сервером и клиентом, который загружает. Также загрузка ЦП очень низкая, максимум 2% до 8%. Я попробовал последнюю версию winscp 5.73 и в режиме sftp получил 555 кБ/с и примерно 805 кБ/с максимум в режиме scp. В то время как, если я запускаю вторичную параллельную передачу в Filezilla, я получаю постоянные 1.3MiB/s для нее тоже.

Так может ли задержка в 180 мс до сервера быть математически ограничивающим фактором, как упомянули Мартин и Майкл? Или может быть еще что-то, за что можно было бы упрекнуть, чтобы я мог улучшить пропускную способность? Если нет, я был бы признателен, если кто-то знает другой (например, lftp, но хорошо работающий на Windows) открытый загрузчик, который безопасен и поддерживает сегментированные загрузки.

Существует три основных фактора, влияющих на скорость передачи:

• Ширина канала – Очевидный фактор, который, по всей видимости, не является вашей проблемой.

• Задержка сети/латентность – SFTP является пакетно-ориентированным протоколом. При загрузке SFTP-клиент отправляет запрос “чтения” на SFTP-сервер, ждет ответа, добавляет возвращенные данные в локальный файл и повторяет до конца файла.

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

  Большинство SFTP-клиентов (включая FileZilla и WinSCP) преодолевают эту проблему, запрашивая большой кусок файла в каждом отдельном запросе “чтения” и отправляя (вставляя в очередь) несколько запросов “чтения”, не дожидаясь ответа на предыдущий. Например, WinSCP может запрашивать до 32 кусочков по 32 КБ каждый сразу, в общей сложности 1 МБ (это значения по умолчанию). Но если существует большая разница между шириной канала и задержкой сети, даже эти 1 МБ могут быть слишком маленькими, чтобы насытить ширину канала.

  Подлежащий протокол TCP может столкнуться с аналогичной проблемой. Поэтому это не только то, насколько эффективен сам SFTP-клиент, но и насколько эффективен подлежащий уровень TCP.

  Смотрите также продукт ширины канала и задержки на Wikipedia.

  Я не думаю, что это ваша проблема тоже, по крайней мере, если вы использовали последнюю версию WinSCP для тестов. В недавних выпусках были некоторые улучшения, которые позволяют WinSCP эффективно использовать соединения с высокой латентностью, как и FileZilla.

• ЦП – SFTP, будучи зашифрованным, является ресурсоемким для ЦП. Если у вас относительно медленный ЦП по сравнению с большой шириной канала, скорость передачи может быть ограничена тем, что ваш ЦП не может зашифровать (или расшифровать в случае загрузки) данные так быстро, как ваша сеть способна их передавать.

  Обычные SFTP-клиенты не могут распределить шифрование/расшифровку между ядрами ЦП, поэтому фактически это является емкостью одного ядра ЦП, которая ограничивает скорость передачи.

  Используйте Диспетчер задач Windows, чтобы увидеть, если одно из ядер используется на максимум во время передачи.

Часть этого ответа взята из статьи WinSCP Скорость передачи файла очень низкая. WinSCP не использует всю доступную ширину канала. Как я могу улучшить скорость передачи?

У меня была такая же проблема.

Я использовал диспетчер задач, чтобы установить приоритет на высокий.

Теперь я получаю до 5 MiB/s

Я недавно пробовал на той же самой сети с Windows 10 и, возможно, более новой версией FileZilla, и получил до 7MB/сек. загрузки с того же сервера! Затем я протестировал с RSYNC внутри виртуальной машины и тоже получил 7MB/сек. Я почти уверен, что проблема заключается в файрволе COMODO, установленном на этой системе Windows 7.

Очевидно, что даже если вы “отключаете” его, все, что он делает, это не применять правила, но он замедляет сетевой стек. Я установил/воссоздал эту систему Windows 7 внутри виртуальной машины тоже, и я попробую полностью “удалить” Comodo cis premium (антивирус + файрвол) и подтвердить здесь. Я также должен упомянуть, что на этой машине я также заметил нестабильные периодические задержки пинга к некоторым системам в своей сети, в то время как все остальные системы между ними были стабильными <1ms. Поэтому информация о продукте ширины канала и задержки очень хороша, но в моем случае мне удалось получить FileZilla и rsync оба на 7MB/s (что по сути насыщает мою доступную ширину канала) на другой установке, в той же сети локальной и удаленной.

Я сейчас загружаю и получаю около 2.3MB/s.