LinkMeUp. Выпуск № 17. Недостатки TCP и новые протоколы транспортного уровня

17-й выпуск подкаста Linkmeup посвящён глубокотехнической теме.
В гостях у нас Дмитрий Качан — аспирант СибГУТИ. Дмитрий в данный момент занимается разработкой транспортных протоколов, работающих на уровне приложений.
Поэтому сегодня мы говорим о недостатках TCP, почему сейчас он уже не может выполнять свою роль протокола с гарантированной доставкой в некоторых случаях.
Вы узнаете какие сейчас есть подходы к решению этой проблемы.

Новости выпуска

  1. Правительство хочет, чтобы данные россиян хранились в нашей стране (link).
  2. HP сделал свой сетевой симулятор доступным широкой общественности (link)
  3. В MIT разработали технологию управления трафиком датацентра, которая многократно уменьшает задержки и очереди (link)
  4. Плавный переход к теме гостя. Big Data на службе футбола (link)

Скачать файл подкаста.




Подписаться на podfm. Добавить RSS в подкаст-плеер.

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

Статья Дмитрия со сравнением приложений


Список подопытных приложений:
  1. TixStream
  2. File Catalyst Direct
  3. Velosity
  4. Catapult
  5. ExpeDat

Некоторые из решений основаны на TCP, некоторые на UDP. Как итог статьи легко заметить невооружённым глазом существенное преимущество в подходах основанных на UDP.



При анализа были использованы данные исследований, где показывается, что в только в 75 % межконтинентальных соединений показатель потерь пакетов ниже 1%, соответственно исследование в сети с потерей пакетов 1% процент, как минимум, имеет место быть. Что касается задержки — 200 мс Round Trip Time в оптических сетях, соответствует примерно расстоянию в 20 000 км. (это без учёта задержки в промежуточных устройствах) а значит такие соединения тоже возможны. (все это описано в статье).

Позднее были проведены исследования над протоколами для передачи данных( до этого речь шла о конечных приложениях).

Статья Дмитрия со сравнением протоколов


В качестве протоколов были использованы:
  1. UDT (opensource)
  2. RBUDP (opensource)
  3. RWTP base of TIXStream
  4. (proprietary)
  5. MTP base of ExpeDat
  6. (proprietary)

Результирующая картина такая же: UDP имеет существенное преобладание.

Проект axxelBox


Проект, осуществленный университетом Anhalt, немецким правительством (финансирование) и двумя немецкими фирмами: Tixel GmbH и Axxeo GmbH.
Одни создают фаерволы, другие протокол RWTP. Идея заключалась в том, чтобы сделать использование протокола RWTP для передачи данных как можно более прозрачным.
Этот проект был представлен дважды на выставках CeBit 2013, и СeBit 2014.



22 комментария

avatar
Хорошо получилось :)

Печально конечно то что у нас в России подобного образования не получить (ну я по крайне мере не встречал), у нас все закачивается на Компьютерные сети — Олифер В.Г., Олифер Н.А. С программированием тоже все не слова богу, хорошие программисты за частую больше знаний и опыта получили в не стен учебных заведений.

Про 1 Гигабитный линк между дата центрами в Польша как то странно. В Европе дорого арендовать высокоскоростной канал? или нет технической возможности? O__o

RWTP — На слух вещь хорошая, на сколько я понял документации в свободном доступе нет, все проприетарное.
А от чего варьирует стоимость box'ов? От объема передаваемого трафика?
avatar
C недавних пор я начал понимать, что многое зависит от нас с вами. У меня есть друзья в Новосибирске, которые прекрасно живут, будучи учёными, правда в области химии, а не связи.
avatar
Ну тут да есть такой момент, у меня родственники НИЯУ МИФИ имеют степень доктор и кандидата физико-математических наук, тоже очень не плохо живут=)
А в области связи что бы достичь тех или иных успехов, нужно практически «огонь трением добыть».
avatar
Вынужден согласиться. Среди моих знакомых нет связистов, которые работали бы в ВУЗах. При этом даже получив неплохое образование, они уходят в зарубежные компании.
Я вот подумываю о том, чтобы когда-нибудь ходить в ВУЗ и читать лекции пару раз в неделю :)
avatar
В России, как я и говорил в подкасте, можно получить очень хорошую теоретическую базу(по крайней мере где я видел). Да, возможно, базу без кричащих новинок, но базу, на которой все работает. После такого обучения, за полгода на производстве или в заграничном ВУЗе можно эту теоретическую базу, при желании, добить хорошей практикой и получить хороший результат.
А оборазование вне учебной системы всегда дает хороший результат… но не у всех терпения и силы воли хватает:)

Высокоскоростной канал, елли он ни с кем не поделен — очень дорого везде.

Кстати, я выяснил примерные цены на axxelBox'ы,
приятно, что я был неправ в цифрах:
Версия 100 Mbps — 1700€ + VAT(налог) + сервис (15% в год);
Версия 2.5 Gbps — 4500€ + VAT(налог) + сервис (15% в год).

И стоимость, соответственно, зависит от предоставляемого максимального ускорения.
avatar
Мне кажется, речь о том, что в сфере связи у нас очень сложно получить практику в ВУЗе, как это получается у тебя.

Для конкрвсетного человека в общем-то, наверно, неважно, где получать опыт. А вот для системы образования, это крайне полезно.
avatar
avatar
Очень интересный выпуск. Но вот интересует следующий момент. Как я понял из повествования, так или иначе axxelBox ставятся в режиме inline, т.е. должны пропускать через себя все потоки. Если используются обычные x86-сервера с Linux, то даже бриджирование будет проходить, как я понимаю, через центральный процессор, а ведь надо еще интересующий траффик отлавливать и заниматься тем, для чего axxelBox поставили. И как нам известно, потоки трафика даже у провайдера масштаба среднего города (порядка полумиллиона человек) очень немаленькие и постоянно растут. Выдержит ли такую нагрузку данная железка и не создаст ли критическую точку отказа? Или тут используется PBR на граничных маршрутизаторах и только FTP-трафик пересылается на axxelBox? И еще вопрос сразу: получается для конечных пользователей axxelBox эмулирует реальную TCP-сессию?
avatar
Да, в общем случае, axxelBox ставится в режиме inline и трафик идет через него. Для средних и малых предприятий это не должно создать никаких проблем — файервол по совместительству может будет что то ускорять…
что касается провайдеров — целесообразно напрвить на них только FTP трафик, но это вопрос внутренней кухни провайдера. Вопрос конечно хороший, нужен ли им вообще этот бокс с функцией файервола, или же необходим просто акслеретор:)
В любом случае соль не в железе а в софте и для экстраординарных случаев можно будет укомплектовать и нечто помощнее. Все зависит от потребностей.

Конечные пользователи видят чистую TCP сессию и не имею ни малейшего представления о axxelBox.
avatar
Как всегда, спасибо за выпуск, очень интересно.
Кстати, у меня одногруппники ездили в университет Анхальт по программе двойных дипломов, им понравилась учебная программа и подход к образованию (тоже сети).
А я вот в Кельне учусь и не сказал бы, что очень доволен. Хотя казалось бы большой город, большой университет. А Кётен (где находится университет Анхальт) — небольшой пригород с населением 30000, но с клевым универом.
avatar
Всегда пожалуйста)

Не нравится именно в плане образования? Вообще в одном из предыдущих выпусков в гостях у нас был Богдан, он из Канады, и описывал точно такую же ситуацию — все сливки в маленьких городах. И это классно.
avatar
Да, не нравится в плане образования :)
avatar
Совсем недавно начал интересоваться темой микрочипов, по этому есть вопрос по реализации продукта axxelBox. Я так понимаю реализация самой «коробки» — от чипов до софта ваша? Если так то какие микрочипы использовались? Как они тестировались? Какие основные характеристики лежали в основе выбора? Как в Германии обстоят дела с микрочипами? Было ли какое-то специальное моделирование логики и характеристик чипа под ваши нужды? Имеет ли мой вопрос смысл в данном контексте вопроса :)?
avatar
Реализация только софта наша. Сама «коробка» это просто сервер. единственное требование к нему — это CPU, который будет в состоянии тянуть до 3 Gbps, в случае, если используется 2.5 Gbps версия, и достаточно оперативки.
avatar
Спасибо за выпуск и подкаст в целом! В Украине тоже образование в отрыве от реалий рынка и отрасли. Хотя рынок ведь заинтересован в квалифицированных специалистах, которых не нужно будет обучать и переучивать за средства компании. Поэтому упор делаем на самообразование, в чем ваш ресурс, бесспорно, помогает :)
Очень надеюсь, что если Вы решите проводить лекции для студентов, то это будут онлайн лекции, как СДСМ, чтобы побольше ребят имело возможность их послушать.
P.S. Не все выпуски успела прослушать, но есть ли где-то представление вашей ведущей Натальи, ее опыт в сфере связи? Мне как девушке очень интересно и радостно слышать у вас в выпусках в том числе женский голос
avatar
У нас тут несколько ребят из Одесской академии связи учатся. Ребята способные, и проблемы в знаниях имеют, по сути, схожие с российскими.
avatar
Спасибо за выпуск. А способно ли решение axxelbox разгонять smtp/RPC/RDP/SMB трафик?
avatar
axxelBox — решение направленное на FTP и, по сути, только им и занимается.
сам же протокол RWTP потенциально может даже стримы передавать.
Если будет заказ сделать акселиратор для smtp/RPC/RDP/SMB, то, я думаю, это можно будет реализовать на этом протоколе.
avatar
Спасибо Дмитрий. На данный момент мы совместно со спутниковым провайдером пытаемся оптимизировать TCP с помощью следующей железки… Your text to link...
Но пока от нее больше вреда чем пользы.
avatar
Со спутником, я боюсь, что пока рано этому протоколу сражаться:)
он работает порядочно только по наземным линиям…
avatar
Дмитрий, вы сказали, что разрабатываемые протоколы вряд ли будут стандартизированы из-за своей агрессивности. А какие варианты решения видите вы, для разработки протоколов на замену TCP, которые могли бы быть приняты как международные стандарты? И почему не следуете этим вариантам?
P.S. Большое спасибо организаторам за выпуск — так глубоко «на пальцах» я еще не нырял. :)
avatar
На замену TCP может прийти только протокол, который будет очень осторожен с TCP. Если это не будет учтено, то всю унаследованную инфраструктура ждёт коллапс, ввиду того, что TCP сейчас используется повсеместно.
Мы предлагаем лишь использовать другие, более эффективные протоколы для передачи тяжёлого контента по «жирным сетям».
Более того, парадигма взаимодействия в Интернете уже начала постепенно меняться.
Крупные фирмы с географически распределенными подразделениями, зачастую, покупают сервис Virtual Private LAN, и свой траффик гонят так, что он не контактирует с другим. А вот именно в таких сетях наш протокол и найдёт своё применение, в зависимости от задач конечно же.
Почему мы не следуем этим вариантам? Ну почему же не следуем? Вот например, моя диссертация сейчас идёт в направлении измерения свободной полосы пропускания соединения. Это необходимо, чтобы не просто бездумно посылать в сеть много данных, а так же иметь в виду других участников «дорожного движения».
Только мы хотим не управлять fairness протокола, а мы хотим управлять его агрессивностью.
В идеале это могло бы выглядеть так:
Для соединения, нашему скоростному протоколу мы скажем быть агрессивным на 80% пропускной способности этого соединения, а остальные 20, он будет использовать только если не будет других участников, желающих передать свои данные.
Но и агрессивность не может быть «слепой». Если в соединении будет запущено два таких «трактора», они живенько растолкают все «легковушки», которые будут пытаться ехать по этому соединению. После чего им придётся как то вместе уживаться. Но это уже совсем другая история.
Простите за каламбур со сравнениями протоколов с автомобилями, просто так как то проще объяснять.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.