| 1.1, Snaut (ok), 11:10, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –7 +/– |
 >>> давая возможность отправки данных на начальном этапе установки соединения (данные посылаются одновременно с SYN-сегментом);
отличная дыра для ddos. теперь серверу мало того, что надо будет открыть соединение - так еще и обработать что находится внутри пакета.
| | |
| |
| |
| |
| 4.8, XXasd (?), 12:39, 28/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
то есть пользователи не real-time -- должны страдать? :-)
| | |
| |
| 5.10, Аноним (-), 12:47, 28/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если он сам хочет страдать - никакое отсутствие fast-open ему помешать не в силах.
| | |
|
|
|
|
| |
| 2.7, Alex (??), 11:57, 28/09/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
MPTCP? Пока нет. Вообще штука очень интересная, особенно с учётом того, что даёт возможность очень просто строить распределённую балансировку.
| | |
|
| 1.9, fail (?), 12:43, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– | |
>с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы,
Ы, "нафейхуа" - одновременно ?
| | |
| 1.11, fail (?), 12:47, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
...схоже, на попытку выбивания и освоения грантофф - пeреизобрeтением SСTР
| | |
| |
| 2.12, anonymous (??), 13:09, 28/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
Утверждается, что оно лучше работает с ущербными роутерами и файрволлами, не знающими ни о чем, кроме TCP и UDP
| | |
| |
| 3.21, Demo (??), 22:30, 28/09/2015 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Вот поэтому в Интернете всё как-то кривенько и через ж…
Напомнило как мы долго бились с проблемой невозможности связать через Watson-овские бриджи рабочую станцию управления с STM-1 мультиками, хотя локально по 10BASE-2 всё летало "на ура!". В итоге, через пол-дня разбирательств, выяснилось, что все Ethertype-ы кроме IP отфильтровывались бриджами как некорректные. Видимо инженеры Watson-а о CLNP и слыхом не слыхивали. Да что тут говорить о CLNP, если IPX им тоже не знаком. Выросло поколение инженеров, не знающих ничего, кроме IP, будто и не было ничего ни до ни после…
| | |
|
|
| 1.13, orgkhnargh (ok), 14:30, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 То есть, если у меня есть 2 свистка по 2 мегабита от разных операторов, то с помощью MPTCP я смогу получить 4 мегабита вкупе и можно будет качество видео на ютубе повыше сделать?
| | |
| |
| 2.14, slavius (?), 14:37, 28/09/2015 [^] [^^] [^^^] [ответить]
| –6 +/– |
а ты ютубу сначала скажи что ты качаешь в два свистка)) да и повозись чтоб это все собиралось в один файл и кормилось твоему плееру. нет конечно можно наваять скрипт на коленке, но боюсь что скриптик получится не маленький. придется делать что то типа торрента. кстати для торрента должно быть неплохо. опять же надо проверять.
| | |
| |
| 3.16, Аноним (-), 16:58, 28/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
А разве не в этом смысл MultiPath TCP, чтобы снять эту работу с приклада?
| | |
| 3.18, Аноним (-), 18:12, 28/09/2015 [^] [^^] [^^^] [ответить]
| +1 +/– | |
«Для сетевых приложений подобное агрегированное соединение выглядит как обычное TCP-соединение, вся логика разделения потоков выполняется силами MPTCP.»
Никому ничего объяснять не надо. Главное, чтобы Ютуб понимал MPTCP, но это можно решить при помощи промежуточного прокси-сервера.
| | |
| |
| 4.23, slavius (?), 22:43, 28/09/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
а ты подумал че сказал? ты каким макаром собрался объяснить ютубу что ты качаешь с одного компа но в два потока.? он то увидит 2 ip? и ко всему прочему надо чтоб ютуб отдавал данные пачками и это все дело маркировалось по положению в файле, точь в точь как торрент, или ты собрался смотреть 2 версии одного и того же через свой плеер? тогда в чем суть. что один канал что 2.
| | |
| |
| 5.30, Alex (??), 08:09, 29/09/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Самовыпились, а. MPTCP именно тем и занимается, что изолирует многоканальность от приложения. Приложение 2 IP не увидит, а вот MPTCP - увидит.
| | |
|
| 4.24, slavius (?), 22:53, 28/09/2015 [^] [^^] [^^^] [ответить]
| –3 +/– |
еще добавлю прокси сервер тебе не разделит потоки и он же создаст ситуацию при которой один поток останется не у дел. фишка в том и есть что с одного компа норазных сетевух и разных ip/ нафига копья ломать тогда, сразу увеличил скорость и все. а вот торрент из этого действительно пользу извлечет. и вообще чисто сетевые проги , работающие на скачку. опять же будет разве что возможность распределения мощностей, но это и раньше можно было сделать при наличии двух сетевух и ip. в чем соль пока не понял, для просмотра видео её пока точно нет.
| | |
| |
| 5.26, Ytch (ok), 01:05, 29/09/2015 [^] [^^] [^^^] [ответить] | +5 +/– |  Что ему помешает Из примера выше - прокси сидит, к примеру, на 10 мегабитном ка... большой текст свёрнут, показать | | |
| |
| 6.46, slavius (?), 01:08, 30/09/2015 [^] [^^] [^^^] [ответить]
| –3 +/– |
а теперь подумай хорошенько и скажи как ты планируешь собирать файл в кучу с двух потоков и еще ко всему прочему в нынешней ситуации в сети. ты что же под этот мртср всю инфрасируктуру сети и стеков переделать хочешь? ты хоть понимаешь что для такого надо как минимум чтобы прокси знал как разбивать куски данных на несколько потоков и нормально их маркировать, чтоб потом собрать воедино? короче минимум у твоей прокси должна быть система маркировки пакетов по типу торрента и на уровне хоста тоже самое, что бы стек мог правильно прочесть маркировку и собрать файл воедино. чем не торрент? в третьих тогда уж надо принудить ютюб чтоб он ввел стандартизацию на разбивку видео на кластеры данных в видео и чтобы это поддерживалось в проге на стооне клиента. тогда да будет существенное повышение производительности загрузки файлов. но .... ты видел волка в бане парившись)))
| | |
| |
| 7.47, angra (ok), 05:05, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
 Почитай уже для самообразования https://en.wikipedia.org/wiki/OSI_model
Оно конечно не ложится напрямую на tcp/ip стек, но хотя бы даст понимание, что такое различные уровни сетевых протоколов.
А вот когда(или если) разберешься, то перечитай внимательно предыдущий пост, там тебе все доступно объяснили.
| | |
| |
| |
| 9.51, angra (ok), 13:54, 30/09/2015 [^] [^^] [^^^] [ответить] | +/– | Читал, но ничего не понял Бывает, может еще рано, а может вообще не твое это В... текст свёрнут, показать | | |
|
|
| 7.52, Ytch (ok), 23:48, 30/09/2015 [^] [^^] [^^^] [ответить] | +/– | Подумать всё-таки придется тебе ну или забей и дальше не читай Поток для при... большой текст свёрнут, показать | | |
| |
| 8.53, angra (ok), 02:02, 01/10/2015 [^] [^^] [^^^] [ответить] | +/– | Ну ты ему еще мозг взорви рассказом про MTU и фрагментацию пакетов Мало того, ч... текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.29, Alex (??), 08:07, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
Именно так, если на стороне ютуба будет поддержка MPTCP.
| | |
| |
| 3.40, orgkhnargh (ok), 21:59, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Именно так, если на стороне ютуба будет поддержка MPTCP.
То есть, работать будет примерно как бондинг, но внешний сервер поднимать отдельно не надо?
| | |
| |
| 4.41, Alex (??), 22:05, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> То есть, работать будет примерно как бондинг, но внешний сервер поднимать отдельно
> не надо?
Это и есть бондинг, только на уровне отдельного виртуального соединения TCP, состоящего фактически из нескольких :)
| | |
| 4.42, Alex (??), 22:07, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
Если проще - то "да". С некоторыми оговорками, например, что каналы вполне могут быть совершенно разноскоростными и с разным уровнем потерь.
| | |
| |
| 5.54, Bobik (?), 13:52, 02/10/2015 [^] [^^] [^^^] [ответить]
| +/– |
Оговорка одна ютуб ету херню не поддержывает и по етому работать оно не будет, а рассуждать можно много очом.
| | |
|
|
|
|
| |
| 2.22, Demo (??), 22:33, 28/09/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> лучше бы sctp внедряли где попало
SCTP богомерзкой телефонией попахивает, а это сегодня не в трэнде.
| | |
| |
| 3.27, Crazy Alex (ok), 01:57, 29/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
 И правильно, что не в тренде. Телефонисты что-то понятное и удобное в эксплуатации отродясь сделать не могли. И до сих пор не могут - одна идея "телефонного номера" фиксированной длины чего стоит.
| | |
| |
| 4.28, Ytch (ok), 03:07, 29/09/2015 [^] [^^] [^^^] [ответить] | +/– | Ну не совсем так, мягко выражаясь У них было множество весьма неплохих инженерн... большой текст свёрнут, показать | | |
| |
| |
| 6.48, t28 (?), 09:28, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> X.400 (невзлетевшая типа электропочта)
Не надо "ля-ля". Всё работает, где надо.
| | |
|
|
| 4.31, Alex (??), 08:13, 29/09/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
> И правильно, что не в тренде. Телефонисты что-то понятное и удобное в
> эксплуатации отродясь сделать не могли. И до сих пор не могут
> - одна идея "телефонного номера" фиксированной длины чего стоит.
А то, что у IPv4/v6/Ethernet/whatever адрес фиксированной длины, тебя не смущает?
| | |
| |
| 5.37, Crazy Alex (ok), 16:01, 29/09/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
Не смущает. Это адрес для машины, а не для человека. Вот если бы фиксированной длины (да ещё контекстно-зависимой от моего положения) были имена в скайпе или имена доменов - смущало бы, и ещё как.
| | |
| |
| 6.43, Alex (??), 22:07, 29/09/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
А для человека у телефонистов есть телефонный справочник. Аналог DNS, по сути. Книжка такая толстая.
| | |
|
|
| |
| 5.38, Crazy Alex (ok), 16:03, 29/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
И всё равно везде всё прибито гвоздями к номерным планам с фиксированной длиной номера, префиксами выхода и подобной мутью. Хотя, например, доменная система смотрелась бы куда лучше и на современных ресурсах ни малейших проблем по ресурсам не составила бы.
| | |
| |
| 6.44, Alex (??), 22:09, 29/09/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> И всё равно везде всё прибито гвоздями к номерным планам с фиксированной
> длиной номера, префиксами выхода и подобной мутью. Хотя, например, доменная система
> смотрелась бы куда лучше и на современных ресурсах ни малейших проблем
> по ресурсам не составила бы.
Ну в интернетах всё прибито к IPv4 фиксированной длины точно так же. С IPv6 всё вообще ужасно, оно ещё и не человеко-запоминаемо. DNS DNS'ом, а прямые адреса вбивать всё равно приходится. Даже ендюзерам иногда.
| | |
| 6.49, t28 (?), 09:37, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> И всё равно везде всё прибито гвоздями к номерным планам
В The Internet-е так же. Адресация гвоздями прибита к Route Database, и пока Regional Registry не заапрувит и не внесёт ваши данные в базу, полноценно пользоваться своими префиксами вы не сможете.
| | |
|
|
|
|
|
| 1.25, InventoR (??), 23:27, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 Мне не интересен трафик, мне интересно, эта штука наконец поможет сбалансировать и сделать отказоустойчивость в managment интерфейсе кластера, пусть даже прокса?
Строить агрегацию на базе разных свичей обьеденых в стек это безумие, а вот поставить два простых свича и построить managment с этой штукой было бы здорово.
| | |
| 1.33, Alex (??), 08:23, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Есть у MPTCP ещё одна хитрость при использовании нескольких операторов: всякие СОРМы и прочие будут ссать кровавыми слезами, потому что трафик собрать воедино скорее всего не получится. А с TLS - еще хуже.
| | |
| |
| 2.34, Петушок (?), 10:02, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Есть у MPTCP ещё одна хитрость при использовании нескольких операторов: всякие СОРМы
> и прочие будут ссать кровавыми слезами, потому что трафик собрать воедино
> скорее всего не получится. А с TLS - еще хуже.
Неуловимый, ты никому не нужен
| | |
| |
| 3.45, Alex (??), 22:10, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Неуловимый, ты никому не нужен
Мне вообще давно пох, нужен я или нет )
| | |
|
|
|
