Для ядра Linux доступна (http://multipath-tcp.org/pmwiki.php/Main/Release87) новая версия (0.87) расширения MPTCP (http://multipath-tcp.org) (MultiPath TCP), которое позволяет организовать (http://multipath-tcp.org/pmwiki.php/Users/ConfigureRouting) работу TCP-соединения с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам. Для сетевых приложений подобное агрегированное соединение выглядит как обычное TCP-соединение, вся логика разделения потоков выполняется силами MPTCP.
Multipath TCP может использоваться как для расширения пропускной способности, так и для увеличения надёжности. В качестве одного из практических применений Multipath TCP для обычных пользователей упоминается возможность организации передачи данных на смартфоне, с использованием одновременно линков WiFi и 3G. Для серверных систем Multipath TCP может обеспечить сокращение расходов за счёт использования нескольких дешевых линков вместо одного более дорогого.
Новая версия выполнена в виде патча для ядра Linux 3.10. Бинарные пакеты собраны (http://multipath-tcp.org/pmwiki.php?n=Users.AptRepository) для Ubuntu (amd64) и Debian (amd64, i386).В отличие от прошлого варианта патча, в новой версии добавлена поддержка аппаратного ускорения TSO/LRO, увеличена производительность, обеспечена поддержка таких средств снятия нагрузки в процессе обработки сетевых соединений, как TCP zero-copy (sendfile и splice) и NET_DMA (http://cateee.net/lkddb/web-lkddb/NET_DMA.html). Обеспечена возможность использования NFS поверх линков, созданных с использованием Multipath TCP.
URL: http://multipath-tcp.org/pmwiki.php/Main/Release87
Новость: http://www.opennet.me/opennews/art.shtml?num=37541
Разделение идет в пределах одного TCP_CONNECT или умеет фрагментировать пакеты?
В классическом Multipath поддержка должна быть у клиента и у сервера.
# This creates two different routing tables, that we use based on the source-address.
ip rule add from 10.1.1.2 table 1
ip rule add from 10.1.2.2 table 2# Configure the two different routing tables
ip route add 10.1.1.0/24 dev eth0 scope link table 1
ip route add default via 10.1.1.1 dev eth0 table 1ip route add 10.1.2.0/24 dev eth1 scope link table 2
ip route add default via 10.1.2.1 dev eth1 table 2# default route for the selection process of normal internet-traffic
ip route add default scope global nexthop via 10.1.1.1 dev eth0Прекрасно! Какой критерий определения, что нужен nexthop, RR/CFQ/FIFO/RANDOM?
ip link set dev eth0 multipath backup
Замечательно, только по-моему это называется Load Balance/HA/Multi routing,..."This server (multipath-tcp.org) is running the latest build of our kernel and has two
interfaces. Thus, every time you connect to this server you will be using MPTCP and
create at least two subflows."
Ну с этого бы и начинали...
>[оверквотинг удален]
>
> ip link set dev eth0 multipath backup
>
> Замечательно, только по-моему это называется Load Balance/HA/Multi routing,...
> "This server (multipath-tcp.org) is running the latest build of our kernel and
> has two
> interfaces. Thus, every time you connect to this server you will be
> using MPTCP and
> create at least two subflows."
> Ну с этого бы и начинали...Приведенный пример как балансировка нагрузки - полная ерунда.
Часть протоколов/сайтов банально не будет в этим работать - один раз запрос пришел с одного адреса, другой раз - с другого... Как минимум - можно ожидать проблем со всеми личными кабинетами в банках и т.д., где такие фокусы будут отслеживаться серверной стороной более ревностно, чем на обычном сайте.
Подробнее: несмотря на то, что маршруты кэшируются (т.е. путь к одно и тому же хосту будет ходить через один и тот же линк), к связанному с ним хосту, но на другом айпи - он может пойти уже через другой линк.
Ну и вообще, приведенный пример с использованием iproute2 - это сетевой уровень. MPTCP - это уже транспортный уровень. Так же, если Вы будете качать файл в один tcp-поток, балансировка нагрузки на сетевом уровне никак не поможет, а на транспортном - поможет.
> Приведенный пример как балансировка нагрузки - полная ерунда.Молодец! Это пример с их сайта :)
> Молодец! Это пример с их сайта :)Trolling win :).
>> Приведенный пример как балансировка нагрузки - полная ерунда.
> Молодец! Это пример с их сайта :)Невнимательно посмотрел на пример, подумал, что это балансировка через iproute2.
> Часть протоколов/сайтов банально не будет в этим работатьА вот MPTCP - будет. В этом то его прелесть как раз.
LARTC бы открыл, что ли, раз уже даже man ip-route для тебя слишком сложен. Пакеты по маршрутам с одинаковыми метриками балансируются RR в равной пропорции (с поправкой на кэширование маршрутов).
> LARTC бы открылЕщё один теоретик,
1. LARTC устарел уже лет на 15 точно.
2. RFC по MPTCP только в январе придумали, какие в песту FAQи
3. Кроме RR есть ещё CBQ/HTB/HFSC/SFB/SFQ/TEQL/QFQ/... и ещё туева хуча, появившихся с момента написания LARTC.
>Кроме RR есть ещё CBQ/HTB/HFSC/SFB/SFQ/TEQL/QFQ/...Речь не про очередь пакетов у интерфейса, а про вес маршрута, при выборе последнего. Ты QoS с маршрутизацией не путай. Маршруты выбираются в ядре только по WRR.
Планировщик пакетов и QoS ваще в разных измерения живут.
Хотя да, для юзера Интернет и Браузер - это одна х...я.
>CBQ/HTB/HFSC/SFB/SFQ/TEQL/QFQЗачем тогда сам пишешь про все эти планировщики очередей пакетов, используемых для QoS?
Открой исходники ядра хотя бы, кроме WRR других алгоритмов балансировки маршрутов нет.
> # This creates two1. Без автономки это работает криво.
2. С автономкой это работает криво наполовину, но работает для исходящего трафика.
3. К теме это все мало относится.
согласен
Я вот тоже не понимаю зачем этот MultiPath TCP. И чем от отличается от примера выше.
Вроде наружу ( для приложения ) это будет один стрим .
Как то так , по моему .
> Я вот тоже не понимаю зачем этот MultiPath TCP. И чем от
> отличается от примера выше.Тем, что без MPTCP в примере выше пакеты будут уходить с разных интерфейсов и, соответственно, восприниматься принадлежащими к разным сессиям, т.о., если сессия началась на одном интерфейсе, то приходящие по другому интерфейсу пакеты восприниматься, как невалидные. Конечно, кэширование маршрутов несколько сгладит проблему, но ребалансировку на лету при падении одного из каналов уже не обеспечит.
чего сразу не B.A.T.M.A.N нативный ? :)
https://en.wikipedia.org/wiki/B.A.T.M.A.N.
какие-то костыли multipath из эпохи 1990х городить, тьфу...
Request for Comments: 6824, January 2013
TCP Extensions for Multipath Operation with Multiple Addresseshttp://tools.ietf.org/html/rfc6824
Ну да, почти 90-х. :)
по дизайну решения и по самому подходу к и (декларируемому)решению - читый 1992 год.
лютый засил irc и без http 0.9 ишшо. все дружно юзают Gopher, UUCP и AOL/Prodigy/MSDN
> чего сразу не B.A.T.M.A.N нативный ? :)Ээээ batman в ядре уже есть, нативнее вроде просто некуда :).
лучше бы СС пилили.
а то половина реализаций бородатого ECN - не дружит с третью реализаций SynCookie а уж CTCP и DCTCP - вообще мало где есть, увы :(
Здоровская штука. Жаль, что почти никем пока не поддерживается. Очень удобно тем, у кого два и более линка во внешний мир - мне, например.
> мне, например.Ой напугал,... ща воткну Йоту, мобилу, ADSL и 3 хакнутых соседских вайфая, и устрою тут мультифлуд :)
Не, у меня реально два симметричных линка - для отказоустойчивости. А ёты и прочее - да, в качестве крайнего резерва.
По теме - сомневаюсь, что гугл на мобилки это быстро запихнёт :)
Пойду компилять под центос, давненько не брал в руки шашек...
А какие роутеры поддерживают два коннекта? Ставить ради этого комп не охота
> Йоту, мобилу, ADSL и 3 хакнутых соседских вайфаяи с каждого - через тор, для полноты щястья.
> Здоровская штука. Жаль, что почти никем пока не поддерживается.А оно и не должно никем поддерживаться кроме твоих хостов между которыми ты трафф гонять будешь через несколько линков :).
Хинт: так можно в принципе агрегировать трафф на чем-то типа VPN сервера, обеспечив повышенную суммарную скорость и автоматическое прозрачное переключение каналов интернета :).
Интересео - поймут они с солярой друг друга? А то я IPMP давно и успешно юзаю :)
А под соляркой уже запускается ядро линух? :Э
Я конечно понимал что ты деб^W странный, но надеялся что ты хоть великий и могучий петраешь ...
Ну бывает, сделаею поправку на чурк^W на гостей столицы, ещё раз большими малиновыми буквами:В Соляре IP_M_ulti_P_ath хрен знает ужо сколько. Вот и интересно поймут они друг друга или как обычно ...
IPMP в соляре это севсем не то, о чем написано в новосте. Там оно используется для только для отказоустойчивости и одновременно ничего никуда не идет.
> IPMP в соляре это севсем не то, о чем написано в новосте.
> Там оно используется для только для отказоустойчивости и одновременно ничего никуда
> не идет.Маны кури. Там т а щ е м т а настоящий мультипасинг реализован действительно лет 20 тому как.
Да что вы говорите, ну приведите хотя бы простенький пример. Где для передачи будет использоваться одновременно более 1 линка. Этот ipmp failover-ный. А про то, о чем вы говорите это agregation, нормально работающий начиная с 10ки
> друг друга или как обычно ...Как обычно, ибо MPTCP - это отдельное расширение протокола TCP, позволяющее явно открывать новые потоки и прочая. Для софта все выглядит как будто это одно и то же соединение - новые потоки кернель поднимает. Хотя если софт желает явно знать топологию - это предусмотрено.
Зачем?? Есть же STCP - его продвигать надо!
http://www.ibm.com/developerworks/ru/library/l-sctp/index.ht...
Тебя забыли спросить,
что продвигать надо.
> Зачем?? Есть же STCP - его продвигать надо!Ну так продвигай. А как по мне - эта штука куда как менее радикальна и имеет коронный бонус: в лучшем случае софт можно совсем не переделывать, но плюсы поиметь получится :).
> Зачем?? Есть же STCP - его продвигать надо!
> http://www.ibm.com/developerworks/ru/library/l-sctp/index.ht...Не факт, что надо.
Весьма сложный протокол, который изначально затачивался для решения весьма узких задач ... нажрался я ним в свое время в телекоме но самое немогу, когда свое понимание вендора + сырость реализации к таким артефактам приводили ... извините, но тогдашний циркодром с проблемами ОСК7 мне до сих пор по ночам снится ... как изощренный кошмар
Так вот и надо стандартизацию и тестирование. Можно подумать другие (IPX|IP|TCP|UDP|*) были сразу готовы. Кроме того - эта новая фича также требует изменение и поддержки как клиента так и сервера иначе толку - NULL.
А что легче с нуля соорудить на основе стандарта или многолетние наслоения готовых программ тревожить?? Думаю ответ очевиден.
Вон "очевидный ответ" в виде IPv6 уже соорудили "с нуля". Да так, что почти 20 лет уже в обед, а внедрения всё нет.
> Вон "очевидный ответ" в виде IPv6 уже соорудили "с нуля". Да так,
> что почти 20 лет уже в обед, а внедрения всё нет.IPv6 тормозится из-за существующей инфраструктуры роутинга с NAT, которой "всем достаточно" и ничего нового больше не нужно. Вложения в IPv4/NAT уже сто раз себя окупили и дадут ещё подзаработать не одному поколению админов-сетевиков. А вот инвестиции в IPv6 ещё не определены толком, кому-чего давать, чтобы хорошо и долго работало — NAT IPv4 стала преградой для продвижения IPv6 вследствие своей "кормушечной" природы (многие от наличия NAT кормятся и, кстати, не без успеха проталкивают эту ненужность в IPv6). ;)
Должен ли удаленный сервер иметь поддержку MultiPath TCP, чтоб вся это магия заработала или же это всё будет замечательно работать уже сейчас со всеми существующими серверами в Интернете?Если только один из линков на машине будет иметь реальный IP, а на остальных будет использоваться NAT, то MultiPath TCP будет ли работать и получать преимущества от всех этих линков?
> Должен ли удаленный сервер иметь поддержку MultiPath TCP,Ну разумеется. Зато между своими хостами так трафф гонять милое дело: промежуточные узлы которые не в курсе что такое MPTCP никак особо мешать не будут. В самом плохом случае оно просто деграднет до 1-поточного классического TCP :)
А как же снифферы и СОРМ-2, они шо пострадают?
Конечно. Так шта, пока не придумают, как увязать СОРМ с этим чудом, в продакшене MPTCP не жди и не надейся!
Они изобрели заново мультиплексор для TCP ?
а какие уже изобретённые Вы знаете?