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

Это похоже на этот , но он несколько отличается.

Существует эта связь WAN между двумя сайтами компании, и нам нужно перенести один очень большой файл (Oracle dump, ~ 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. Таненбаум сказал: «Никогда не недооценивайте пропускную способность универсала, заполненного лентами, мчащимися по шоссе».

21 голос | спросил Massimo 11 FebruaryEurope/MoscowbThu, 11 Feb 2010 10:19:48 +0300000000amThu, 11 Feb 2010 10:19:48 +030010 2010, 10:19:48

5 ответов


15

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

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

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

  • fasp передача файлов «технология» из Aspera появляется чтобы соответствовать счету за то, что вы ищете, а также.

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

ответил Evan Anderson 11 FebruaryEurope/MoscowbThu, 11 Feb 2010 11:01:41 +0300000000amThu, 11 Feb 2010 11:01:41 +030010 2010, 11:01:41
9

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

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

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

ответил Tom O'Connor 11 FebruaryEurope/MoscowbThu, 11 Feb 2010 11:23:44 +0300000000amThu, 11 Feb 2010 11:23:44 +030010 2010, 11:23:44
7

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

ответил Steve-o 18 MaramFri, 18 Mar 2011 06:21:27 +03002011-03-18T06:21:27+03:0006 2011, 06:21:27
5

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

На своем веб-сайте:

  

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

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

  

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

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

ответил Jan van Haarst 25 J0000006Europe/Moscow 2010, 00:59:12
4

bbcp с самой актуальной страницы

ответил Robert Polson 27 J0000006Europe/Moscow 2012, 16:23:50

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132