Я загружаю с сервера, и загрузка достигает максимума 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, я получил 555 кб / с и около 805 кб / с макс. Тогда как если я начну вторичную параллельную передачу в Filezilla, я также получу для нее постоянные 1,3 МБ / с.
Так может ли задержка на сервер в 180 мс быть математически ограничивающим фактором, как Мартин и Майкл немного коснулись? Или может быть виноват что-то еще, что я могу улучшить пропускную способность? Если нет, я был бы признателен, если бы кто-нибудь знал какой-либо другой (например, lftp, но хорошо работает в Windows) загрузчик с открытым исходным кодом, который является безопасным и поддерживает сегментированную загрузку.
На скорость передачи влияют три общих фактора:
Пропускная способность - Очевидный фактор, видимо, это не твоя проблема.
Сетевая задержка / задержка - SFTP - это пакетно-ориентированный протокол. При загрузке клиент SFTP отправляет запрос «чтения» на сервер SFTP, ожидает ответа, добавляет возвращенные данные в локальный файл; и повторяется до конца файла.
Даже если ваше соединение быстрое, если сервер находится далеко (или медленный), для возврата данных требуется время. Если это время клиент будет ждать без толку, скорость вашего перевода будет низкой.
Большинство клиентов SFTP (включая FileZilla и WinSCP) преодолевают эту проблему, запрашивая большой кусок файла в каждом отдельном запросе на «чтение» и отправляя (ставя в очередь) несколько запросов на «чтение», не дожидаясь ответа на предыдущий. Например, WinSCP может одновременно запросить до 32 блоков по 32 КБ каждый, что составляет 1 МБ (это значения по умолчанию). Но если есть большое несоответствие между пропускной способностью и задержкой сети, даже этот 1 МБ может оказаться слишком маленьким, чтобы перегрузить полосу пропускания.
Базовый протокол TCP может столкнуться с аналогичной проблемой. Таким образом, дело не только в эффективности фактического клиента SFTP, но и в эффективности нижележащего уровня TCP.
Смотрите также Продукт задержки полосы пропускания в Википедии.
Я тоже не думаю, что это ваша проблема, по крайней мере, если вы использовали для тестов последнюю версию WinSCP. Там были некоторые улучшения в последних выпусках, которые позволяют WinSCP использовать соединения с высокой задержкой так же эффективно, как FileZilla.
ЦПУ - Зашифрованный SFTP интенсивно использует ЦП. Если у вас относительно медленный процессор по сравнению с большой пропускной способностью, передача может быть ограничена тем, что ваш процессор не может зашифровать (или расшифровать в случае загрузки) данные с такой скоростью, с какой ваша сеть способна их передавать.
Обычные клиенты SFTP не могут распределять шифрование / дешифрование между ядрами ЦП, поэтому на самом деле емкость одного ядра ЦП ограничивает скорость передачи.
Используйте диспетчер задач Windows, чтобы увидеть, используется ли одно из ядер максимально во время передачи.
Часть этого ответа взята из статьи WinSCP Скорость передачи файлов очень низкая. WinSCP не использует всю доступную пропускную способность. Как мне улучшить скорость передачи?
У меня тоже была эта проблема.
Я использовал диспетчер задач, чтобы установить высокий приоритет.
Теперь у меня до 5 Мбайт / с
Я недавно пробовал использовать ту же самую сеть с Windows 10 и, возможно, более новой версией filezilla, и я получил до 7 МБ / с передачи с того же сервера! Затем я протестировал RSYNC внутри виртуальной машины и также получил 7 МБ / с. Теперь я «почти уверен», что проблема заключается в брандмауэре COMODO, который я установил в этой системе Windows 7.
Очевидно, даже если вы "отключите" его, все, что он сделает, не будет обеспечивать соблюдение правил, а замедлит сетевой стек. Я также установил / реплицировал эту систему Windows 7 внутри виртуальной машины, и я попытаюсь полностью «удалить» Comodo cis premium (антивирус + брандмауэр) и подтвердить здесь. Я также должен упомянуть, что на этой машине я также заметил неустойчивые прерывистые пинги с задержкой для некоторых систем в моей сети, где все другие системы между ними были стабильными <1 мс. Таким образом, информация о продукте с задержкой полосы пропускания очень хороша, но в моем случае я смог получить filezilla и rsync со скоростью 7 МБ / с (что в основном насыщает мою доступную полосу пропускания) при другой установке, той же локальной и удаленной сети.