После года разработки представлена (https://multipath-tcp.org/pmwiki.php?n=Main.Release91) новая версия (0.91) расширения MPTCP (http://multipath-tcp.org) (MultiPath TCP) для ядра Linux, которое позволяет организовать (http://multipath-tcp.org/pmwiki.php/Users/ConfigureRouting) работу TCP-соединения с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам. Для сетевых приложений подобное агрегированное соединение выглядит как обычное TCP-соединение, вся логика разделения потоков выполняется силами MPTCP. Новая версия выполнена в виде патча для ядра Linux 4.1 LTS. Бинарные пакеты собраны (http://multipath-tcp.org/pmwiki.php?n=Users.AptRepository) для Ubuntu 14.04 и Debian Jessie.Multipath TCP может использоваться как для расширения пропускной способности, так и для увеличения надёжности. В качестве одного из практических применений Multipath TCP для обычных пользователей упоминается возможность организации передачи данных на смартфоне с использованием одновременно линков WiFi и 3G. Для серверных систем Multipath TCP может обеспечить сокращение расходов за счёт использования нескольких дешевых линков вместо одного более дорогого.
В новой версии:
- Добавлена поддержка опции ADD_ADDR2, определённой в черновом варианте спецификации RFC6824bis (https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-05) (TCP Extensions for Multipath Operation with Multiple Addresses). Для использования ADD_ADDR2 требуется изменить значение версии MPTCP через "sysctl net.mptcp.mptcp_version=1", но поддержка RFC6824bis пока реализована не полностью и не рекомендуется для промышленного использования;
- Представлен отказоустойчивый планировщик MPTCP, позволяющий сократить задержки и повысить однородность потока (jitter). Отказоустойчивость обеспечивается через дублирование всего трафика на всех доступных каналах. Для включения нового планировщика следует установить sysctl net.mptcp.mptcp_scheduler в значение "redundant";
- Внесена серия оптимизаций производительности и исправлений ошибок;
- Проведена синхронизация с кодовой базой новых выпусков ядра Linux.
URL: https://multipath-tcp.org/pmwiki.php?n=Main.Release91
Новость: https://www.opennet.ru/opennews/art.shtml?num=45037
Уже больше года применяем на очень высоконагруженном проекте, гоняем по 4-м гигабитным интерфейсам метаданные CephRBD.. Респект ребятам, проблем нет!
> Уже больше года применяем на очень высоконагруженном проекте, гоняем по 4-м гигабитным
> интерфейсам метаданные CephRBD.. Респект ребятам, проблем нет!LACP не пробовали?
>> Уже больше года применяем на очень высоконагруженном проекте, гоняем по 4-м гигабитным
>> интерфейсам метаданные CephRBD.. Респект ребятам, проблем нет!
> LACP не пробовали?Конечно же, но производительность на 30% оказалась хуже!
А не брешешь ли ты, мил человек?
> А не брешешь ли ты, мил человек?Брешет, как Троцкий. А вообще прикольно - изобрести мультипасинг в 2016м году, когда на нормальных осях он уже 20 с лишним лет как существует.
Не уподобляйся! Столько он даже в Соляре _НЕ_ существует.PS: Кстати - то что сделали в Линуксе ... с Cолярным IPMP не совместимо :-\
Solaris IPMP больше похож на HSRP или GLBP, чем на Multipath TCP.
>> А не брешешь ли ты, мил человек?
> Брешет, как Троцкий. А вообще прикольно - изобрести мультипасинг в 2016м году,
> когда на нормальных осях он уже 20 с лишним лет как
> существует.Что за нормальный ОС и о каком multipath идёт речь? Уточню вопрос, где именно реализован ещё TCP Multipath?
> Уже больше года применяем на очень высоконагруженном проекте, гоняем по 4-м гигабитным
> интерфейсам метаданные CephRBD.. Респект ребятам, проблем нет!Простите, а не пробовали 10G интерфейс применить? Может, он и не нужно бы стало...
Что за высоконагруженный проэкт на гигабите, когда китайцы уже 100G сетевые модули вживую предлагают?
А что в апстрим не берут?
Я ядре и так очень много костылей, зачем еще один!
Пан Аноним - эксперт по ядру Linux.
> зачем еще одинДля mptcp ?
Кэп!
Брехня
Судя по всему, они не заинтересованы пилить это для последнего ядра. Либо ресурсов нет.Ну т.е. если ты начинаешь вмерживать что-то в ядро, то в LTS-выпуск оно попадет через год, а к моменту допиливания до продакшон-реди состояния только к следующему LTS еще через год.
Короче, нет смысла.
> Короче, нет смысла.Почему нет смысла? Через год планета Нибиру? или что такого случится через год что вдруг mptcp станет неактуальным?
Сначала спутал с kernel connection multiplexer (KCM) https://lwn.net/Articles/657999/ , тоже интересная штука
Эта технология как-то может затруднить отслеживание активности пользователей в интернете?
сомневаюсь что сильно поможет. пакеты все равно на твой ip пойдут. ну можно также проксики задействовать. но знаешь и это не гарант.
там вопрос в случае если 2..n link-ов.
А как же sctp? Раз в виндовсе его нет, то и партнёры микрософта его забросят?
А он вообще где-то живьём есть? В смысле - чтобы использовался.
Дык отец и несомненный лидер мирового опенсорца нишмог его ни из какого бсд слизать, потому и не используется. Как и сабж нигде использоваться не будет.
> А он вообще где-то живьём есть? В смысле - чтобы использовался.Используется, и довольно давно — для SIGTRAN (для чего и задумывался, собственно).
А на вопрос то слабо ответить? Ну да на тот, неприятный, простой как топор: "А он вообще где-то живьём есть? В смысле - чтобы использовался."
Ясно - понятно :-\
это Другое и для других применений.
mptcp - это как для балансирования tcp (как по хардверу, так и по интерфейсам) а также для мобильных сетей с Мягким handover-ом/роумингом а также mesh/ad-hoс сетей.
stcp интересен в мэйнстриме и секьюрнее но на него "забили" равно как и на dctcp. к сожалению.
Когда ждать в убунтовском нетворк-менеджере? Или это опять для гиков, а всем домохозякам на винде оставаться?
> Когда ждать в убунтовском нетворк-менеджере? Или это опять для гиков, а всем
> домохозякам на винде оставаться?ненавидишь домохозяек и хочешь, чтобы они с хипстерскими сетевыми стеками пердолились вместо мытья посуды и смотрения телевизира?