Это похоже на вот этот, но это несколько иначе.
Существует WAN-соединение между двумя сайтами компании, и нам нужно передать один очень большой файл (дамп Oracle, ~ 160 ГБ).
У нас есть полная пропускная способность 100 Мбит / с (проверено), но похоже, что одно TCP-соединение просто не может максимизировать ее из-за того, как работает TCP (ACK и т. Д.). Мы проверили ссылку с iperf, и результаты резко меняются при увеличении размера окна TCP: с базовыми настройками мы получаем пропускную способность ~ 5 Мбит / с, с большим WS мы можем получить до ~ 45 Мбит / с, но не более того. Задержка в сети составляет около 10 мс.
Из любопытства мы запустили iperf, используя более одного соединения, и обнаружили, что при запуске четырех из них действительно достигается скорость ~ 25 Мбит / с каждое, заполняя всю доступную полосу пропускания; так что ключ, похоже, заключается в выполнении нескольких одновременных передач.
С FTP дела обстоят еще хуже: даже с оптимизированными настройками TCP (большой размер окна, максимальный MTU и т. Д.) Мы не можем получить более 20 Мбит / с за одну передачу. Мы пробовали одновременно передавать по FTP несколько больших файлов, и действительно все пошло намного лучше, чем при передаче одного файла; но затем виновником стал дисковый ввод-вывод, потому что чтение и запись четырех больших файлов с одного и того же диска очень скоро стали узкими местами; Кроме того, похоже, что мы не можем разделить этот один большой файл на более мелкие, а затем объединить его обратно, по крайней мере, не в приемлемое время (очевидно, мы не можем тратить время на сращивание / слияние файла, сравнимое со временем перенося его).
Идеальным решением здесь был бы многопоточный инструмент, который мог бы передавать различные фрагменты файла одновременно; вроде как одноранговые программы, такие как eMule или BitTorrent, уже делают, но из одного источника в один пункт назначения. В идеале этот инструмент позволил бы нам выбрать, сколько параллельных подключений использовать, и, конечно же, оптимизировать дисковый ввод-вывод, чтобы не переходить (слишком) безумно между различными разделами файла.
Кто-нибудь знает о таком средстве?
Или может кто-нибудь предложить лучшее решение и / или то, что мы еще не пробовали?
P.S. Мы уже думали о резервном копировании на ленту / диск и физической отправке по назначению; это было бы нашей крайней мерой, если бы WAN просто не справлялась, но, как отмечает A.S. Таненбаум сказал: «Никогда не недооценивайте пропускную способность универсала, набитого кассетами, мчащегося по шоссе».
Поиск по запросу "передача файлов с высокой задержкой" дает много интересных результатов. Ясно, что это проблема, над которой думают как сообщество CompSci, так и коммерческое сообщество.
Несколько коммерческих предложений, которые подходят под все требования:
FileCatalyst имеет продукты, которые могут передавать данные по сетям с высокой задержкой, используя UDP или несколько TCP-потоков. У них также есть много других функций (сжатие на лету, дельта-передача и т. Д.).
В быстро «Технология» передачи файлов от Aspera, похоже, также отвечает всем требованиям того, что вы ищете.
В мире открытого исходного кода uftp проект выглядит многообещающим. Вам не особенно нужны его возможности многоадресной рассылки, но основная идея передачи файла получателям, получения NAK за пропущенные блоки в конце передачи, а затем взрыва блоков NAK (вспенить, промыть, повторить) звучит так, как будто он сделает то, что вам нужно, поскольку приемник не отправляет ACK (или NAK) до тех пор, пока передача файла не будет завершена один раз. Предполагая, что сеть просто скрыта, а не с потерями, это тоже может сделать то, что вам нужно.
Это действительно странное предложение. Настройте простой веб-сервер для размещения файла в вашей сети (кстати, я предлагаю nginx), затем настройте компьютер с firefox на другом конце и установите DownThemAll расширение.
Это ускоритель загрузки, который поддерживает фрагменты и повторную сборку.
Вы можете разбить каждую загрузку на 10 частей для повторной сборки, и это действительно ускоряет работу!
(предостережение: я никогда не пробовал его ни на чем размером до 160 ГБ, но он хорошо работает с ISO-файлами 20 ГБ)
В UDT транспорт, вероятно, самый популярный транспорт для связи с высокой задержкой. Это приводит к их другому программному обеспечению, называемому Сектор / Сфера «Высокопроизводительная распределенная файловая система и механизм параллельной обработки данных», на который стоит взглянуть.
Мой ответ немного запоздал, но я только что нашел этот вопрос, когда искал fasp. Во время этого поиска я также нашел это: http://tsunami-udp.sourceforge.net/ , "Протокол UDP по цунами".
Со своего сайта:
Протокол быстрой передачи файлов в пользовательском пространстве, который использует управление TCP и данные UDP для передачи по очень высокоскоростным сетям на большие расстояния (≥ 1 Гбит / с и даже 10 GE), предназначенный для обеспечения большей пропускной способности, чем возможно с TCP в тех же сетях. сети.
Что касается скорости, на странице упоминается этот результат (используется ссылка между Хельсинки, Финляндия, и Бонном, Германия, по ссылке 1 Гбит:
Рисунок 1 - международная передача через Интернет, в среднем 800 Мбит / с.
Если вы хотите использовать ускоритель загрузки, обратите внимание на lftp, насколько мне известно, это единственный ускоритель загрузки, который может выполнять рекурсивное зеркало.
В BBCP утилита с очень актуальной страницы 'Как передавать большие объемы данных по сети' кажется самым простым решением.