Comments 20
OpenSource реализация? Промышленный стандарт?
Технология часто используется, например, «киношниками». Исходник фильма — это сотни гигабайт.
Стоит, правда, все это дело как чугунный мост, насколько я помню. Может, после покупки IBM что-то поменялось, но, не думаю.
Стоит, правда, все это дело как чугунный мост, насколько я помню. Может, после покупки IBM что-то поменялось, но, не думаю.
Я знаю, работал с Асперой… Кстати пару лет назад это был веселый глюкодром, за много денег.
Медийная индустрия давно знает и использует Aspera. В знак признания компания получила статуэтку Эмми на 65 церемонии вручении наград в номинации «an industry game changer»
Мы пользуемся uftp, это похожий протокол на основе udp с механизмом negative acknowledgement (nack). Используем мы его в основном для деплоя на несколько тысяч серверов. Для передачи по длинному линку есть hscp и mtr — тоже похожие на описанные технологии
Как показывает практика последних лет, IT-инновации не имеют шанса на широкое распространение, если ими не заинтересовалась порноиндустрия.
Делал для encoding.com аплоадер файлов с поддержкой FASP. Подтверждаю — работает невероятно быстро и при соответствующих опциях отжирает весь канал (когда тестили, в офисе ни у кого странички не открывались :))
UFO just landed and posted this here
Модификаций, расширений и настроек TCP для решения этой проблемы великое множество. В чём преимущество FASP? В каких продуктах этот протокол используется?
Да, это правда, что в последнее время было разработано большое число высокоскоростных версий 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 Гбайт пропускной способности из-за единичной потери пакета.
Однако, эти улучшения быстро исчезают в 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 Гбайт пропускной способности из-за единичной потери пакета.
UFO just landed and posted this here
А не подскажете, что делать-то, практически?
UFO just landed and posted this here
Представьте что мне 7 лет :)
Я правильно по понимаю что это советы как оптимизировать сервер который отдает путем тюнинга tcp его тип (htcp, cubic, hybla) + буфер?
А по протоколу над tcp это это по прежнему будет ftp сервер и мултипоточный FTP клиент?
Да Aspera их почти полностью утилизирует
Я правильно по понимаю что это советы как оптимизировать сервер который отдает путем тюнинга tcp его тип (htcp, cubic, hybla) + буфер?
А по протоколу над tcp это это по прежнему будет ftp сервер и мултипоточный FTP клиент?
По поводу 300 мегабит: а вы уверены что когда у вас 300 мегабит уходит то с другой стороны приходит хотя бы 280?
Да Aspera их почти полностью утилизирует
Иван, согласен с moiseir… Что делать то? :)
Есть задача часто передовать файлы по 300 GB между сша и москвой + иногда в нутри в регионах + иногда нудно передовать последовательность на 100т файлов обшим объемом 2-3 TB
На сервере linux, клиенты которые забирают под виндой.
Канал который нудно утилизировать 300 M/bit у Aspera это получаеться (я не работают в ibm мы их клиент), у мультипоточного ftp максимум 50-70 M/bit типа…
Иван какое альтернативное ПО по вашему можно протестировать именно для нашей задачи?
P.S: На 300 M/bit Aspera еще как то успевает криптовать пакеты… Хотя для нас это не столь важно…
Есть задача часто передовать файлы по 300 GB между сша и москвой + иногда в нутри в регионах + иногда нудно передовать последовательность на 100т файлов обшим объемом 2-3 TB
На сервере linux, клиенты которые забирают под виндой.
Канал который нудно утилизировать 300 M/bit у Aspera это получаеться (я не работают в ibm мы их клиент), у мультипоточного ftp максимум 50-70 M/bit типа…
Иван какое альтернативное ПО по вашему можно протестировать именно для нашей задачи?
P.S: На 300 M/bit Aspera еще как то успевает криптовать пакеты… Хотя для нас это не столь важно…
не туда. сорри
Sign up to leave a comment.
Высокоскоростной протокол передачи файлов – Aspera FASP