telecom №17. Недостатки TCP и новые протоколы транспортного уровня
17-й выпуск подкаста Linkmeup посвящён глубокотехнической теме.
В гостях у нас Дмитрий Качан — аспирант СибГУТИ. Дмитрий в данный момент занимается разработкой транспортных протоколов, работающих на уровне приложений.
Поэтому сегодня мы говорим о недостатках TCP, почему сейчас он уже не может выполнять свою роль протокола с гарантированной доставкой в некоторых случаях.
Вы узнаете какие сейчас есть подходы к решению этой проблемы.
Добавить RSS в подкаст-плеер.
Под катом вы можете найти список некоторых коммерческих решений и протоколов для эффективной передачи информации с гарантированной доставкой, а также сами исследования Дмитрия.
Список подопытных приложений:
Некоторые из решений основаны на TCP, некоторые на UDP. Как итог статьи легко заметить невооружённым глазом существенное преимущество в подходах основанных на UDP.
При анализа были использованы данные исследований, где показывается, что в только в 75 % межконтинентальных соединений показатель потерь пакетов ниже 1%, соответственно исследование в сети с потерей пакетов 1% процент, как минимум, имеет место быть. Что касается задержки — 200 мс Round Trip Time в оптических сетях, соответствует примерно расстоянию в 20 000 км. (это без учёта задержки в промежуточных устройствах) а значит такие соединения тоже возможны. (все это описано в статье).
Позднее были проведены исследования над протоколами для передачи данных( до этого речь шла о конечных приложениях).
В качестве протоколов были использованы:
Результирующая картина такая же: UDP имеет существенное преобладание.
Проект, осуществленный университетом Anhalt, немецким правительством (финансирование) и двумя немецкими фирмами: Tixel GmbH и Axxeo GmbH.
Одни создают фаерволы, другие протокол RWTP. Идея заключалась в том, чтобы сделать использование протокола RWTP для передачи данных как можно более прозрачным.
Этот проект был представлен дважды на выставках CeBit 2013, и СeBit 2014.
В гостях у нас Дмитрий Качан — аспирант СибГУТИ. Дмитрий в данный момент занимается разработкой транспортных протоколов, работающих на уровне приложений.
Поэтому сегодня мы говорим о недостатках TCP, почему сейчас он уже не может выполнять свою роль протокола с гарантированной доставкой в некоторых случаях.
Вы узнаете какие сейчас есть подходы к решению этой проблемы.
Новости выпуска
- Правительство хочет, чтобы данные россиян хранились в нашей стране (link).
- HP сделал свой сетевой симулятор доступным широкой общественности (link)
- В MIT разработали технологию управления трафиком датацентра, которая многократно уменьшает задержки и очереди (link)
- Плавный переход к теме гостя. Big Data на службе футбола (link)
Скачать файл подкаста.
Добавить RSS в подкаст-плеер.
Под катом вы можете найти список некоторых коммерческих решений и протоколов для эффективной передачи информации с гарантированной доставкой, а также сами исследования Дмитрия.
Статья Дмитрия со сравнением приложений
Список подопытных приложений:
Некоторые из решений основаны на TCP, некоторые на UDP. Как итог статьи легко заметить невооружённым глазом существенное преимущество в подходах основанных на UDP.
При анализа были использованы данные исследований, где показывается, что в только в 75 % межконтинентальных соединений показатель потерь пакетов ниже 1%, соответственно исследование в сети с потерей пакетов 1% процент, как минимум, имеет место быть. Что касается задержки — 200 мс Round Trip Time в оптических сетях, соответствует примерно расстоянию в 20 000 км. (это без учёта задержки в промежуточных устройствах) а значит такие соединения тоже возможны. (все это описано в статье).
Позднее были проведены исследования над протоколами для передачи данных( до этого речь шла о конечных приложениях).
Статья Дмитрия со сравнением протоколов
В качестве протоколов были использованы:
- UDT (opensource)
- RBUDP (opensource)
- RWTP base of TIXStream (proprietary)
- MTP base of ExpeDat (proprietary)
Результирующая картина такая же: UDP имеет существенное преобладание.
Проект axxelBox
Проект, осуществленный университетом Anhalt, немецким правительством (финансирование) и двумя немецкими фирмами: Tixel GmbH и Axxeo GmbH.
Одни создают фаерволы, другие протокол RWTP. Идея заключалась в том, чтобы сделать использование протокола RWTP для передачи данных как можно более прозрачным.
Этот проект был представлен дважды на выставках CeBit 2013, и СeBit 2014.
22 комментария
Печально конечно то что у нас в России подобного образования не получить (ну я по крайне мере не встречал), у нас все закачивается на Компьютерные сети — Олифер В.Г., Олифер Н.А. С программированием тоже все не слова богу, хорошие программисты за частую больше знаний и опыта получили в не стен учебных заведений.
Про 1 Гигабитный линк между дата центрами в Польша как то странно. В Европе дорого арендовать высокоскоростной канал? или нет технической возможности? O__o
RWTP — На слух вещь хорошая, на сколько я понял документации в свободном доступе нет, все проприетарное.
А от чего варьирует стоимость box'ов? От объема передаваемого трафика?
А в области связи что бы достичь тех или иных успехов, нужно практически «огонь трением добыть».
Я вот подумываю о том, чтобы когда-нибудь ходить в ВУЗ и читать лекции пару раз в неделю :)
А оборазование вне учебной системы всегда дает хороший результат… но не у всех терпения и силы воли хватает:)
Высокоскоростной канал, елли он ни с кем не поделен — очень дорого везде.
Кстати, я выяснил примерные цены на axxelBox'ы,
приятно, что я был неправ в цифрах:
Версия 100 Mbps — 1700€ + VAT(налог) + сервис (15% в год);
Версия 2.5 Gbps — 4500€ + VAT(налог) + сервис (15% в год).
И стоимость, соответственно, зависит от предоставляемого максимального ускорения.
Для конкрвсетного человека в общем-то, наверно, неважно, где получать опыт. А вот для системы образования, это крайне полезно.
Интересная старья =)
что касается провайдеров — целесообразно напрвить на них только FTP трафик, но это вопрос внутренней кухни провайдера. Вопрос конечно хороший, нужен ли им вообще этот бокс с функцией файервола, или же необходим просто акслеретор:)
В любом случае соль не в железе а в софте и для экстраординарных случаев можно будет укомплектовать и нечто помощнее. Все зависит от потребностей.
Конечные пользователи видят чистую TCP сессию и не имею ни малейшего представления о axxelBox.
Кстати, у меня одногруппники ездили в университет Анхальт по программе двойных дипломов, им понравилась учебная программа и подход к образованию (тоже сети).
А я вот в Кельне учусь и не сказал бы, что очень доволен. Хотя казалось бы большой город, большой университет. А Кётен (где находится университет Анхальт) — небольшой пригород с населением 30000, но с клевым универом.
Не нравится именно в плане образования? Вообще в одном из предыдущих выпусков в гостях у нас был Богдан, он из Канады, и описывал точно такую же ситуацию — все сливки в маленьких городах. И это классно.
Очень надеюсь, что если Вы решите проводить лекции для студентов, то это будут онлайн лекции, как СДСМ, чтобы побольше ребят имело возможность их послушать.
P.S. Не все выпуски успела прослушать, но есть ли где-то представление вашей ведущей Натальи, ее опыт в сфере связи? Мне как девушке очень интересно и радостно слышать у вас в выпусках в том числе женский голос
сам же протокол RWTP потенциально может даже стримы передавать.
Если будет заказ сделать акселиратор для smtp/RPC/RDP/SMB, то, я думаю, это можно будет реализовать на этом протоколе.
Но пока от нее больше вреда чем пользы.
он работает порядочно только по наземным линиям…
P.S. Большое спасибо организаторам за выпуск — так глубоко «на пальцах» я еще не нырял. :)
Мы предлагаем лишь использовать другие, более эффективные протоколы для передачи тяжёлого контента по «жирным сетям».
Более того, парадигма взаимодействия в Интернете уже начала постепенно меняться.
Крупные фирмы с географически распределенными подразделениями, зачастую, покупают сервис Virtual Private LAN, и свой траффик гонят так, что он не контактирует с другим. А вот именно в таких сетях наш протокол и найдёт своё применение, в зависимости от задач конечно же.
Почему мы не следуем этим вариантам? Ну почему же не следуем? Вот например, моя диссертация сейчас идёт в направлении измерения свободной полосы пропускания соединения. Это необходимо, чтобы не просто бездумно посылать в сеть много данных, а так же иметь в виду других участников «дорожного движения».
Только мы хотим не управлять fairness протокола, а мы хотим управлять его агрессивностью.
В идеале это могло бы выглядеть так:
Для соединения, нашему скоростному протоколу мы скажем быть агрессивным на 80% пропускной способности этого соединения, а остальные 20, он будет использовать только если не будет других участников, желающих передать свои данные.
Но и агрессивность не может быть «слепой». Если в соединении будет запущено два таких «трактора», они живенько растолкают все «легковушки», которые будут пытаться ехать по этому соединению. После чего им придётся как то вместе уживаться. Но это уже совсем другая история.
Простите за каламбур со сравнениями протоколов с автомобилями, просто так как то проще объяснять.