https://opennet.me/openforum/vsluhforumID3/104912.html После более года разработки для ядра 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).<br><br><br><br>Multipath TCP может использоваться как для расширения пропускной способности, так и для увеличения надёжности. В качестве одного из практических применений Multipath TCP для обычных пользователей упоминается возможность организации передачи дан https://opennet.me/openforum/vsluhforumID3/104912.html#54 Fri, 02 Oct 2015 10:52:03 GMT Оговорка одна ютуб ету херню не поддержывает и по етому работать оно не будет, а рассуждать можно много очом.<br> https://opennet.me/openforum/vsluhforumID3/104912.html#53 Wed, 30 Sep 2015 23:02:47 GMT &gt; А как ты думаешь, сейчас, в рамках одного простого tcp-соединения, данные разбиваются? <br>&gt; А маркируются? Хинт: tcp умеет собирать в целостный поток пакеты, пришедшие <br>&gt; не в том порядке. И это там с самого начала так, <br>&gt; by design. Поясню: передающее приложение отправило пакеты 1, 2, 3; на <br>&gt; приемный комп они пришли в таком порядке - 1, 3, 2; <br>&gt; принимающее приложение получит 1, 2, 3 (как и было отправлено). Так <br>&gt; оно работает уже сейчас. Ещё один хинт: данные между приложениями (и <br>&gt; между несколькими соединениями одного приложения), кстати, тоже каким-то чудом не перепутываются. <br><br>Ну ты ему еще мозг взорви рассказом про MTU и фрагментацию пакетов. Мало того, что пакеты могут приходить не в том порядке, так еще и разорванными на части, которые тоже в свою очередь могут прийти не в том порядке. Не забудем, что пакеты или фрагменты могут биться или теряться в процессе пересылки и происходит ретрансмиссия, опять нарушая порядок. И все это без каких-либо торрентов собирается воедино уже десятки лет и https://opennet.me/openforum/vsluhforumID3/104912.html#52 Wed, 30 Sep 2015 20:48:22 GMT &gt; а теперь подумай хорошенько и скажи как ты планируешь собирать файл в <br>&gt; кучу с двух потоков и еще ко всему прочему в нынешней <br>&gt; ситуации в сети.<br><br>Подумать всё-таки придется тебе (ну или забей и дальше не читай). Поток (для приложения, что сервера, что клиента) будет один(!). В этом суть выигрыша от технологии mptcp.<br><br>&gt; ты что же под этот мртср всю инфрасируктуру <br>&gt; сети и стеков переделать хочешь? <br><br>Тебе не зря намекали чуть выше почитать про стек протоколов, модель OSI и все такое. Тут дополняется ТОЛЬКО протокол транспортного уровня (tcp), протоколы всех остальных уровней (и выше и ниже) не затрагиваются (от слова совсем). Никакая "инфраструктура" не пострадает. <br><br>&gt; ты хоть понимаешь что для <br>&gt; такого надо как минимум чтобы прокси знал как разбивать куски данных <br>&gt; на несколько потоков и нормально их маркировать, чтоб потом собрать воедино?<br><br>А как ты думаешь, сейчас, в рамках одного простого tcp-соединения, данные разбиваются? А маркируются? Хинт: tcp умеет собирать в целостный поток пакеты https://opennet.me/openforum/vsluhforumID3/104912.html#51 Wed, 30 Sep 2015 10:54:48 GMT Читал, но ничего не понял? Бывает, может еще рано, а может вообще не твое это. В таком случае я бы посоветовал не влезать в дискуссии на тему сетевых протоколов, рассуждай о том, в чем разбираешься.<br> https://opennet.me/openforum/vsluhforumID3/104912.html#50 Wed, 30 Sep 2015 06:49:28 GMT увы читал)) и поэтому говорю. модернизировать придется как минимум видеопередачу или так любимый тобой прокси. иначе никак.<br> https://opennet.me/openforum/vsluhforumID3/104912.html#49 Wed, 30 Sep 2015 06:37:01 GMT &gt; И всё равно везде всё прибито гвоздями к номерным планам<br><br>В The Internet-е так же. Адресация гвоздями прибита к Route Database, и пока Regional Registry не заапрувит и не внесёт ваши данные в базу, полноценно пользоваться своими префиксами вы не сможете.<br> https://opennet.me/openforum/vsluhforumID3/104912.html#48 Wed, 30 Sep 2015 06:28:27 GMT &gt; X.400 (невзлетевшая типа электропочта)<br><br>Не надо "ля-ля". Всё работает, где надо.<br> https://opennet.me/openforum/vsluhforumID3/104912.html#47 Wed, 30 Sep 2015 02:05:37 GMT Почитай уже для самообразования https://en.wikipedia.org/wiki/OSI_model<br>Оно конечно не ложится напрямую на tcp/ip стек, но хотя бы даст понимание, что такое различные уровни сетевых протоколов. <br>А вот когда(или если) разберешься, то перечитай внимательно предыдущий пост, там тебе все доступно объяснили.<br> <br><br><br> https://opennet.me/openforum/vsluhforumID3/104912.html#46 Tue, 29 Sep 2015 22:08:29 GMT а теперь подумай хорошенько и скажи как ты планируешь собирать файл в кучу с двух потоков и еще ко всему прочему в нынешней ситуации в сети. ты что же под этот мртср всю инфрасируктуру сети и стеков переделать хочешь? ты хоть понимаешь что для такого надо как минимум чтобы прокси знал как разбивать куски данных на несколько потоков и нормально их маркировать, чтоб потом собрать воедино? короче минимум у твоей прокси должна быть система маркировки пакетов по типу торрента и на уровне хоста тоже самое, что бы стек мог правильно прочесть маркировку и собрать файл воедино. чем не торрент? в третьих тогда уж надо принудить ютюб чтоб он ввел стандартизацию на разбивку видео на кластеры данных в видео и чтобы это поддерживалось в проге на стооне клиента. тогда да будет существенное повышение производительности загрузки файлов. но .... ты видел волка в бане парившись)))<br>