The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Новая версия MPTCP (Multipath TCP) для Linux

29.07.2013 21:20

Для ядра Linux доступна новая версия (0.87) расширения MPTCP (MultiPath TCP), которое позволяет организовать работу TCP-соединения с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам. Для сетевых приложений подобное агрегированное соединение выглядит как обычное TCP-соединение, вся логика разделения потоков выполняется силами MPTCP.

Multipath TCP может использоваться как для расширения пропускной способности, так и для увеличения надёжности. В качестве одного из практических применений Multipath TCP для обычных пользователей упоминается возможность организации передачи данных на смартфоне, с использованием одновременно линков WiFi и 3G. Для серверных систем Multipath TCP может обеспечить сокращение расходов за счёт использования нескольких дешевых линков вместо одного более дорогого.

Новая версия выполнена в виде патча для ядра Linux 3.10. Бинарные пакеты собраны для Ubuntu (amd64) и Debian (amd64, i386). В отличие от прошлого варианта патча, в новой версии добавлена поддержка аппаратного ускорения TSO/LRO, увеличена производительность, обеспечена поддержка таких средств снятия нагрузки в процессе обработки сетевых соединений, как TCP zero-copy (sendfile и splice) и NET_DMA. Обеспечена возможность использования NFS поверх линков, созданных с использованием Multipath TCP.

  1. Главная ссылка к новости (http://multipath-tcp.org/pmwik...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/37541-multipath
Ключевые слова: multipath, mptcp
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (47) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, pavlinux (ok), 21:31, 29/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Разделение идет в пределах одного 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 1

      ip 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."
      
    Ну с этого бы и начинали...

     
     
  • 2.9, anonymous (??), 22:49, 29/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >


    > 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-поток, балансировка нагрузки на сетевом уровне никак не поможет, а на транспортном - поможет.

     
     
  • 3.15, pavlinux (ok), 02:03, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > Приведенный пример как балансировка нагрузки - полная ерунда.

    Молодец! Это пример с их сайта :)

     
     
  • 4.25, Аноним (-), 15:13, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Молодец! Это пример с их сайта :)

    Trolling win :).

     
  • 4.35, anonymous (??), 18:45, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Приведенный пример как балансировка нагрузки - полная ерунда.
    > Молодец! Это пример с их сайта :)

    Невнимательно посмотрел на пример, подумал, что это балансировка через iproute2.

     
  • 3.26, Аноним (-), 15:13, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Часть протоколов/сайтов банально не будет в этим работать

    А вот MPTCP - будет. В этом то его прелесть как раз.

     
  • 2.11, Аноним (-), 23:44, 29/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    LARTC бы открыл, что ли, раз уже даже man ip-route для тебя слишком сложен. Пакеты по маршрутам с одинаковыми метриками балансируются RR в равной пропорции (с поправкой на кэширование маршрутов).
     
     
  • 3.16, pavlinux (ok), 02:04, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > LARTC бы открыл

    Ещё один теоретик,

    1. LARTC устарел уже лет на 15 точно.
    2. RFC по MPTCP только в январе придумали, какие в песту FAQи  
    3. Кроме RR есть ещё CBQ/HTB/HFSC/SFB/SFQ/TEQL/QFQ/... и ещё туева хуча, появившихся с момента написания LARTC.

     
     
  • 4.39, Аноним (-), 22:18, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >Кроме RR есть ещё CBQ/HTB/HFSC/SFB/SFQ/TEQL/QFQ/...

    Речь не про очередь пакетов у интерфейса, а про вес маршрута, при выборе последнего. Ты QoS с маршрутизацией не путай. Маршруты выбираются в ядре только по WRR.

     
     
  • 5.45, pavlinux (ok), 02:49, 31/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Планировщик пакетов и QoS ваще в разных измерения живут.
    Хотя да, для юзера Интернет и Браузер - это одна х...я.


     
     
  • 6.47, Аноним (-), 16:37, 31/07/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >CBQ/HTB/HFSC/SFB/SFQ/TEQL/QFQ

    Зачем тогда сам пишешь про все эти планировщики очередей пакетов, используемых для QoS?

    Открой исходники ядра хотя бы, кроме WRR других алгоритмов балансировки маршрутов нет.

     
  • 2.21, Аноним (-), 08:47, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > # This creates two

    1. Без автономки это работает криво.
    2. С автономкой это работает криво наполовину, но работает для исходящего трафика.
    3. К теме это все мало относится.

     
  • 2.48, друг pavlinux (?), 08:12, 01/08/2013 [^] [^^] [^^^] [ответить]  
  • +/
    согласен

     

  • 1.2, Аноним (-), 21:44, 29/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я вот тоже не понимаю зачем этот MultiPath TCP. И чем от отличается от примера выше.  
     
     
  • 2.3, Васисуалий (?), 21:51, 29/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вроде наружу ( для приложения ) это будет один стрим .
    Как то так , по моему .
     
  • 2.12, Аноним (-), 23:48, 29/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Я вот тоже не понимаю зачем этот MultiPath TCP. И чем от
    > отличается от примера выше.

    Тем, что без MPTCP в примере выше пакеты будут уходить с разных интерфейсов и, соответственно, восприниматься принадлежащими к разным сессиям, т.о., если сессия началась на одном интерфейсе, то приходящие по другому интерфейсу пакеты восприниматься, как невалидные. Конечно, кэширование маршрутов несколько сгладит проблему, но ребалансировку на лету при падении одного из каналов уже не обеспечит.

     

  • 1.4, Аноним (-), 22:13, 29/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    чего сразу не B.A.T.M.A.N нативный ? :)
    https://en.wikipedia.org/wiki/B.A.T.M.A.N.
    какие-то костыли multipath из эпохи 1990х городить, тьфу...
     
     
  • 2.7, pavlinux (ok), 22:47, 29/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Request for Comments: 6824,  January 2013
    TCP Extensions for Multipath Operation with Multiple Addresses

    http://tools.ietf.org/html/rfc6824

    Ну да, почти 90-х. :)

     
     
  • 3.44, Аноним (-), 00:18, 31/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    по дизайну решения и по самому подходу к и (декларируемому)решению - читый 1992 год.
    лютый засил irc и без http 0.9 ишшо. все дружно юзают Gopher, UUCP и AOL/Prodigy/MSDN
     
  • 2.27, Аноним (-), 15:15, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > чего сразу не B.A.T.M.A.N нативный ? :)

    Ээээ batman в ядре уже есть, нативнее вроде просто некуда :).

     

  • 1.5, Аноним (-), 22:15, 29/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    лучше бы СС пилили.
    а то половина реализаций бородатого ECN - не дружит с третью реализаций SynCookie а уж CTCP и DCTCP - вообще мало где есть, увы :(
     
  • 1.6, AlexAT (ok), 22:46, 29/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Здоровская штука. Жаль, что почти никем пока не поддерживается. Очень удобно тем, у кого два и более линка во внешний мир - мне, например.
     
     
  • 2.8, pavlinux (ok), 22:48, 29/07/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > мне, например.

    Ой напугал,... ща воткну Йоту, мобилу, ADSL и 3 хакнутых соседских вайфая, и устрою тут мультифлуд :)


     
     
  • 3.10, AlexAT (ok), 22:52, 29/07/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Не, у меня реально два симметричных линка - для отказоустойчивости. А ёты и прочее - да, в качестве крайнего резерва.
    По теме - сомневаюсь, что гугл на мобилки это быстро запихнёт :)
    Пойду компилять под центос, давненько не брал в руки шашек...
     
     
  • 4.38, Крот (??), 22:10, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А какие роутеры поддерживают два коннекта? Ставить ради этого комп не охота
     
  • 3.14, YetAnotherOnanym (ok), 00:47, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Йоту, мобилу, ADSL и 3 хакнутых соседских вайфая

    и с каждого - через тор, для полноты щястья.

     
  • 2.29, Аноним (-), 15:16, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Здоровская штука. Жаль, что почти никем пока не поддерживается.

    А оно и не должно никем поддерживаться кроме твоих хостов между которыми ты трафф гонять будешь через несколько линков :).

    Хинт: так можно в принципе агрегировать трафф на чем-то типа VPN сервера, обеспечив повышенную суммарную скорость и автоматическое прозрачное переключение каналов интернета :).

     

  • 1.13, Аноним (-), 00:36, 30/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Интересео - поймут они с солярой друг друга? А то я IPMP давно и успешно юзаю :)
     
     
  • 2.17, pavlinux (ok), 02:22, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А под соляркой уже запускается ядро линух? :Э
     
     
  • 3.18, Аноним (-), 03:49, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Я конечно понимал что ты деб^W странный, но надеялся что ты хоть великий и могучий петраешь ...
    Ну бывает, сделаею поправку на чурк^W на гостей столицы, ещё раз большими малиновыми буквами:

    В Соляре IP_M_ulti_P_ath хрен знает ужо сколько. Вот и интересно поймут они друг друга или как обычно ...

     
     
  • 4.22, Ващенаглухо (ok), 09:01, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    IPMP в соляре это севсем не то, о чем написано в новосте. Там оно используется для только для отказоустойчивости и одновременно ничего никуда не идет.
     
     
  • 5.24, Аноним (-), 15:00, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > IPMP в соляре это севсем не то, о чем написано в новосте.
    > Там оно используется для только для отказоустойчивости и одновременно ничего никуда
    > не идет.

    Маны кури. Там т а щ е м т а  настоящий мультипасинг реализован действительно лет 20 тому как.

     
     
  • 6.50, Ващенаглухо (ok), 10:08, 05/08/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да что вы говорите, ну приведите хотя бы простенький пример. Где для передачи будет использоваться одновременно более 1 линка. Этот ipmp failover-ный. А про то, о чем вы говорите это agregation, нормально работающий начиная с 10ки
     
  • 4.30, Аноним (-), 15:18, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > друг друга или как обычно ...

    Как обычно, ибо MPTCP - это отдельное расширение протокола TCP, позволяющее явно открывать новые потоки и прочая. Для софта все выглядит как будто это одно и то же соединение - новые потоки кернель поднимает. Хотя если софт желает явно знать топологию - это предусмотрено.

     

  • 1.19, Аноним (-), 05:14, 30/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Зачем?? Есть же STCP - его продвигать надо!
    http://www.ibm.com/developerworks/ru/library/l-sctp/index.html?S_TACT=105AGX9
     
     
  • 2.20, Аноним (-), 07:24, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Тебя забыли спросить,
    что продвигать надо.
     
  • 2.31, Аноним (-), 15:19, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Зачем?? Есть же STCP - его продвигать надо!

    Ну так продвигай. А как по мне - эта штука куда как менее радикальна и имеет коронный бонус: в лучшем случае софт можно совсем не переделывать, но плюсы поиметь получится :).

     
  • 2.34, edwin (??), 17:47, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Зачем?? Есть же STCP - его продвигать надо!
    > http://www.ibm.com/developerworks/ru/library/l-sctp/index.html?S_TACT=105AGX9

    Не факт, что надо.
    Весьма сложный протокол, который изначально затачивался для решения весьма узких задач ... нажрался я ним в свое время в телекоме но самое немогу, когда свое понимание вендора + сырость реализации к таким артефактам приводили ... извините, но тогдашний циркодром с проблемами ОСК7 мне до сих пор по ночам снится ... как изощренный кошмар


     
     
  • 3.36, некто (?), 19:01, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так вот и надо стандартизацию и тестирование. Можно подумать другие (IPX|IP|TCP|UDP|*) были сразу готовы. Кроме того - эта новая фича также требует изменение и поддержки как клиента так и сервера иначе толку - NULL.
    А что легче с нуля соорудить на основе стандарта или многолетние наслоения готовых программ тревожить?? Думаю ответ очевиден.
     
     
  • 4.40, AlexAT (ok), 22:20, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вон "очевидный ответ" в виде IPv6 уже соорудили "с нуля". Да так, что почти 20 лет уже в обед, а внедрения всё нет.
     
     
  • 5.46, iZEN (ok), 15:24, 31/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Вон "очевидный ответ" в виде IPv6 уже соорудили "с нуля". Да так,
    > что почти 20 лет уже в обед, а внедрения всё нет.

    IPv6 тормозится из-за существующей инфраструктуры роутинга с NAT, которой "всем достаточно" и ничего нового больше не нужно. Вложения в IPv4/NAT уже сто раз себя окупили и дадут ещё подзаработать не одному поколению админов-сетевиков. А вот инвестиции в IPv6 ещё не определены толком, кому-чего давать, чтобы хорошо и долго работало — NAT IPv4 стала преградой для продвижения IPv6 вследствие своей "кормушечной" природы (многие от наличия NAT кормятся и, кстати, не без успеха проталкивают эту ненужность в IPv6). ;)

     

  • 1.23, Аноним (-), 11:37, 30/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Должен ли удаленный сервер иметь поддержку MultiPath TCP, чтоб вся это магия заработала или же это всё будет замечательно работать уже сейчас со всеми существующими серверами в Интернете?

    Если только один из линков на машине будет иметь реальный IP, а на остальных будет использоваться NAT, то MultiPath TCP будет ли работать и получать преимущества от всех этих линков?

     
     
  • 2.32, Аноним (-), 15:20, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Должен ли удаленный сервер иметь поддержку MultiPath TCP,

    Ну разумеется. Зато между своими хостами так трафф гонять милое дело: промежуточные узлы которые не в курсе что такое MPTCP никак особо мешать не будут. В самом плохом случае оно просто деграднет до 1-поточного классического TCP :)

     

  • 1.33, Аноним (-), 16:43, 30/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А как же снифферы и СОРМ-2, они шо пострадают?
     
     
  • 2.37, iZEN (ok), 19:07, 30/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно. Так шта, пока не придумают, как увязать СОРМ с этим чудом, в продакшене MPTCP не жди и не надейся!
     

  • 1.49, Аноним (-), 16:37, 04/08/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Они изобрели заново мультиплексор для TCP ?
     
     
  • 2.51, edo (ok), 01:23, 19/08/2013 [^] [^^] [^^^] [ответить]  
  • +/
    а какие уже изобретённые Вы знаете?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру