После более года разработки для ядра Linux доступна (http://multipath-tcp.org/pmwiki.php?n=Main.Release90) новая версия (0.90) расширения MPTCP (http://multipath-tcp.org) (MultiPath TCP), которое позволяет организовать (http://multipath-tcp.org/pmwiki.php/Users/ConfigureRouting) работу TCP-соединения с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам. Для сетевых приложений подобное агрегированное соединение выглядит как обычное TCP-соединение, вся логика разделения потоков выполняется силами MPTCP. Новая версия выполнена в виде патча для ядра Linux 3.18. Бинарные пакеты собраны (http://multipath-tcp.org/pmwiki.php?n=Users.AptRepository) для Ubuntu 14.04 (amd64) и Debian Squeeze (amd64, i386).Multipath TCP может использоваться как для расширения пропускной способности, так и для увеличения надёжности. В качестве одного из практических применений Multipath TCP для обычных пользователей упоминается возможность организации передачи данных на смартфоне, с использованием одновременно линков WiFi и 3G. Для серверных систем Multipath TCP может обеспечить сокращение расходов за счёт использования нескольких дешевых линков вместо одного более дорогого.
В новой версии:
- В состав включен алгоритм управления перегрузкой TCP Balia (https://tools.ietf.org/html/draft-walid-mptcp-congestion-con...) (Balanced Linked Adaptation Congestion Control Algorithm), специально реализованный для MPTCP и учитывающий балансировку потока через несколько разнородных линков;
- Добавлена поддержка режима быстрого открытия TCP-соединений FastOpen (https://tools.ietf.org/html/draft-barre-mptcp-tfo-01) для Multipath TCP. TCP FastOpen позволяет сократить число шагов установки соединения за счёт комбинирования в один запрос первого и второго шагов классического 3-этапного процесса согласования соединения, и давая возможность отправки данных на начальном этапе установки соединения (данные посылаются одновременно с SYN-сегментом);
- Улучшена поддержка опций настройки TCP-сокета;
- Возможность настройки метода контроля перегрузки для отдельных потоков через опцию настройки сокета TCP_CONGESTION;
- Поддержка неотслеживаемой (stateless) установки соединений (например, TCP SYN-Cookies);
- Возможность использования TCP SYN-Cookies для защиты web-серверов от SYN-флуда;
- Добавлены дополнительные счётчики MIB/SNMP для статистики и отладки;
- Поддержка мониторинга за состоянием MPTCP через команду "netstat -s" (требуется установка модифицированной версии (http://multipath-tcp.org/pmwiki.php/Users/Tools) пакета net-tools);
- Проведение работы по оптимизации производительности.URL: http://multipath-tcp.org/pmwiki.php?n=Main.Release90
Новость: https://www.opennet.ru/opennews/art.shtml?num=43054
>>> давая возможность отправки данных на начальном этапе установки соединения (данные посылаются одновременно с SYN-сегментом);отличная дыра для ddos. теперь серверу мало того, что надо будет открыть соединение - так еще и обработать что находится внутри пакета.
ЭТО (tcp fast open) уже относительно есть в классическом tcp, и даже работает, и даже дефолтно.
http://kernelnewbies.org/Linux_3.13#head-159ff61ea3acfd67b88...
> ЭТО (tcp fast open) уже относительно есть в классическом tcp, и даже
> работает, и даже дефолтно.
> http://kernelnewbies.org/Linux_3.13#head-159ff61ea3acfd67b88...ну подобное нужно для real-time систем. на кой оно по дефолту не понятно
то есть пользователи не real-time -- должны страдать? :-)
Если он сам хочет страдать - никакое отсутствие fast-open ему помешать не в силах.
А в меинлаин не хотят впихнуть?
в смысле, в основном ядре этого разве нет?
MPTCP? Пока нет. Вообще штука очень интересная, особенно с учётом того, что даёт возможность очень просто строить распределённую балансировку.
>с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы,Ы, "нафейхуа" - одновременно ?
...схоже, на попытку выбивания и освоения грантофф - пeреизобрeтением SСTР
Утверждается, что оно лучше работает с ущербными роутерами и файрволлами, не знающими ни о чем, кроме TCP и UDP
Вот поэтому в Интернете всё как-то кривенько и через ж…Напомнило как мы долго бились с проблемой невозможности связать через Watson-овские бриджи рабочую станцию управления с STM-1 мультиками, хотя локально по 10BASE-2 всё летало "на ура!". В итоге, через пол-дня разбирательств, выяснилось, что все Ethertype-ы кроме IP отфильтровывались бриджами как некорректные. Видимо инженеры Watson-а о CLNP и слыхом не слыхивали. Да что тут говорить о CLNP, если IPX им тоже не знаком. Выросло поколение инженеров, не знающих ничего, кроме IP, будто и не было ничего ни до ни после…
То есть, если у меня есть 2 свистка по 2 мегабита от разных операторов, то с помощью MPTCP я смогу получить 4 мегабита вкупе и можно будет качество видео на ютубе повыше сделать?
а ты ютубу сначала скажи что ты качаешь в два свистка)) да и повозись чтоб это все собиралось в один файл и кормилось твоему плееру. нет конечно можно наваять скрипт на коленке, но боюсь что скриптик получится не маленький. придется делать что то типа торрента. кстати для торрента должно быть неплохо. опять же надо проверять.
А разве не в этом смысл MultiPath TCP, чтобы снять эту работу с приклада?
«Для сетевых приложений подобное агрегированное соединение выглядит как обычное TCP-соединение, вся логика разделения потоков выполняется силами MPTCP.»Никому ничего объяснять не надо. Главное, чтобы Ютуб понимал MPTCP, но это можно решить при помощи промежуточного прокси-сервера.
а ты подумал че сказал? ты каким макаром собрался объяснить ютубу что ты качаешь с одного компа но в два потока.? он то увидит 2 ip? и ко всему прочему надо чтоб ютуб отдавал данные пачками и это все дело маркировалось по положению в файле, точь в точь как торрент, или ты собрался смотреть 2 версии одного и того же через свой плеер? тогда в чем суть. что один канал что 2.
Самовыпились, а. MPTCP именно тем и занимается, что изолирует многоканальность от приложения. Приложение 2 IP не увидит, а вот MPTCP - увидит.
еще добавлю прокси сервер тебе не разделит потоки и он же создаст ситуацию при которой один поток останется не у дел. фишка в том и есть что с одного компа норазных сетевух и разных ip/ нафига копья ломать тогда, сразу увеличил скорость и все. а вот торрент из этого действительно пользу извлечет. и вообще чисто сетевые проги , работающие на скачку. опять же будет разве что возможность распределения мощностей, но это и раньше можно было сделать при наличии двух сетевух и ip. в чем соль пока не понял, для просмотра видео её пока точно нет.
> еще добавлю прокси сервер тебе не разделит потокиЧто ему помешает? Из примера выше - прокси сидит, к примеру, на 10 мегабитном канале до ютуба и оттуда тянет "классически". Одновременно он "знает", что этот контент надо отдавать как multipath на ip1 и ip2, но это одно и то же логическое tcp-соединение (прокси, само собой, multipath должен поддерживать). Почему он не сможет задействовать 2 канала по 2 мегабита (ip1 и ip2) для отдачи того что тянет по 10 мегабитному с ютуба тем самым вдвое поднимая скорость скачивания видео с точки зрения клиента?
Грубо и крайне упрощенно - почему он не может кидать последовательные куски данных, приходящих с ютуба попеременно то на ip1, то на ip2. Всё что нужно ему "понимать", что ack приходящие и c ip1 и с ip2 в рамках этого соединения это один и тот же "интегральный" ack. Посылает seq1 на ip1, seq2 на ip2, seq3 на ip1 (несмотря на то что seq2 туда не отправлялся), seq4 на ip2 (несмотря на то что seq3 туда не отправлялся) - главное, что если, к примеру придет ack4 c ip2, то он должен "понять", что это подтверждение всем seq1-4 независимо от того куда те были отправлены. При этом загружены оба канала, то есть пропускная способность выросла вдвое (для ясности не будем рассматривать "неодинаковость" каналов, пропадания пакетов и прочую классическую сетевую муть, с которой все это естсественно справляется). Это очень-очень упрощенно, естественно.
И нет никакой разницы видео это или ещё что-то, в одну сторону или в обе сразу идет передача, и даже вообще не важно что за протокол работает поверх tcp.
> нафига копья ломать тогда, сразу увеличил скорость и все.
А, так можно просто поднять скорость канала и всех делов? Как просто все решается...
> а вот торрент из этого действительно пользу извлечет
Торрент и так может извлечь пользу из наличия двух каналов безо всяких MultipathTCP - ему, по самой его сути, не надо брать данные из одного соединения. Как и простое скачивание с http (при помощи range) тоже может и без этих фокусов с MultipathTCP загрузить 2 независимых канала скачиванием разных частей одного и того же без необходимости вообще модифицировать сервер. Это как раз случаи когда от MultipathTCP ни холодно ни жарко с точки зрения загрузки канала(ов). Фишка в том что тут потенциально можно так использовать вообще любой протокол поверх tcp причем вообше незаметно для прикладухи.
> это и раньше можно было сделать при наличии двух сетевух и ip.
Разных ip. В разных сетях. И при этом получается (для клиента) одно(!) tcp-соединение, что позволяет использовать существующие протоколы поверх tcp, даже не предполагающие множественных подключений к одним и тем же данным.
а теперь подумай хорошенько и скажи как ты планируешь собирать файл в кучу с двух потоков и еще ко всему прочему в нынешней ситуации в сети. ты что же под этот мртср всю инфрасируктуру сети и стеков переделать хочешь? ты хоть понимаешь что для такого надо как минимум чтобы прокси знал как разбивать куски данных на несколько потоков и нормально их маркировать, чтоб потом собрать воедино? короче минимум у твоей прокси должна быть система маркировки пакетов по типу торрента и на уровне хоста тоже самое, что бы стек мог правильно прочесть маркировку и собрать файл воедино. чем не торрент? в третьих тогда уж надо принудить ютюб чтоб он ввел стандартизацию на разбивку видео на кластеры данных в видео и чтобы это поддерживалось в проге на стооне клиента. тогда да будет существенное повышение производительности загрузки файлов. но .... ты видел волка в бане парившись)))
Почитай уже для самообразования https://en.wikipedia.org/wiki/OSI_model
Оно конечно не ложится напрямую на tcp/ip стек, но хотя бы даст понимание, что такое различные уровни сетевых протоколов.
А вот когда(или если) разберешься, то перечитай внимательно предыдущий пост, там тебе все доступно объяснили.
увы читал)) и поэтому говорю. модернизировать придется как минимум видеопередачу или так любимый тобой прокси. иначе никак.
Читал, но ничего не понял? Бывает, может еще рано, а может вообще не твое это. В таком случае я бы посоветовал не влезать в дискуссии на тему сетевых протоколов, рассуждай о том, в чем разбираешься.
> а теперь подумай хорошенько и скажи как ты планируешь собирать файл в
> кучу с двух потоков и еще ко всему прочему в нынешней
> ситуации в сети.Подумать всё-таки придется тебе (ну или забей и дальше не читай). Поток (для приложения, что сервера, что клиента) будет один(!). В этом суть выигрыша от технологии mptcp.
> ты что же под этот мртср всю инфрасируктуру
> сети и стеков переделать хочешь?Тебе не зря намекали чуть выше почитать про стек протоколов, модель OSI и все такое. Тут дополняется ТОЛЬКО протокол транспортного уровня (tcp), протоколы всех остальных уровней (и выше и ниже) не затрагиваются (от слова совсем). Никакая "инфраструктура" не пострадает.
> ты хоть понимаешь что для
> такого надо как минимум чтобы прокси знал как разбивать куски данных
> на несколько потоков и нормально их маркировать, чтоб потом собрать воедино?А как ты думаешь, сейчас, в рамках одного простого tcp-соединения, данные разбиваются? А маркируются? Хинт: tcp умеет собирать в целостный поток пакеты, пришедшие не в том порядке. И это там с самого начала так, by design. Поясню: передающее приложение отправило пакеты 1, 2, 3; на приемный комп они пришли в таком порядке - 1, 3, 2; принимающее приложение получит 1, 2, 3 (как и было отправлено). Так оно работает уже сейчас. Ещё один хинт: данные между приложениями (и между несколькими соединениями одного приложения), кстати, тоже каким-то чудом не перепутываются.
> короче минимум у твоей прокси должна быть система маркировки пакетов по
> типу торрента и на уровне хоста тоже самое, что бы стек
> мог правильно прочесть маркировку и собрать файл воедино. чем не торрент?Тем, что торрент работает уровнем выше. И вот чтоб по аналогии работали другие приложения их надо серьезно перерабатывать (и клиенты и серверы). А с MPTCP они смогут (условно) также, но их не надо будет даже перекомпилировать.
> в третьих тогда уж надо принудить ютюб чтоб он ввел стандартизацию
> на разбивку видео на кластеры данных в видео и чтобы это
> поддерживалось в проге на стооне клиента.Это было б надо если б узким местом были серверы и балансировщики гугла или каналы непосредственно к ним подходящие. Но скорости ограничиваются не там, а обычно гораздо ближе к клиенту. Поэтому достаточно распараллелить поток по разным каналам (причем его снова можно собрать в один позже и ускорение все равно будет). Так что от гугла ничего подобного не требуется, а распараллелить все равно получится. Можешь считать это колдунством, но достаточно чтоб ядро ОС где крутится сервер и на клиенте поддерживало MPTCP. Либо в ядре ОС прокси сервера (само приложение прокси сервера тоже может оставаться без изменений) и ядре ОС клиента.
> А как ты думаешь, сейчас, в рамках одного простого tcp-соединения, данные разбиваются?
> А маркируются? Хинт: tcp умеет собирать в целостный поток пакеты, пришедшие
> не в том порядке. И это там с самого начала так,
> by design. Поясню: передающее приложение отправило пакеты 1, 2, 3; на
> приемный комп они пришли в таком порядке - 1, 3, 2;
> принимающее приложение получит 1, 2, 3 (как и было отправлено). Так
> оно работает уже сейчас. Ещё один хинт: данные между приложениями (и
> между несколькими соединениями одного приложения), кстати, тоже каким-то чудом не перепутываются.Ну ты ему еще мозг взорви рассказом про MTU и фрагментацию пакетов. Мало того, что пакеты могут приходить не в том порядке, так еще и разорванными на части, которые тоже в свою очередь могут прийти не в том порядке. Не забудем, что пакеты или фрагменты могут биться или теряться в процессе пересылки и происходит ретрансмиссия, опять нарушая порядок. И все это без каких-либо торрентов собирается воедино уже десятки лет и приложений этот процесс вообще не касается. Черная магия, не иначе.
> в чем соль пока не понялЭто точно.
Нет.
> Нет.Ламера ответ.
Да.
Именно так, если на стороне ютуба будет поддержка MPTCP.
> Именно так, если на стороне ютуба будет поддержка MPTCP.То есть, работать будет примерно как бондинг, но внешний сервер поднимать отдельно не надо?
> То есть, работать будет примерно как бондинг, но внешний сервер поднимать отдельно
> не надо?Это и есть бондинг, только на уровне отдельного виртуального соединения TCP, состоящего фактически из нескольких :)
Если проще - то "да". С некоторыми оговорками, например, что каналы вполне могут быть совершенно разноскоростными и с разным уровнем потерь.
Оговорка одна ютуб ету херню не поддержывает и по етому работать оно не будет, а рассуждать можно много очом.
лучше бы sctp внедряли где попало
> лучше бы sctp внедряли где попалоSCTP богомерзкой телефонией попахивает, а это сегодня не в трэнде.
И правильно, что не в тренде. Телефонисты что-то понятное и удобное в эксплуатации отродясь сделать не могли. И до сих пор не могут - одна идея "телефонного номера" фиксированной длины чего стоит.
> Телефонисты что-то понятное и удобное в
> эксплуатации отродясь сделать не могли.Ну не совсем так, мягко выражаясь. У них было множество весьма неплохих инженерных решений на разных этапах развития (последние пару десятилетий не считаем). Вообще, по моим наблюдениям, они делают что-то хорошее и остроумное только при очень ограниченных технических ресурсах. Когда они переходили на цифру и цифровые мультиплексирования разных поколений в разное время все ещё было неплохо и с идеями и с реализациями, но речь тогда шла про "их епархию" - коммутацию каналов, хоть и в цифре. Да и вычислиловка ещё была слабовата и дороговата - приходилось думать. Хотя склонности к лютому overengineering'у у них всегда проявлялись, но технические возможности их как-то сдерживали и было более или менее норм (я сейчас про чисто технические, инжернерные решения - не касаясь инфраструктурных дел и всякого прочего).
Вот когда они полезли в сети с коммутацией пакетов и вычислительные ресурсы стали позволять не особо проявлять инженерную смекалку, тут да, их прорвало и из них поперли тонны откровенно переусложненного и дико неудобного г$*на (в смысле предлагаемых решений). И тут всем на руку оказалось что на этом поле не они одни могут играть.> И до сих пор не могут
Вот сейчас, в последние лет примерно 20 - да, соглашусь. Сплошной шлак какой-то.
> - одна идея "телефонного номера" фиксированной длины чего стоит.
Ну, во-первых, это традиция и это (было)удобно и людям и технически (ещё со времен шаговых искателей), а во-вторых, это, извините, неправда и очень давно (номерам 01, 02, 03..., например, "сто лет в обед"). Для широкого круга, да, они это не делали в разное время по разным причинам - да и сейчас не факт что большинство с энтузиазмом воспримет идею - они вынуждены рассчитывать и на бабушек в том числе, а уж в этой среде традиции ого-го как сильны )), даже несмотря на то, что некоторые "продвинутые" бабушки вполне себе, например, справляются со skype, но юмор в изменении принципов формирования телефонных номеров вряд ли оценят. С мобильными ещё как-то можно было б, но там фиксированные длины номеров это уже такая мелочь по сравнению с остальным дерьмом "под капотом". Да и нет у "телефонистов" уже той "власти" над "умами и коммуникациями" (и это хорошо, имхо) - подобные трюки лет 15-20 назад они ещё может и могли б провернуть, а сейчас я сильно сомневаюсь.
X.400 (невзлетевшая типа электропочта), X.500 — это все а) невообразимейший ужас; б)телефонисты. Вы поинтересуйтесь на досуге, какие строковые кодировки для использования в X.509 сертификатах были разрешены (например, здесь: https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt , да там весь документ интересный).
> X.400 (невзлетевшая типа электропочта)Не надо "ля-ля". Всё работает, где надо.
> И правильно, что не в тренде. Телефонисты что-то понятное и удобное в
> эксплуатации отродясь сделать не могли. И до сих пор не могут
> - одна идея "телефонного номера" фиксированной длины чего стоит.А то, что у IPv4/v6/Ethernet/whatever адрес фиксированной длины, тебя не смущает?
Не смущает. Это адрес для машины, а не для человека. Вот если бы фиксированной длины (да ещё контекстно-зависимой от моего положения) были имена в скайпе или имена доменов - смущало бы, и ещё как.
А для человека у телефонистов есть телефонный справочник. Аналог DNS, по сути. Книжка такая толстая.
Кстати в ISDN номера далеко не фиксированной длины.
И всё равно везде всё прибито гвоздями к номерным планам с фиксированной длиной номера, префиксами выхода и подобной мутью. Хотя, например, доменная система смотрелась бы куда лучше и на современных ресурсах ни малейших проблем по ресурсам не составила бы.
> И всё равно везде всё прибито гвоздями к номерным планам с фиксированной
> длиной номера, префиксами выхода и подобной мутью. Хотя, например, доменная система
> смотрелась бы куда лучше и на современных ресурсах ни малейших проблем
> по ресурсам не составила бы.Ну в интернетах всё прибито к IPv4 фиксированной длины точно так же. С IPv6 всё вообще ужасно, оно ещё и не человеко-запоминаемо. DNS DNS'ом, а прямые адреса вбивать всё равно приходится. Даже ендюзерам иногда.
> И всё равно везде всё прибито гвоздями к номерным планамВ The Internet-е так же. Адресация гвоздями прибита к Route Database, и пока Regional Registry не заапрувит и не внесёт ваши данные в базу, полноценно пользоваться своими префиксами вы не сможете.
Мне не интересен трафик, мне интересно, эта штука наконец поможет сбалансировать и сделать отказоустойчивость в managment интерфейсе кластера, пусть даже прокса?Строить агрегацию на базе разных свичей обьеденых в стек это безумие, а вот поставить два простых свича и построить managment с этой штукой было бы здорово.
Нормальный Management должен быть OOB.
Есть у MPTCP ещё одна хитрость при использовании нескольких операторов: всякие СОРМы и прочие будут ссать кровавыми слезами, потому что трафик собрать воедино скорее всего не получится. А с TLS - еще хуже.
> Есть у MPTCP ещё одна хитрость при использовании нескольких операторов: всякие СОРМы
> и прочие будут ссать кровавыми слезами, потому что трафик собрать воедино
> скорее всего не получится. А с TLS - еще хуже.Неуловимый, ты никому не нужен
> Неуловимый, ты никому не нуженМне вообще давно пох, нужен я или нет )