IBM
Компания
176,74
рейтинг
11 января в 10:33

Разработка → Высокоскоростной протокол передачи файлов – Aspera FASP



В настоящее время, в век популярности Интернет и разнообразного контента, в том числе медийного, размер которого в HD-качестве может занимать несколько Гигабайт, наиболее остро встала проблема скоростной передачи файлов по сети. В качестве примера можно рассмотреть работу новостной телестудии, где репортер, находясь на другом континенте, должен быстро передать снятый в высоком качестве репортаж в центральную студию для обработки и запуска в эфир. Понятно, что здесь скорость передачи играет ключевую роль, поскольку новость уже не будет новостью, если она появится через пару дней.

Или, например, в случае, когда плавучая бурильная установка, на которой есть только спутниковый канал, должна передать куб геофизических данных бурения скважины для интерпретации в высокопроизводительные вычислительные центры, каждый день задержки может привести к убыткам.

Первое, что приходит на ум — это воспользоваться протоколом FTP. И, действительно, FTP, работающий на базе Transmission Control Protocol (TCP), будет отлично справляться, если потребуется передавать файлы на небольшие расстояния или по “хорошей” сети. Но в приведенных выше примерах скорость протокола FTP будет очень низкой из-за неэффективной работы TCP на сетях с задержками и потерей пакетов. Увеличение канала при этом не решает проблему, и дорогой канал остается не утилизированным.

У протокола Aspera FASP нет недостатков TCP, и он максимально утилизирует любой доступный канал, увеличивая скорость передачи данных по сравнению с FTP в сотни раз. До появления Aspera, данные записывались на жесткие диски или ленты и передавались курьерами, что не очень быстро, кроме того существовал риск потери данных.

FASP – это высокоскоростной протокол для передачи файлов с гарантированной доставкой, разработанный и запатентованный компанией Aspera (www.asperasoft.com). В 2014 году корпорация IBM покупает компанию Aspera и решение попадает в облачное подразделение IBM.

Аббревиатура FASP расшифровывается как fast, adaptive, secure protocol, что в переводе с английского означает быстрый, адаптивный и безопасный протокол. Быстрый, потому что эффективно использует всю доступную полосу пропускания; адаптивный, потому что адаптируется под состояние сети и при этом “дружественен” для другого трафика; а безопасный, потому что использует шифрование как при передаче, так и в “состоянии покоя”.

Для того, чтобы понять преимущества FASP, давайте вспомним как работает протокол TCP. В 70-х годах прошлого века перед учеными поставили задачу разработать протокол, который сможет перенести ядерный удар. Требовалось создать протокол, который смог бы безопасно передавать данные. Поэтому при создании TCP основные усилия были направлены на создание механизма именно надежной, а не скоростной передачи. В те годы не было ни мобильных, ни спутниковых сетей, а единственный трансатлантический канал из США в Европу имел скорость 64 Кбит/сек, что показывает состояние технологии на тот период. TCP был разработан так, что скорость передачи обратно пропорциональна расстоянию между конечными точками. Кроме того, в случае потери пакетов TCP считает, что канал перегружен, и самостоятельно уменьшает скорость передачи. Производительность TCP снижается с ростом расстояния передачи и из-за низкого качества сети. Чем больше расстояние, тем больше задержка, и тем ниже скорость передачи. Задержку обычно измеряют величиной Round-Trip Time (RTT). Это время, которое потребуется на отправку пакета и получение подтверждения от получателя. Задержка возникает из-за законов физики, ограничивающих скорость света или электромагнитного сигнала. Например, задержка при передаче по спутниковым сетям может достигать 800 мс. Более того, при передаче на большие расстояния по глобальной сети Интернет (WAN) пакет должен пройти через большое количество маршрутизаторов прежде, чем его получит получатель. Маршрутизатору требуется время на обработку пакета, а если он настроен неправильно или перегружен, может произойти потеря пакета. Чем выше количество потерянных пакетов, тем более затратной по времени становится передача. На рисунке 1 показано, что TCP имеет хорошую производительность в локальных сетях (LAN) относительно доступной пропускной способности сети, но, при этом, чем больше RTT и потеря пакетов, тем ниже будет производительность передачи.

Также, производительность протокола TCP не растет с увеличением канала. Другими словами, если у вас медленная передача на канале в 10 Мбит/c, нет никаких гарантий, что при увеличении канала до 1 Гбит/c скорость вырастет. Конечно, если необходимо передать файл на соседнюю улицу, рост производительности будет заметен, но, если стоит задача передать данные на большие расстояния, то увеличение канала до 1 Гбит/c, скорее всего, мало чем поможет.


Рисунок 1 Производительность TCP

TCP — сессионный протокол, т.е. при передаче он устанавливает соединение, как видно на рисунке 2. все отправленные пакеты получают подтверждение в виде ACK-пакетов. Задержка (RTT) составляет разницу во времени между отправкой пакета и получением подтверждения (ACK).


Рисунок 2 Обмен пакетами TCP

Количество пакетов, которые может отправить TCP в момент времени определяется механизмом под названием окно TCP (TCP Sliding Window). Окно TCP управляется алгоритмом предотвращения перегрузки AIMD (Adaptive Increase Multiplicative Decrease) и контролем передачи (Flow Control), регулируя скорость отправки пакетов. Благодаря этому TCP может «быть уверен» в том, что пакеты отправляются не быстрее, чем их может принять получатель. Как показано на рисунке 3, благодаря окну TCP, отправитель может одновременно высылать несколько пакетов, но, при этом, если не будет получено подтверждение, TCP заблокирует передачу любых последующих пакетов.


Рисунок 3 TCP Sliding Window

В случае обнаружения потери пакета/подтверждения, отправитель, используя AIMD алгоритм, уменьшает размер окна TCP вдвое или до нуля. Ситуация, когда отправитель не дожидается подтверждения доставки и уменьшает окно передачи, наиболее часто проявляется при передаче на большие расстояния, т.е. в сетях с большим RTT. При этом, если произойдет еще и потеря пакетов, скорость передачи уменьшится практически до нуля. Если представить скорость передачи протокола TCP в виде графика, получится так называемая “пилообразная” функция (sawtooth pattern).


Рисунок 4 TCP AIMD “Sawtooth” Pattern

Как видно на рисунке 4, по причине использования в TCP алгоритма предотвращения перегрузок AIMD скорость передачи в TCP возрастает до тех пор, пока не случается “перегрузка”, в результате чего скорость резко падает, и “пилообразный” процесс постоянно повторяется, не давая протоколу TCP полностью утилизировать доступный канал. В интернете есть инструменты, которые позволяют оценить эффективную скорость передачи по TCP (http://asperasoft.com/performance_calculator/). Например, на сети с пропускной способностью 100 Мбит/с, RTT=150 мс и потерей пакетов 1,5% скорость передачи будет меньше 1 Мбит/c, при этом не важно какой будет канал: 100 Мбит/с или 1 Гбит/сек, т.к. скорость передачи в TCP зависит от величины RTT и потери пакетов.

Протокол FASP


Транспортный протокол Aspera FASP, в отличие от TCP, отлично работает в любой сети, обеспечивая гарантированную доставку. Этот протокол эффективно передает данные неограниченного объёма по глобальной сети Интернет, спутниковым и мобильным каналам, и при этом не снижает свой эффективности в сетях с повышенным RTT и потерей пакетов. Протокол обеспечивает максимальную скорость и механизм предотвращения перегрузки, а также контроль политик передачи, безопасность и надежность.


Рисунок 5 Производительность FASP

При работе в локальной сети разница между TCP и FASP не существенна, но, как только в сети между двумя конечными точками увеличивается RTT и потеря пакетов, производительность FASP становится существенно лучше, (рисунок 5). FASP передает данные быстрее, максимальным образом используя доступный канал передачи. При этом нет никаких ограничений в теоретической максимальной скорости передачи, которая скорее может быть ограничена аппаратными ресурсами, например, производительностью дисковой подсистемы. Передача по протоколу TCP показывает “пилообразный” график, чего вы никогда не увидите в FASP, где скорость передачи выйдет на заданный уровень (Target Rate) и будет его придерживаться вне зависимости от наличия потерянных пакетов. Конечно, потерянные данные будут переданы заново, но это не окажет влияния на производительность передачи. Используя Aspera FASP можно гарантировать предсказуемое время передачи независимо от качества сети.

Протокол FASP работает на базе протокола UDP (User Datagram Protocol) на транспортном уровне модели OSI, а, так как UDP не гарантирует доставку, то алгоритмы предотвращения перегрузки и управление передачей реализованы на прикладном уровне.

FASP не использует механизм окна TCP и не зависит от расстояния передачи. Передача начинается на определённой скорости и отправляет данные на скорости, рассчитанной математическим алгоритмом. Протокол FASP использует механизм негативных подтверждений (NACK); это означает, что, при наличии потерянного пакета, получатель сообщит, что не получил этот пакет, при этом отправитель будет продолжать передачу. FASP, в отличие от TCP, не ожидает получения подтверждения, прежде чем выслать следующие данные. Поскольку для передачи файлов не важно, в какой последовательности придут пакеты, передача данных не останавливается при потерях пакетов, как это происходит в TCP. Данные эффективно продолжают передаваться на высокой скорости. Отправитель заново вышлет лишь потерянный пакет, а не все окно пакетов, как в TCP, не останавливая при этом текущую передачу. Использование протокола FASP позволяет свести к минимуму передачу служебной информации (overhead), позволяя получить цифру меньше, чем 0,1% при 30%-й потере пакетов.


Рисунок 6 Утилита сравнения производительности Aspera и TCP

На рисунке 6 приведено сравнение скорости передачи файла, размером в 100 Гбайт в сети с пропускной способностью 100 Мбит/c, RTT равным 150 мс, и 2%-й потерей пакетов. Как видно, эффективная скорость передачи файлов равна 98 Мбит/c при использовании Aspera FASP, и 0,7 Мбит/c при использовании протокола TCP.

Отказ от использования избыточных алгоритмов контроля скорости и надежности протокола TCP, позволяет протоколу FASP не снижать скорость передачи при потере пакетов. Потерянные данные отсылаются на доступной для канала или заданной скорости, без отправления повторных данных.

Доступная полоса пропускания канала определяется на основе механизма управления скоростью FASP. Адаптированный механизм управления скоростью в протоколе FASP на постоянной основе отсылает пробные пакеты, с помощью которых измеряется так называемая задержка нахождения в очереди (queueing delay). Т.е., когда пакет попадает на маршрутизатор, его нужно обработать и переслать. Т.к. маршрутизатор может обработать один пакет в единицу времени, то, при получении пакета раньше, чем его сможет обработать маршрутизатор, пакет помещается в очередь. Таким образом, формируется задержка нахождения в очереди. FASP использует измеренные значения задержки нахождения в очереди как главный индикатор перегрузки сети (или дисковой подсистемы). Сеть постоянно опрашивается, скорость передачи увеличивается при уменьшении значения задержки нахождения в очереди ниже целевого значения (показывает, что канал не полностью утилизирован и необходимо поднять скорость) и уменьшается при увеличении размера задержки нахождения в очереди выше заданного уровня (показывает, что канал полностью утилизирован и возможна перегрузка). Постоянно отсылая в сеть пробные пакеты, FASP получает точные значения задержки в очереди на всем маршруте передачи. При увеличении задержки в очереди, сессия FASP уменьшает скорость передачи пропорционально разнице между целевой и текущей задержкой в очереди, позволяя не перегружать сеть. При снижении нагрузки на сеть, сессия FASP быстро увеличивает скорость пропорционально целевой задержке, утилизируя при этом почти 100% доступной пропускной способности канала.

Кроме эффективной утилизации канала, основанной на измерении задержек в механизме управления скоростью, FASP позволяет равномерно делить полосу пропускания с другим трафиком TCP, а также задавать приоритеты на различные передачи файлов.

Альтернативные технологии и FASP


На сегодняшний день существуют различные технологии ускорения передачи данных по WAN, например, технология сжатия (пр. Riverbed, Silverpeak). Данная технология заключается в компрессии файлов у отправителя и дальнейшей декомпрессии у получателя. Т.е., на самом деле, вы не ускоряете передачу данных в чистом виде, а просто пересылаете меньше данных по сети WAN. Но возможны сценарии, когда файлы не могут быть сжаты, или они уже заархивированы или зашифрованы — в этом случае роста производительности не произойдет.

Другая технология — это Traffic Shaping. В ней на разные типы траффика выставляется разный приоритет. Например, имеет смысл выставить высокий приоритет на трафик приложений, с которыми работает команда менеджеров по продажам, поскольку этот трафик является критичным для бизнеса. Трафику из системы SAP или электронной почты можно задать средний приоритет, а просмотру WEB страниц низкий. Понятно, что это позволяет настроить качество сервиса на определенные задачи, но этот метод не имеет никакого отношения к ускорению передачи данных.
Еще один метод ускорения передачи – это кэширование. Идея данного способа заключается в том, чтобы кэшировать данные, которые часто передаются по сети. Программно-аппаратный комплекс, который стоит на стороне отправителя опрашивает программно-аппаратный комплекс на стороне получателя на предмет наличия у него передаваемого файла или его части, и, в случае, если они имеются, то файл не передается, а извлекается из кэша. Недостатками этого метода являются дорогое оборудование: программно-аппаратный комплекс, который нужно установить в каждой локации, и подход “все или ничего” (метод не работает в случаях, если объект не найден в кэше или был изменен).

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

Подводя итог, приведем основные технологические преимущества Aspera:
• Возможность пересылать очень объемные файлы (от 500 Гбайт до нескольких Тбайт). Клиенты Aspera регулярно отправляют файлы размером больше 1 ТБ как в облачное, так и в локальное хранилище, передавая больше 10 ТБ в одной сессии.
• Передача на огромные расстояния в сетях с большой задержкой (round-trip time) и потерей пакетов. Например, компания BGI передала геномные данные между США и Китаем на скорости 10 Гбит/сек. (http://phys.org/news/2012-06-bgi-genomic-gigabits-china.html).
• Гарантированная и предсказуемая доставка файлов неограниченного объёма на большие расстояния и на максимальной скорости.
Автор: @marks
IBM
рейтинг 176,74

Комментарии (20)

  • +3
    OpenSource реализация? Промышленный стандарт?
    • 0
      Технология часто используется, например, «киношниками». Исходник фильма — это сотни гигабайт.
      Стоит, правда, все это дело как чугунный мост, насколько я помню. Может, после покупки IBM что-то поменялось, но, не думаю.
      • 0
        Я знаю, работал с Асперой… Кстати пару лет назад это был веселый глюкодром, за много денег.
      • 0
        Медийная индустрия давно знает и использует Aspera. В знак признания компания получила статуэтку Эмми на 65 церемонии вручении наград в номинации «an industry game changer»
  • +3
    Мы пользуемся uftp, это похожий протокол на основе udp с механизмом negative acknowledgement (nack). Используем мы его в основном для деплоя на несколько тысяч серверов. Для передачи по длинному линку есть hscp и mtr — тоже похожие на описанные технологии
  • +1
    Как показывает практика последних лет, IT-инновации не имеют шанса на широкое распространение, если ими не заинтересовалась порноиндустрия.
  • 0
    Делал для encoding.com аплоадер файлов с поддержкой FASP. Подтверждаю — работает невероятно быстро и при соответствующих опциях отжирает весь канал (когда тестили, в офисе ни у кого странички не открывались :))
    • 0
      это было десктопное приложение?
      • 0
        Да, винда и мак.
    • +1
      По умолчанию стоит приоритет Fair — честный к другому трафику, а High — да съест всю полосу.
  • 0
    Полнейшая чушь.

    Алгоритм контроля перегрузки в TCP принято называть congestion control, их есть целая куча под разные применения, в том числе и для спутниковых каналов с дропами.
    Помимо прочего для TCP сделали овердохрена всяких расширений/опций для ускорения.
    Сейчас TCP совсем не тот что был когда то, хотя и совместим с ним до сих пор.

    И последнее: недавно японцы хвастались что накорябали свой congestion control алгоритм чтобы в рамках одного TCP соединения прокачивать дохрена и прокачали 73 гигабита: http://geektimes.ru/company/icover/blog/267826/
    Притом типа весь тюнинг был только на сервере.

    И последнее.
    Никакой алгоритм не поможет надёжно шифровать данные на таких скоростях — оно упрётся в криптографию в проце/ускорителе.

    Так что это всё для тех кому лень и/или тех кто не умеет готовить.
  • 0
    Модификаций, расширений и настроек TCP для решения этой проблемы великое множество. В чём преимущество FASP? В каких продуктах этот протокол используется?
    • 0
      Да, это правда, что в последнее время было разработано большое число высокоскоростных версий TCP протокола и апплайнсов которые поддерживали эти модификации. Новые версии TCP протокола признают фундаментальные недостатки AIMD алгоритма и уходят от механизма контроля перегрузки на основе окна TCP, дабы избежать искусственного ограничения скорости, вызванного им же самим и улучшить пропускную способность на больших расстояниях. Наиболее продвинутые версии протокола TCP стараются улучшить механизм обнаружения перегрузки, используя так же, как и FASP задержку нахождения в очереди, что лучше чем повышать скорость до тех пор, пока не случится потеря пакета. Это позволяет TCP не генерировать самому потери пакетов и тем самым, не включать искусственный механизм избежания перегрузки, это улучшает скорость передачи на сетях без потерь пакетов или с малым количеством потерь.
      Однако, эти улучшения быстро исчезают в WAN сети, где потеря пакета может произойти из-за “физики” или переполнения буфера в результате всплеска трафика. Единичная потеря пакета на таких сетях, значительно уменьшит окно TCP, а если потерь будет много, то влияние на скорость будет катастрофическое.
      Пропускная способность “быстрого” TCP (CUBIC, H-TCP, BIC и т.д.) будет больше стандартного TCP Reno на сетях с низкой задержкой, но это преимущество резко исчезает с ростом RTT. С ростом числа потерянных пакетов “быстрый” TCP сравняется по скорости с TCP Reno. В FASP пропускная способность не уменьшается с ростом задержки, с ростом потерянных пакетов пропускная способность FASP уменьшится на тоже самое число, пример 95% при 5% потери пакетов.
      Реакция стандартного и “скоростного” TCP на потерю пакета заставит отправителя, не только уменьшить окно TCP, а также отправлять новые пакеты в окне с уже переданными ранее пакетами для того, чтобы поддерживалась TCP in-order delivery, т.е. доставка пакетов в том порядке в котором они были высланы. Понятно, что не всем приложениям нужна доставка пакетов по порядку, для передачи файлов она не нужна, в отличие например от стриминга видео.
      Приведу пример калькуляции потери пропускной способности из-за единичной потери пакета в “скоростном” TCP с уменьшением окна TCP одна восьмая для каждой потери. Для Гигабитной сети с 1% потерей пакетов и 100 мс RTT, каждый потерянный пакет вызовет уменьшение скорости в одну восьмую (1/2 в TCP Reno), получится
      1 Гбит/c ÷ 8 (бит/байт) ÷ 1024 (байтов/пакет) * 100 мс * 0,125 (уменьшение скорости/потеря) * 100 мс ~ 152.6 секунд потребуется отправителю для того, чтобы вернуться на прежний уровень передачи в 1 Гбит/c. В течение этого периода “скоростной” TCP потеряет 152.6 * 1 Гбит/c * 0.125/2 ~ 8.9 Гбайт пропускной способности из-за единичной потери пакета.
      • 0
        Опять TCP со старыми congestion control сравнивают непонятно с чем.

        1. *бик алгоритмы не самые лучшие, ровно как и reno

        2. «быстрый TCP» это скорее htcp, притом он не сказать чтобы роняет скорость от RTT, только от потерь

        3. для каналов с потерями есть hybla, хз насколько она выжимает всё что можно (пока не проверил), но что лучше всех остальных алгоритмов (при большом ртт и потерях) доступных в линухе на 2013 год это точно.
        Ещё chd есть во фре, тоже вроде для трудных случаев, но ИМХО, его нужно тюнить через sysctl.

        4. Reno описан в RFC и постоянно обновляется, если что.

        Единственный профит в этом вашем FASP это окно передачи размером с весь файл.
        • 0
          А не подскажете, что делать-то, практически?
          • 0
            и khar_khar:

            ЧИТАТЬ!

            Из того же линуха на отдачу запросто можно х2 обычно выжать, если конечно речь не про локалку, там он и так в линк или диск упирается.
            Выставляем буфера сокетов на приём и отдачу по 2 мб, выставляем tcp.cc=hybla или htcp и вот оно счастье.
            Ещё нужно смотреть что всякие крутилки включены.
            Короче, практически Сысоевские рекомендации по тюнингу от 2007 года + hybla.
            hybla тоже можно попробовать тюнить, там всего одна крутилка есть, может немного помочь.

            Я себе под фрю hybla накорябал, и получил х2-х3 прироста в сравнении с со всем остальным что было, особенно в дефолтных настройках.
            Линуксовые htcp, cubic тоже не плохи, нужно подбирать под себя, благо делается без ребута, просто переключаем в sysctl и переподключаем соединение.

            По поводу 300 мегабит: а вы уверены что когда у вас 300 мегабит уходит то с другой стороны приходит хотя бы 280?
            300 мегабит это не большая скорость для шифрования, у меня слабенький амд 5350 аппаратно шифрует гиг в АЕС и даже не напрягается.

            Обычный TCP всегда будет уступать специализированным решениям, но и создавался он для гарантированной доставки (чего попало, а не только файлов) и чтобы не перегружать каналы.

            Есть ещё CTCP (coded tcp, не виндовый ctcp), это больше академическая разработка, вроде есть даже какой то код в виде приложений, можно его попробовать найти и заюзать, авторы хвастались что получилось весьма неплохо — пдф с графиками легко гуглятся.
            • 0
              Представьте что мне 7 лет :)
              Я правильно по понимаю что это советы как оптимизировать сервер который отдает путем тюнинга tcp его тип (htcp, cubic, hybla) + буфер?

              А по протоколу над tcp это это по прежнему будет ftp сервер и мултипоточный FTP клиент?

              По поводу 300 мегабит: а вы уверены что когда у вас 300 мегабит уходит то с другой стороны приходит хотя бы 280?

              Да Aspera их почти полностью утилизирует
              • 0
                Детям семи лет лучше приглашать родителей :)

                Да, это было про настройки OS.
                ftp не тестил, я гонял по http в кач сервера nginx, потому что там тоже можно много чего настроить — есть уверенность что с обоих сторон не код из 90-х годов, когда всё было очень медленное.
        • 0
          Иван, согласен с moiseir… Что делать то? :)
          Есть задача часто передовать файлы по 300 GB между сша и москвой + иногда в нутри в регионах + иногда нудно передовать последовательность на 100т файлов обшим объемом 2-3 TB
          На сервере linux, клиенты которые забирают под виндой.
          Канал который нудно утилизировать 300 M/bit у Aspera это получаеться (я не работают в ibm мы их клиент), у мультипоточного ftp максимум 50-70 M/bit типа…
          Иван какое альтернативное ПО по вашему можно протестировать именно для нашей задачи?
          P.S: На 300 M/bit Aspera еще как то успевает криптовать пакеты… Хотя для нас это не столь важно…
  • 0
    не туда. сорри

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка