https://www.opennet.me/openforum/vsluhforumID3/91046.html Для ядра 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.<br><br><br>Multipath TCP может использоваться как для расширения пропускной способности, так и для увеличения надёжности. В качестве одного из практических применений Multipath TCP для обычных пользователей упоминается возможность организации передачи данных на смартфоне, с использованием одновременно линков WiFi и 3G. Для серверных систем Multipath TCP может обеспечить сокращение расходов за счёт использования нескольких дешевых линков вместо одного более дорогого. <br><br><br>Новая вер https://www.opennet.me/openforum/vsluhforumID3/91046.html#51 Sun, 18 Aug 2013 21:23:31 GMT а какие уже изобретённые Вы знаете?<br> https://www.opennet.me/openforum/vsluhforumID3/91046.html#50 Mon, 05 Aug 2013 06:08:49 GMT Да что вы говорите, ну приведите хотя бы простенький пример. Где для передачи будет использоваться одновременно более 1 линка. Этот ipmp failover-ный. А про то, о чем вы говорите это agregation, нормально работающий начиная с 10ки<br> https://www.opennet.me/openforum/vsluhforumID3/91046.html#49 Sun, 04 Aug 2013 12:37:36 GMT Они изобрели заново мультиплексор для TCP ?<br> https://www.opennet.me/openforum/vsluhforumID3/91046.html#48 Thu, 01 Aug 2013 04:12:07 GMT согласен<br><br> https://www.opennet.me/openforum/vsluhforumID3/91046.html#47 Wed, 31 Jul 2013 12:37:25 GMT &gt;CBQ/HTB/HFSC/SFB/SFQ/TEQL/QFQ<br><br>Зачем тогда сам пишешь про все эти планировщики очередей пакетов, используемых для QoS?<br><br>Открой исходники ядра хотя бы, кроме WRR других алгоритмов балансировки маршрутов нет.<br> https://www.opennet.me/openforum/vsluhforumID3/91046.html#46 Wed, 31 Jul 2013 11:24:31 GMT &gt; Вон "очевидный ответ" в виде IPv6 уже соорудили "с нуля". Да так, <br>&gt; что почти 20 лет уже в обед, а внедрения всё нет.<br><br>IPv6 тормозится из-за существующей инфраструктуры роутинга с NAT, которой "всем достаточно" и ничего нового больше не нужно. Вложения в IPv4/NAT уже сто раз себя окупили и дадут ещё подзаработать не одному поколению админов-сетевиков. А вот инвестиции в IPv6 ещё не определены толком, кому-чего давать, чтобы хорошо и долго работало &#8212; NAT IPv4 стала преградой для продвижения IPv6 вследствие своей "кормушечной" природы (многие от наличия NAT кормятся и, кстати, не без успеха проталкивают эту ненужность в IPv6). ;)<br><br> https://www.opennet.me/openforum/vsluhforumID3/91046.html#45 Tue, 30 Jul 2013 22:49:46 GMT Планировщик пакетов и QoS ваще в разных измерения живут. <br>Хотя да, для юзера Интернет и Браузер - это одна х...я.<br><br><br> https://www.opennet.me/openforum/vsluhforumID3/91046.html#44 Tue, 30 Jul 2013 20:18:51 GMT по дизайну решения и по самому подходу к и (декларируемому)решению - читый 1992 год.<br>лютый засил irc и без http 0.9 ишшо. все дружно юзают Gopher, UUCP и AOL/Prodigy/MSDN<br> https://www.opennet.me/openforum/vsluhforumID3/91046.html#40 Tue, 30 Jul 2013 18:20:58 GMT Вон "очевидный ответ" в виде IPv6 уже соорудили "с нуля". Да так, что почти 20 лет уже в обед, а внедрения всё нет.<br>