Итак, мне недавно потребовалось получить через Интернет большой файл из одного из наших зарубежных офисов. Оба офиса имеют 50-мегабитные оптоволоконные линии в обоих направлениях, но время приема-передачи ужасно и варьируется от 450 мс в хороший день до 750 мс в плохой.
Первоначально я пытался вытащить файл через VPN-соединение, но после нескольких неудачных передач (smb действительно отстой по медленным ссылкам) и максимальной скорости около 128 кбит / с быстрый Google показал, что я столкнулся с проблемами масштабирования окна TCP в Windows.
С тех пор я протолкнул файл через коммерческую службу типа частного облака, которая доставила файл сюда быстрее, поэтому нижеследующее больше из любопытства, чем что-либо еще.
К удовольствию добавляется то, что доступ в Интернет на обоих концах осуществляется через HTTP-прокси. Однако у меня есть права администратора на машинах с обеих сторон.
Как бы вы увеличили скорость?
Вещи, которые я пробовал:
1) Простой SFTP между двумя виртуальными машинами Linux, используя штопор для пробивания через прокси-сервер http и третьего посредника для соединения двух концов вместе. Достигнутая скорость: около 600 кбит / с.
2) SFTP, но с использованием OpenSSH с исправлением HPN-SSH. Штопор и промежуточная конфигурация такие же, как 1). Небольшое улучшение скорости.
3) То же, что и 2, но с использованием LFTP с pget -c -n 10 чтобы разбить перевод на куски. На данный момент это лучший результат, скорость 3,5 Мбит / с ...
Все улучшения приветствуются.
В наши дни я обращаюсь к передачам по каналам на большие расстояния и с большей задержкой, оборачивая 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/
У меня была такая же проблема на $ lastjob.
Оставаясь исключительно в рамках собственной инфраструктуры, я никогда не находил лучшего решения, чем LFTP.
Если вы можете оправдать затраты, вы можете получить устройства, ускоряющие WAN. По сути, они прозрачно превращают ваши запросы в гораздо большие блоки, тем самым значительно сокращая разговоры между двумя сайтами. Riverbed, вероятно, самый известный вариант, но у IIRC есть также модуль для маршрутизаторов Juniper для этого. На данный момент я не знаю ни одной опции FLOSS.
На самом деле я нашел, что лучшим вариантом был Dropbox и др., Но это может быть неприемлемо для вас.