Почему передача файлов FileZilla SFTP макс. ограничивается в 1.3MiB/sec вместо того, чтобы насыщать доступную пропускную способность? rsync и WinSCP еще медленнее
Я загружаю с сервера, и загрузки истратили в 1.3MiB/second с FileZilla, но я могу запустить параллельные загрузки, и они загрузят в 1.3MiB/second также. Итак, почему я не могу загрузить всего один файл в быстрее, чем 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.
ОБНОВЛЕНИЕ: В ответ на информацию Martin (см. его ответ ниже) я добавляю, что ping составляет 180 мс к 190 мс, довольно постоянным между сервером и клиентом, который загружает. Также использование CPU является очень низким, 2% к 8% максимум. Я попробовал последней версией winscp 5.73 и sftp режимом, я получил 555kb/s и о 805kb/s макс. с scp режимом. Принимая во внимание, что, если я запускаю вторичную параллельную передачу в Filezilla, я получаю постоянный 1.3MiB/s для него также.
Таким образом, 180 мс могли задержаться к серверу быть математически ограничивающим фактором как Martin и Michael, тронутым немного? Или что-то еще могло там все еще быть для обвинения таким образом, что я могу улучшить пропускную способность? В противном случае я ценил бы, если кто-либо знает кого-либо другого (как lftp, но работает хорошо в Windows) загрузчик, с открытым исходным кодом, который безопасен и поддерживает сегментированную загрузку.
- Есть три общих фактора, которые влияют на скорость передачи:
Полоса пропускания - Очевидный фактор, который, очевидно, не является вашей проблемой.
Задержка/латентность сети - SFTP является пакетно-ориентированным протоколом. При загрузке SFTP-клиент посылает SFTP-серверу запрос на "чтение", ждет ответа, добавляет возвращенные данные в локальный файл; и повторяет до конца файла.
Даже если ваше соединение быстрое, если сервер находится далеко (или медленно), требуется время, чтобы данные вернулись обратно. Если клиент тратит это время бесполезно в ожидании, ваша скорость передачи будет низкой.
Большинство SFTP клиентов (включая FileZilla и WinSCP) преодолевают проблему, как запрашивая большой кусок файла в каждом отдельном "читаемом" запросе, так и посылая (ставя в очередь) несколько "читаемых" запросов, не дожидаясь ответа на предыдущий. Например, WinSCP может запросить до 32 блоков по 32 КБ каждый сразу, всего 1 МБ (по умолчанию). Но если есть большая разница между полосой пропускания и задержкой сети, даже эта 1 MB может быть слишком мала, чтобы насытить полосу пропускания.
Основной TCP протокол может страдать аналогичной проблемой. Таким образом, это не только то, как эффективен реальный SFTP клиент, но и то, как эффективен лежащий в основе TCP слой.
Смотрите также Продукт задержки полосы пропускания в Википедии.
Я не думаю, что это тоже ваша проблема, по крайней мере, если вы использовали последнюю версию WinSCP для тестов. В последних релизах были некоторые улучшения, которые позволяют WinSCP использовать высоколатентные соединения так же эффективно, как и FileZilla.
CPU - SFTP, будучи зашифрованным, интенсивно использует процессор. Если у вас относительно медленный процессор, по сравнению с большой пропускной способностью, передача может быть ограничена тем, что ваш процессор не в состоянии зашифровать (или расшифровать в случае загрузки) данные настолько быстро, насколько ваша сеть способна их передать.
Обычные клиенты SFTP не могут распределить шифрование/дешифрование между ядрами процессора, поэтому на самом деле это емкость одного ядра процессора, которая ограничивает скорость передачи.
Воспользуйтесь диспетчером задач Windows, чтобы посмотреть, используется ли одно из ядер по максимуму во время передачи.
У меня тоже была эта проблема.
Я использовал диспетчер задач, чтобы установить высокий приоритет.
Теперь я получаю до 5 МБ / с
Я недавно пробовал использовать ту же самую сеть с Windows 10 и, возможно, более новой версией filezilla, и я получил до 7 МБ / с передачи с того же сервера! Затем я протестировал RSYNC внутри виртуальной машины и также получил 7 МБ / с.Теперь я «почти уверен», что проблема заключается в брандмауэре COMODO, который я установил в этой системе Windows 7.
Очевидно, даже если вы его «отключите», все, что он сделает, не будет обеспечивать соблюдение правил, а замедлит сетевой стек. Я также установил / реплицировал эту систему Windows 7 внутри виртуальной машины, и я попытаюсь полностью «удалить» Comodo cis premium (антивирус + брандмауэр) и подтвердить здесь. Я также должен упомянуть, что на этой машине я также заметил неустойчивые прерывистые эхо-запросы с задержкой для некоторых систем в моей сети, где все другие системы между ними были стабильными <1 мс. Таким образом, информация о продукте с задержкой полосы пропускания очень хороша, но в моем случае я смог получить как filezilla, так и rsync со скоростью 7 МБ / с (что в основном насыщает мою доступную полосу пропускания) при другой установке, той же локальной и удаленной сети.