Каков наилучший способ передачи одного большого файла по высокоскоростному каналу глобальной сети с высокой задержкой?

Похоже, это связано с этим , но это несколько другое.

Существует связь WAN между двумя сайтами компании, и нам нужно передать один очень большой файл (дамп Oracle, ~ 160 ГБ).

У нас полная пропускная способность 100 Мбит / с (протестировано), но похоже, что одно TCP-соединение просто не может его максимально использовать из-за того, как работает TCP (ACK и т. Д.). Мы протестировали связь с iperf , и результаты значительно изменились при увеличении размера окна TCP: с базовыми настройками мы получаем пропускную способность ~ 5 Мбит / с, с большей WS мы можем получить до ~ 45 Мбит / с, но не более того. Задержка сети составляет около 10 мс.

Из любопытства мы запустили iperf, используя более одного соединения, и обнаружили, что при запуске четырех из них они действительно достигают скорости ~ 25 Мбит / с каждое, заполняя всю доступную полосу пропускания; поэтому ключ, по-видимому, заключается в выполнении нескольких одновременных передач.

С FTP все становится хуже: даже с оптимизированными настройками TCP (большой размер окна, максимальный MTU и т. Д.) Мы не можем получить более 20 Мбит / с за одну передачу. Мы одновременно пытались передавать по FTP несколько больших файлов, и на самом деле все стало намного лучше, чем при передаче одного; но затем виновником стал дисковый ввод-вывод, потому что очень скоро чтение и запись четырех больших файлов с одних и тех же узких мест диска; кроме того, мы, похоже, не можем разбить этот один большой файл на более мелкие, а затем объединить его, по крайней мере, в неприемлемое время (очевидно, мы не можем тратить время на сращивание / объединение файла, сравнимое со временем передавая это).

Идеальным решением здесь был бы многопоточный инструмент, который мог бы передавать различные фрагменты файла одновременно; вроде как одноранговые программы, такие как eMule или BitTorrent, уже делают, но из одного источника в один пункт назначения. В идеале этот инструмент позволил бы нам выбирать, сколько параллельных соединений использовать, и, конечно, оптимизировать дисковый ввод-вывод, чтобы не переходить (слишком) безумно между различными разделами файла.

Кто-нибудь знает такой инструмент?

Или кто-нибудь может предложить лучшее решение и / или то, что мы уже не пробовали?

PS Мы уже думали о резервном копировании на ленту / диск и физической отправке его по назначению; это было бы нашей крайней мерой, если бы WAN просто не сократил ее, но, как сказал А.С. Таненбаум, «никогда не стоит недооценивать пропускную способность универсала, полного лент, несущихся по шоссе».

Поиск «передачи файлов с высокой задержкой» вызывает много интересных хитов. Понятно, что это проблема, в которую вовлечены как сообщество CompSci, так и коммерческое сообщество.

Несколько коммерческих предложений, которые соответствуют всем требованиям:

• FileCatalyst имеет продукты, которые могут передавать данные по сетям с высокой задержкой, используя UDP или несколько потоков TCP. У них также есть много других функций (сжатие на лету, дельта-переносы и т. Д.).

• « Технология» передачи файлов FASP от Aspera, кажется, также отвечает вашим потребностям .

В мире открытого исходного кода проект uftp выглядит многообещающе. Вам особенно не нужны его возможности многоадресной рассылки, но основная идея заключается в уничтожении файла для получателей, получении NAK для пропущенных блоков в конце передачи, а затем в уничтожении блоков NAK (пена, полоскание, повтор). Похоже, это будет делать то, что вам нужно, поскольку ACK'ing (или NAK'ing) от приемника не будет до тех пор, пока передача файла не будет завершена один раз. Предполагая, что сеть просто скрыта и не с потерями, это может сделать то, что вам нужно.

Это действительно странное предложение. Настройте простой веб-сервер для размещения файла в своей сети (кстати, я предлагаю nginx), затем установите компьютер с firefox на другом конце и установите расширение DownThemAll .

Это ускоритель загрузки, который поддерживает чанкинг и повторную сборку.
Вы можете разбить каждую загрузку на 10 частей для повторной сборки, и это действительно делает вещи быстрее!

(предостережение: я никогда не пробовал его на чем-то настолько большом, как 160 ГБ, но он хорошо работает с ISO-файлами 20 ГБ)

Транспорт UDT, вероятно, является наиболее популярным транспортом для связи с высокой задержкой. Это приводит к их другому программному обеспечению, названному Сектором / Сферой, «Высокопроизводительная распределенная файловая система и механизм параллельной обработки данных», на который, возможно, стоит взглянуть.

Мой ответ немного запоздал, но я только нашел этот вопрос, когда искал fastp. Во время этого поиска я также обнаружил: http://tsunami-udp.sourceforge.net/ , «UDP-протокол цунами».

С их сайта:

Быстрый протокол передачи файлов в пользовательском пространстве, использующий данные управления TCP и UDP для передачи по очень высокоскоростным сетям большой дальности (≥ 1 Гбит / с и даже 10 GE), разработанный для обеспечения большей пропускной способности, чем это возможно при использовании TCP в тех же сетях. сетей.

Что касается скорости, на странице упоминается этот результат (используя ссылку между Хельсинки, Финляндия и Бонном, Германия, по ссылке 1 Гбит:

Рисунок 1 - международная передача через Интернет, в среднем 800 Мбит / с

Если вы хотите использовать ускоритель загрузки, взгляните на lftp, насколько я знаю, это единственный ускоритель загрузки, который может создавать рекурсивное зеркало.

Bbcp утилита от очень соответствующей страницы «Как передавать большие объемы данных через сеть» , кажется, самое простое решение.