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

Я пытаюсь передать набор больших файлов по всему миру, используя SFTP, но я обнаружил, что мой международный партнер не может получить скорость загрузки выше ~ 50k, несмотря на очень хорошие соединения с обеих сторон. Мы можем получить несколько подключений, загружаемых с такой скоростью (а не с пропускной способностью?), Но ни одна загрузка не улучшается по скорости, что является проблемой, так как многие файлы имеют размер несколько ГБ.

SFTP размещается с использованием стандартной системы Apple OSX «Remote Login» SFTP.

Есть ли способ улучшить скорость загрузки или другой хост SFTP, который бы помог? Мне не ясно, является ли это проблемой конфигурации или внутренним ограничением протокола.

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

С клиентом OpenSSHsftp (который вы используете) вы можете использовать:

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

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

sftp -R 128 -B 65536 user@host

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

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

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

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

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

От man sftp:

-C Включает сжатие (через флаг ssh -C).

И из man ssh:

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

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

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

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

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

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

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

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

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

Ускорить передачу SFTP

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

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

(Вы упоминаете «высокую задержку» в заголовке вопроса, но не в тексте. Измеряли ли вы реальную задержку и каковы результаты?)

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

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

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

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

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

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

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

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