The OpenNET Project / Index page

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

Выпуск MPTCP 0.90 (Multipath TCP) для Linux

28.09.2015 10:52

После более года разработки для ядра Linux доступна новая версия (0.90) расширения MPTCP (MultiPath TCP), которое позволяет организовать работу TCP-соединения с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам. Для сетевых приложений подобное агрегированное соединение выглядит как обычное TCP-соединение, вся логика разделения потоков выполняется силами MPTCP. Новая версия выполнена в виде патча для ядра Linux 3.18. Бинарные пакеты собраны для Ubuntu 14.04 (amd64) и Debian Squeeze (amd64, i386).

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

В новой версии:

  • В состав включен алгоритм управления перегрузкой TCP Balia (Balanced Linked Adaptation Congestion Control Algorithm), специально реализованный для MPTCP и учитывающий балансировку потока через несколько разнородных линков;
  • Добавлена поддержка режима быстрого открытия TCP-соединений FastOpen для Multipath TCP. TCP FastOpen позволяет сократить число шагов установки соединения за счёт комбинирования в один запрос первого и второго шагов классического 3-этапного процесса согласования соединения, и даёт возможность отправки данных на начальном этапе установки соединения (данные посылаются одновременно с SYN-сегментом);
  • Улучшена поддержка опций настройки TCP-сокета;
  • Возможность настройки метода контроля перегрузки для отдельных потоков через опцию настройки сокета TCP_CONGESTION;
  • Поддержка неотслеживаемой (stateless) установки соединений (например, TCP SYN-Cookies);
  • Возможность использования TCP SYN-Cookies для защиты web-серверов от SYN-флуда;
  • Добавлены дополнительные счётчики MIB/SNMP для статистики и отладки;
  • Поддержка мониторинга за состоянием MPTCP через команду "netstat -s" (требуется установка модифицированной версии пакета net-tools);
  • Проведение работы по оптимизации производительности.


  1. Главная ссылка к новости (http://multipath-tcp.org/pmwik...)
Лицензия: CC-BY
Тип: Программы
Ключевые слова: mptcp
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (53) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Snaut (ok), 11:10, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    >>> давая возможность отправки данных на начальном этапе установки соединения (данные посылаются одновременно с SYN-сегментом);

    отличная дыра для ddos. теперь серверу мало того, что надо будет открыть соединение - так еще и обработать что находится внутри пакета.

     
     
  • 2.4, Аноним (-), 11:31, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ЭТО (tcp fast open) уже относительно есть в классическом tcp, и даже работает, и даже дефолтно.
    http://kernelnewbies.org/Linux_3.13#head-159ff61ea3acfd67b88855e75dbbb140f882
     
     
  • 3.6, Snaut (ok), 11:35, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > ЭТО (tcp fast open) уже относительно есть в классическом tcp, и даже
    > работает, и даже дефолтно.
    > http://kernelnewbies.org/Linux_3.13#head-159ff61ea3acfd67b88855e75dbbb140f882

    ну подобное нужно для real-time систем. на кой оно по дефолту не понятно

     
     
  • 4.8, XXasd (?), 12:39, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    то есть пользователи не real-time -- должны страдать? :-)
     
     
  • 5.10, Аноним (-), 12:47, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если он сам хочет страдать - никакое отсутствие fast-open ему помешать не в силах.
     

  • 1.3, анон (?), 11:25, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А в меинлаин не хотят впихнуть?
     
  • 1.5, б.б. (?), 11:34, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    в смысле, в основном ядре этого разве нет?
     
     
  • 2.7, Alex (??), 11:57, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    MPTCP? Пока нет. Вообще штука очень интересная, особенно с учётом того, что даёт возможность очень просто строить распределённую балансировку.
     

  • 1.9, fail (?), 12:43, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    >с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы,

    Ы, "нафейхуа" - одновременно ?

     
  • 1.11, fail (?), 12:47, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    ...схоже, на попытку выбивания и освоения грантофф - пeреизобрeтением SСTР
     
     
  • 2.12, anonymous (??), 13:09, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Утверждается, что оно лучше работает с ущербными роутерами и файрволлами, не знающими ни о чем, кроме TCP и UDP
     
     
  • 3.21, Demo (??), 22:30, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вот поэтому в Интернете всё как-то кривенько и через ж…

    Напомнило как мы долго бились с проблемой невозможности связать через Watson-овские бриджи рабочую станцию управления с STM-1 мультиками, хотя локально по 10BASE-2 всё летало "на ура!". В итоге, через пол-дня разбирательств, выяснилось, что все Ethertype-ы кроме IP отфильтровывались бриджами как некорректные. Видимо инженеры Watson-а о CLNP и слыхом не слыхивали. Да что тут говорить о CLNP, если IPX им тоже не знаком. Выросло поколение инженеров, не знающих ничего, кроме IP, будто и не было ничего ни до ни после…

     

  • 1.13, orgkhnargh (ok), 14:30, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    То есть, если у меня есть 2 свистка по 2 мегабита от разных операторов, то с помощью MPTCP я смогу получить 4 мегабита вкупе и можно будет качество видео на ютубе повыше сделать?
     
     
  • 2.14, slavius (?), 14:37, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • –6 +/
    а ты ютубу сначала скажи что ты качаешь в два свистка)) да и повозись чтоб это все собиралось в один файл и кормилось твоему плееру. нет конечно можно наваять скрипт на коленке, но боюсь  что скриптик получится не маленький. придется делать что то типа торрента. кстати для торрента должно быть неплохо. опять же надо проверять.
     
     
  • 3.16, Аноним (-), 16:58, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А разве не в этом смысл MultiPath TCP, чтобы снять эту работу с приклада?
     
  • 3.18, Аноним (-), 18:12, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    «Для сетевых приложений подобное агрегированное соединение выглядит как обычное TCP-соединение, вся логика разделения потоков выполняется силами MPTCP.»

    Никому ничего объяснять не надо. Главное, чтобы Ютуб понимал MPTCP, но это можно решить при помощи промежуточного прокси-сервера.

     
     
  • 4.23, slavius (?), 22:43, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    а ты подумал че сказал? ты каким макаром собрался объяснить ютубу что ты качаешь с одного компа но в два потока.? он то увидит 2 ip? и ко всему прочему надо чтоб ютуб отдавал данные пачками и это все дело маркировалось по положению в файле, точь в точь как торрент, или ты собрался смотреть 2 версии одного и того же через свой плеер? тогда в чем суть. что один канал что 2.
     
     
  • 5.30, Alex (??), 08:09, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Самовыпились, а. MPTCP именно тем и занимается, что изолирует многоканальность от приложения. Приложение 2 IP не увидит, а вот MPTCP - увидит.
     
  • 4.24, slavius (?), 22:53, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    еще добавлю прокси сервер тебе не разделит потоки и он же создаст ситуацию при которой один поток останется не у дел. фишка в том и есть что с одного компа норазных сетевух и разных ip/ нафига копья ломать тогда, сразу увеличил скорость и все. а вот торрент из этого действительно пользу извлечет. и вообще чисто сетевые проги , работающие на скачку. опять же будет разве что возможность распределения мощностей, но это и раньше можно было сделать при наличии двух сетевух и ip. в чем соль пока не понял, для просмотра видео её пока точно нет.
     
     
  • 5.26, Ytch (ok), 01:05, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Что ему помешает Из примера выше - прокси сидит, к примеру, на 10 мегабитном ка... текст свёрнут, показать
     
     
  • 6.46, slavius (?), 01:08, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    а теперь подумай хорошенько и скажи как ты планируешь собирать файл в кучу с двух потоков и еще ко всему прочему в нынешней ситуации в сети. ты что же под этот мртср всю инфрасируктуру сети  и стеков переделать хочешь? ты хоть понимаешь что для такого надо как минимум чтобы прокси знал как разбивать куски данных на несколько потоков и нормально их маркировать, чтоб потом собрать воедино? короче минимум у твоей прокси должна быть система маркировки пакетов по типу торрента и на уровне хоста тоже самое, что бы стек мог правильно прочесть маркировку и собрать файл воедино. чем не торрент? в третьих тогда уж надо принудить ютюб чтоб он ввел стандартизацию на разбивку видео на кластеры данных в видео и чтобы это поддерживалось в проге на стооне клиента. тогда да будет существенное повышение производительности загрузки файлов. но .... ты видел волка в бане парившись)))
     
     
  • 7.47, angra (ok), 05:05, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Почитай уже для самообразования https://en.wikipedia.org/wiki/OSI_model
    Оно конечно не ложится напрямую на tcp/ip стек, но хотя бы даст понимание, что такое различные уровни сетевых протоколов.
    А вот когда(или если) разберешься, то перечитай внимательно предыдущий пост, там тебе все доступно объяснили.


     
     
  • 8.50, slavius (?), 09:49, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    увы читал и поэтому говорю модернизировать придется как минимум видеопередачу... текст свёрнут, показать
     
     
  • 9.51, angra (ok), 13:54, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Читал, но ничего не понял Бывает, может еще рано, а может вообще не твое это В... текст свёрнут, показать
     
  • 7.52, Ytch (ok), 23:48, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Подумать всё-таки придется тебе ну или забей и дальше не читай Поток для при... текст свёрнут, показать
     
     
  • 8.53, angra (ok), 02:02, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну ты ему еще мозг взорви рассказом про MTU и фрагментацию пакетов Мало того, ч... текст свёрнут, показать
     
  • 5.39, Аноним (-), 18:39, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > в чем соль пока не понял

    Это точно.

     
  • 2.15, Bobik (?), 14:39, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Нет.
     
     
  • 3.19, Аноним (-), 18:12, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Нет.

    Ламера ответ.

     
  • 2.17, bugmenot (??), 17:46, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да.
     
  • 2.29, Alex (??), 08:07, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Именно так, если на стороне ютуба будет поддержка MPTCP.
     
     
  • 3.40, orgkhnargh (ok), 21:59, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Именно так, если на стороне ютуба будет поддержка MPTCP.

    То есть, работать будет примерно как бондинг, но внешний сервер поднимать отдельно не надо?

     
     
  • 4.41, Alex (??), 22:05, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > То есть, работать будет примерно как бондинг, но внешний сервер поднимать отдельно
    > не надо?

    Это и есть бондинг, только на уровне отдельного виртуального соединения TCP, состоящего фактически из нескольких :)

     
  • 4.42, Alex (??), 22:07, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Если проще - то "да". С некоторыми оговорками, например, что каналы вполне могут быть совершенно разноскоростными и с разным уровнем потерь.
     
     
  • 5.54, Bobik (?), 13:52, 02/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Оговорка одна ютуб ету херню не поддержывает и по етому работать оно не будет, а рассуждать можно много очом.
     

  • 1.20, Аноним (-), 18:54, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    лучше бы sctp внедряли где попало
     
     
  • 2.22, Demo (??), 22:33, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > лучше бы sctp внедряли где попало

    SCTP богомерзкой телефонией попахивает, а это сегодня не в трэнде.

     
     
  • 3.27, Crazy Alex (ok), 01:57, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И правильно, что не в тренде. Телефонисты что-то понятное и удобное в эксплуатации отродясь сделать не могли. И до сих пор не могут - одна идея "телефонного номера" фиксированной длины чего стоит.
     
     
  • 4.28, Ytch (ok), 03:07, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну не совсем так, мягко выражаясь У них было множество весьма неплохих инженерн... текст свёрнут, показать
     
     
  • 5.36, Аноним (-), 15:43, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    X.400 (невзлетевшая типа электропочта), X.500 — это все а) невообразимейший ужас; б)телефонисты. Вы поинтересуйтесь на досуге, какие строковые кодировки для использования в X.509 сертификатах были разрешены (например, здесь: https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt , да там весь документ интересный).
     
     
  • 6.48, t28 (?), 09:28, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > X.400 (невзлетевшая типа электропочта)

    Не надо "ля-ля". Всё работает, где надо.

     
  • 4.31, Alex (??), 08:13, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > И правильно, что не в тренде. Телефонисты что-то понятное и удобное в
    > эксплуатации отродясь сделать не могли. И до сих пор не могут
    > - одна идея "телефонного номера" фиксированной длины чего стоит.

    А то, что у IPv4/v6/Ethernet/whatever адрес фиксированной длины, тебя не смущает?

     
     
  • 5.37, Crazy Alex (ok), 16:01, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не смущает. Это адрес для машины, а не для человека. Вот если бы фиксированной длины (да ещё контекстно-зависимой от моего положения) были имена в скайпе или имена доменов - смущало бы, и ещё как.
     
     
  • 6.43, Alex (??), 22:07, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А для человека у телефонистов есть телефонный справочник. Аналог DNS, по сути. Книжка такая толстая.
     
  • 4.32, Alex (??), 08:14, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кстати в ISDN номера далеко не фиксированной длины.
     
     
  • 5.38, Crazy Alex (ok), 16:03, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И всё равно везде всё прибито гвоздями к номерным планам с фиксированной длиной номера, префиксами выхода и подобной мутью. Хотя, например, доменная система смотрелась бы куда лучше и на современных ресурсах ни малейших проблем по ресурсам не составила бы.
     
     
  • 6.44, Alex (??), 22:09, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И всё равно везде всё прибито гвоздями к номерным планам с фиксированной
    > длиной номера, префиксами выхода и подобной мутью. Хотя, например, доменная система
    > смотрелась бы куда лучше и на современных ресурсах ни малейших проблем
    > по ресурсам не составила бы.

    Ну в интернетах всё прибито к IPv4 фиксированной длины точно так же. С IPv6 всё вообще ужасно, оно ещё и не человеко-запоминаемо. DNS DNS'ом, а прямые адреса вбивать всё равно приходится. Даже ендюзерам иногда.

     
  • 6.49, t28 (?), 09:37, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > И всё равно везде всё прибито гвоздями к номерным планам

    В The Internet-е так же. Адресация гвоздями прибита к Route Database, и пока Regional Registry не заапрувит и не внесёт ваши данные в базу, полноценно пользоваться своими префиксами вы не сможете.

     

  • 1.25, InventoR (??), 23:27, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Мне не интересен трафик, мне интересно, эта штука наконец поможет сбалансировать и сделать отказоустойчивость в managment интерфейсе кластера, пусть даже прокса?

    Строить агрегацию на базе разных свичей обьеденых в стек это безумие, а вот поставить два простых свича и построить managment с этой штукой было бы здорово.

     
     
  • 2.35, Demo (??), 10:48, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Нормальный Management должен быть OOB.
     

  • 1.33, Alex (??), 08:23, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Есть у MPTCP ещё одна хитрость при использовании нескольких операторов: всякие СОРМы и прочие будут ссать кровавыми слезами, потому что трафик собрать воедино скорее всего не получится. А с TLS - еще хуже.
     
     
  • 2.34, Петушок (?), 10:02, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть у MPTCP ещё одна хитрость при использовании нескольких операторов: всякие СОРМы
    > и прочие будут ссать кровавыми слезами, потому что трафик собрать воедино
    > скорее всего не получится. А с TLS - еще хуже.

    Неуловимый, ты никому не нужен

     
     
  • 3.45, Alex (??), 22:10, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Неуловимый, ты никому не нужен

    Мне вообще давно пох, нужен я или нет )

     

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



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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