Повышение скорости передачи больших файлов по ссылке с высокой задержкой

Итак, недавно у меня возникла необходимость вытащить большой файл через Интернет из одного из наших офисов за рубежом. Оба офиса имеют 50-битные оптоволоконные каналы в обоих направлениях, но время приема-передачи ужасно и варьируется от 450 мс в хороший день и до 750 мс в дерьмовый день.

Первоначально я пытался перетащить файл через VPN-соединение, но после нескольких неудачных передач (smb действительно сосет медленные ссылки) и максимальной скорости около 128 Кбит / с быстрый Google показал, что я столкнулся с проблемами масштабирования окон Windows TCP.

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

В дополнение к этому, доступ в Интернет на обоих концах осуществляется через http-прокси. Однако у меня есть права администратора на машинах с обоих концов.

Как бы вы пошли на улучшение скорости?

Вещи, которые я пробовал:

1) Простой SFTP между двумя виртуальными машинами Linux, используя штопор для пробивки через http-прокси и третьего посредника для соединения двух концов вместе. Достигнутая скорость: около 600 кбит / с.

2) SFTP, но с использованием OpenSSH, пропатченного HPN-SSH. Штопор и промежуточный конфиг такой же, как 1). Небольшое улучшение скорости.

3) Согласно пункту 2, но с использованием LFTP, pget -c -n 10чтобы разбить передачу на куски. Пока это лучший, видя 3.5MBps ...

Все улучшения приветствуются.

В настоящее время я обращаюсь к передачам по междугородним и высокоскоростным каналам, оборачивая rsync через UDP, используя UDR в качестве транспорта. UDR использует UDT , который описывается как:

UDT - это надежный протокол передачи данных на уровне приложений на основе UDP для распределенных приложений с интенсивным использованием данных в глобальных высокоскоростных сетях. UDT использует UDP для передачи больших объемов данных с помощью собственных механизмов контроля надежности и контроля перегрузки. Новый протокол может передавать данные с гораздо большей скоростью, чем TCP. UDT также является сильно конфигурируемой средой, которая может приспосабливать различные алгоритмы управления перегрузкой.

Это отключает шифрование по умолчанию, что было главным, что мне было нужно, когда я исправлял HPN-SSH , но подход UDP очень помог. Основным преимуществом решения UDR / UDP является то, что функциональность команд не сильно меняется. Вы заканчиваете тем, что добавляете команду rsync с помощью udr.

udr rsync -avP --stats --delete --inplace /data/ mir1:/data/

Также см .: Возможность оптимизации WAN для трафика SSH.

У меня была такая же проблема на $ lastjob.

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

Если вы можете оправдать расходы, вы можете получить устройства, которые ускоряют WAN. По сути, они прозрачно превращают ваши запросы в гораздо более крупные куски, тем самым значительно уменьшая общительность между двумя сайтами. Riverbed, вероятно, является наиболее известным вариантом, но у IIRC есть также модуль для маршрутизаторов Juniper. Я не знаю ни одного варианта FLOSS на данный момент.

На самом деле я обнаружил, что лучшим вариантом был Dropbox et al, но это может быть неприемлемо для вас.