Ускорить загрузку SFTP в сети с высокой задержкой?

С участием OpenSSH sftp клиент (который вы, кажется, используете), вы можете использовать:

• -R переключатель для увеличения длины очереди запросов (по умолчанию 64)
• -B переключатель для увеличения размера запроса на чтение / запись (по умолчанию 32 КБ)

Для начала попробуйте удвоить оба:

sftp -R 128 -B 65536 user@host

Наверное, не имеет большого значения, какие из них вы увеличиваете.

Увеличение любого из них должно помочь насыщать ваше соединение с высокой задержкой. С указанными выше настройками он будет поддерживать поток данных объемом 8 МБ в конвейере в любое время (128 * 64 КБ = 8 МБ).

Обратите внимание, что это помогает только при передаче больших файлов. Это не повлияет на передачу большого количества небольших файлов.

Для получения дополнительной информации и обсуждения других (GUI) клиентов SFTP см. Раздел «Сетевая задержка / задержка» моего ответа на Почему максимальная скорость передачи файлов SFTP в FileZilla ограничена 1,3 МБ / с вместо того, чтобы загружать доступную полосу пропускания? rsync и WinSCP еще медленнее.

Я пытаюсь передать набор больших файлов на международном уровне с помощью SFTP

Это еще не упоминалось в качестве ответа, но при передаче нескольких файлов по ссылке с высокой задержкой есть одно действительно простое решение для повышения производительности:

Параллельная передача нескольких файлов.

И это является решение, которое вы даже упомянули в своем вопросе. Используй это.

По сути, протокол TCP не очень хорошо обрабатывает соединения с большим продуктом задержки полосы пропускания - одно соединение не может обеспечить одновременное перемещение достаточного количества данных. Видеть https://en.wikipedia.org/wiki/TCP_tuning

поскольку каждое соединение ограничен протоколом TCP, просто используйте больше соединений.

(Вы упоминаете "высокую задержку" в заголовке вопроса, но не в основном тексте. Вы измерили фактическую задержку и каковы результаты?)

Есть патч для OpenSSH, который явно увеличивает пропускную способность сетевого канала с высокой задержкой: HPN-SSH: (курсив мой)

SCP и лежащая в основе реализация протокола SSH2 в OpenSSH - это производительность сети, ограниченная статически определенными внутренними буферами управления потоком. Эти буферы часто становятся узким местом для пропускной способности сети SCP, особенно на длинных и высокоскоростных сетевых каналах. Изменение кода ssh, позволяющее определять буферы во время выполнения, устраняет это узкое место. Мы создали патч, который устранит узкие места в OpenSSH и полностью совместим с другими серверами и клиентами. Кроме того, клиенты HPN смогут быстрее загружать файлы с серверов, отличных от HPN, а серверы HPN смогут быстрее получать загрузки от клиентов, не являющихся HPN.

Итак, попробуйте скомпилировать и использовать HPN-SSH на принимающей стороне и посмотрите, улучшит ли это вашу скорость передачи.

Ускорьте переводы sftp

Предполагая, что ваши проблемы связаны с настройкой сети и / или регулированием TCP-соединения, взгляните на sftp с использованием подсистемы зеркала lftp

Настройка сети на каждом конце - это гораздо более обширная тема, и она потребует много времени назад и вперед, вынуждая эту тему выйти за рамки ServerFault. Для отдельных соединений сжатие, указанное Iwaseatenbyagrue может помочь в любом случае. Это предполагает, что удаленный конец разрешает сжатие.

Вы можете попробовать включить сжатие и посмотреть, поможет ли это.

Из man sftp:

-C Включает сжатие (с помощью флага ssh -C).

И из man ssh:

-C Запрашивает сжатие всех данных (включая stdin, stdout, stderr и данные для перенаправленных соединений X11, TCP и UNIX-домена). Алгоритм сжатия тот же, что и в gzip (1), а «уровень» можно контролировать с помощью параметра CompressionLevel для версии протокола 1. Сжатие желательно на модемных линиях и других медленных соединениях, но только замедлит работу в быстрых сетях. . Значение по умолчанию может быть установлено для каждого хоста в файлах конфигурации; см. параметр «Сжатие».

Скорее звучит так, как будто скорость соединения может быть ограничена в какой-то момент на своем пути (или, скорее, это кажется мне самым простым объяснением ваших 50 КБ / с на соединение, но возможно несколько таких подключений), хотя это может быть не плохая идея убедиться, что диски с обеих сторон не имеют значения.

Вы также можете запустить быстрый pcap, чтобы увидеть, есть ли какие-либо `` очевидные '' проблемы (например, большое количество повторных передач), но если у вас нет уверенности, что вы сможете решить эту проблему, я, вероятно, просто посмотрю, будет ли включение сжатия Помогите.

Не уверен, что это вариант для вас, но пробовали ли вы извлекать или отправлять данные на международный сайт? А также в разное время, чтобы увидеть, не проблема с конкуренцией за сетевые ресурсы?

Мы можем получить несколько подключений, загружаемых на этой скорости (а не с пропускной способностью?)

Звучит как проблема с конфигурацией - либо намеренно (как способ увеличения продаж без дополнительных мер), либо случайно (например, сломанный масштабирование окна или чрезмерный контроль трафика). Хотя вы можете распараллеливать передачи, вы ничего не сказали нам о том, что находится на другом конце соединения, или о том, стоит ли разработать несколько простых сценариев для обработки сегментирования / восстановления файлов.

Настройка размера очереди и сжатия вряд ли окажет какое-либо существенное влияние, если только причина не очень плохо написанное программное обеспечение (и openSSH не относится к этой категории - не имеет большого смысла использовать openssh с более длинной очередью запросов / большим размером блока, если только задержка не превышает 250 мсек. Вы можете попробовать с разными клиентами из разных мест, чтобы исключить проблему с сервер.

Мой первый звонок - определить, какой провайдер виноват в проблеме, попросить их исправить проблему или переключиться на другого провайдера.