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