> еще добавлю прокси сервер тебе не разделит потокиЧто ему помешает? Из примера выше - прокси сидит, к примеру, на 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, даже не предполагающие множественных подключений к одним и тем же данным.
