Здравствуйте, m2l, Вы писали:
C>>Ну начнём с того, что 0-RTT connection невозможен без шифрования на уровне протокола. Но более глубокая причина в том, что одной из целей протокола было сделать middlebox'ы невозможными. Практика показала, что иначе протоколы мгновенно закостеневают. m2l>Ты почему то за аксиому берешь что некое обозначенное тобой "закостеневают" это "плохо".
Потому, что это плохо. Это останавливает саму возможность развития протоколов.
m2l>Не стесняйся, расскажи нам, что хорошего каждую неделю переделывать протоколы и форматы. Для кого это будет хорошо. И почему, если это так хорошо раньше этого не делали.
"Мой дед крутил гайки ключом на 15, мой отец крутил гайки ключом на 15, и я буду крутить гайки ключом на 15!"
А не делали из-за того, что протоколы начали костенеть в районе 2001-го года. Я уже привёл пример с ECN.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Somescout, Вы писали:
C>>>Одной из проблем в Интернете является PMTU — поиск максимального размера пакета. Потому многие серверы тупо ставят что-то типа 1380 (Google) для гарантии того, что ответы пройдут через любые разумные тоннели ( https://jamesdobson.name/post/mtu/ ). S>>А с чего вдруг это проблема? C>Увеличивает число пакетов. Именно число пакетов в секунду нынче является узким горлышком в железе.
Разница минимальна, более того со всеми подобными проблемами куда лучше справляется IPv6. Но гугля не хочет его ждать у гугли чешется NIH.
C>При учёте пакетов не забываем отсутствие тройного рукопожатия, при 0-RTT сервер отправляет данные в первом же пакете.
Лол — QUIC показывает наилучшие результаты на broadband, а когда пугают "тремя рукопожатиями" используют примеры с таймингами чуть ли не из мобильной связи, где QUIC отсасывает. Это "три рукопожатия" на нормальном канале дадут 100-200 миллисекунд (в худшем случае!) на первом подключениии — хром будет дольше layout страницы делать.
S>>Максимум это немного (действительно ненамного) повышает нагрузку на оборудование провайдера (затраты на маршрутизацию пакетов, но визуально это заметно когда пакеты сильно меньше килобайта. Да и в любом случае геморроя с маршрутизацией UDP будет больше). C>ЩИТО?
"Маршрутизацией", посмотрите значение в словаре.
S>>ЗЫ. Ютуб тупит на любом браузере далеко не из-за протокола, но лучше ведь в очередной раз поставить интернет раком, а не фиксить свои сайты. C>ЩИТО?
ШИ ТО. Ютуб второй после твитча случай, когда программистам можно пересадить руки макаки и это не ухудшит результат. Гугль гонится за миллисекундами скорости, игнорируя что один из их основных сайтов тормозное ****.
Здравствуйте, Cyberax, Вы писали:
C>>>Ну начнём с того, что 0-RTT connection невозможен без шифрования на уровне протокола. Но более глубокая причина в том, что одной из целей протокола было сделать middlebox'ы невозможными. Практика показала, что иначе протоколы мгновенно закостеневают. m2l>>Ты почему то за аксиому берешь что некое обозначенное тобой "закостеневают" это "плохо". C>Потому, что это плохо. Это останавливает саму возможность развития протоколов.
Логики нет в твоих словах. К примеру cloud & sdn дают развитие vxvlan. Умные устройства дают возможности для "промышленных протоколов". Через 30 лет после TCP и UDP появились SCTP и DCCP. Насчет последнего не в курсе, а SCTP активно используется. Эволюция идёт, и если появится протокол кардинально лучший — то он вытеснит существующие. Другой вопросы, что ничего кардинально лучшего нет. А "развитие" ради "развития", ну ты сам понимаешь...
m2l>>Не стесняйся, расскажи нам, что хорошего каждую неделю переделывать протоколы и форматы. Для кого это будет хорошо. И почему, если это так хорошо раньше этого не делали. C> C>"Мой дед крутил гайки ключом на 15, мой отец крутил гайки ключом на 15, и я буду крутить гайки ключом на 15!"
Действительно, он крутил на 15, а мы будет крутить на 16, через год заменим на 14, потом на 15 с половиной. Ведь это развитие! Если просто так не менять их диаметр, то будет плохо!
C>А не делали из-за того, что протоколы начали костенеть в районе 2001-го года. Я уже привёл пример с ECN.
ИМХО, ты немного не разобрался отчего оно реализовано и отключено по умолчанию. Я вот на вскидку не смог придумать кейс, где оно было бы полезно, а не вредно.
Здравствуйте, Somescout, Вы писали:
C>>Увеличивает число пакетов. Именно число пакетов в секунду нынче является узким горлышком в железе. S>Разница минимальна, более того со всеми подобными проблемами куда лучше справляется IPv6. Но гугля не хочет его ждать у гугли чешется NIH.
В IPv6 число пакетов ровно такое же. Точнее, на практике ещё большее из-за того, что MTU руками занижают ещё сильнее.
S>Лол — QUIC показывает наилучшие результаты на broadband, а когда пугают "тремя рукопожатиями" используют примеры с таймингами чуть ли не из мобильной связи, где QUIC отсасывает. Это "три рукопожатия" на нормальном канале дадут 100-200 миллисекунд (в худшем случае!) на первом подключениии — хром будет дольше layout страницы делать.
Если обращение на страницу в другой части страны (с западного берега на восточный) — это уже почти треть секунды на RTT. Уже очень заметно.
S>>>Максимум это немного (действительно ненамного) повышает нагрузку на оборудование провайдера (затраты на маршрутизацию пакетов, но визуально это заметно когда пакеты сильно меньше килобайта. Да и в любом случае геморроя с маршрутизацией UDP будет больше). C>>ЩИТО? S>"Маршрутизацией", посмотрите значение в словаре.
ЩИТО такое "маршрутизация UDP"?
S>>>ЗЫ. Ютуб тупит на любом браузере далеко не из-за протокола, но лучше ведь в очередной раз поставить интернет раком, а не фиксить свои сайты. C>>ЩИТО? S>ШИ ТО. Ютуб второй после твитча случай, когда программистам можно пересадить руки макаки и это не ухудшит результат. Гугль гонится за миллисекундами скорости, игнорируя что один из их основных сайтов тормозное ****.
Ну да, один Somescout такой умный. Что там где тормозит, конкретно?
Здравствуйте, m2l, Вы писали:
C>>Потому, что это плохо. Это останавливает саму возможность развития протоколов. m2l>Логики нет в твоих словах. К примеру cloud & sdn дают развитие vxvlan. Умные устройства дают возможности для "промышленных протоколов". Через 30 лет после TCP и UDP появились SCTP и DCCP.
SCTP не работает в публичном Интернете из-за вездесущих middlebox'ов. В частности, на большинстве мобильных устройств.
Любое приложение, которое будет пытаться использовать SCTP пойдёт лесом примерно для так ~20% пользователей.
C>>"Мой дед крутил гайки ключом на 15, мой отец крутил гайки ключом на 15, и я буду крутить гайки ключом на 15!" m2l>Действительно, он крутил на 15, а мы будет крутить на 16, через год заменим на 14, потом на 15 с половиной. Ведь это развитие! Если просто так не менять их диаметр, то будет плохо!
Нет. Будешь крутить и дальше ключом на 15.
C>>А не делали из-за того, что протоколы начали костенеть в районе 2001-го года. Я уже привёл пример с ECN. m2l>ИМХО, ты немного не разобрался отчего оно реализовано и отключено по умолчанию.
ECN не включен из-за того, что ДО СИХ ПОР его неправильно обрабатывают middlebox'ы.
Здравствуйте, Ops, Вы писали:
Pzz>>Этот метод считается достаточно надежным для, например, привязывания брелков к электрическим воротам, или для привязывания bluetooth устройств. Воткнуться, конечно, в нужный момент можно, но это надо очень постараться.
Ops>BT, WPS и, подозреваю, ворота с брелоками, обеспечивают это вообще на канальном уровне. А уже на уровне IP такой сценарий затруднителен, из-за меньшей локальности хостов в общем случае.
Ну спросили про утюг, я и ответил про утюг. Утюг всегда локален, иначе нафиг он вообще нужен? Каждая задача должна решаться с учетом спецефических для нее потребностей.
В общем и целом, доверие должно на чем-то основываться. Использование сертификационных центров, которым все доверяют (совершенно напрасно, на мой взглад) — один из вариантов. Использование явного действия со стороны пользователя — другой возможный вариант, при условии, что пользователь действительно понимает, что он делает.
Pzz>>Без надстроек он обеспечивает TLS-like модель безопасности, при наличии соответствующей инфраструктуры для раздачи сертификатов.
Ops>А в чем польза-то? Ну сделали бы этот протокол без принудительного шифрования, а сверху пустили бы тот же TLS, когда нужно.
В том, что от внесения шифрования на уровень транспортного протокола, можно добиться существенной экономии. Например, объединяя "TLS" handshake и "TCP" handshake, можно установить соединение с шифрованием за 1-2 RTT, а не за 5-7, как в случае TCP+TLS. Объеденив "TCP" sequence numbers с криптографическим nonce, можно сэкономить несколько байт на пакет, что заметно, если пакеты маленькие (как в случае аудиопотока, например). Ну и т.д. и т.п.
Здравствуйте, Cyberax, Вы писали:
C>Ну начнём с того, что 0-RTT connection невозможен без шифрования на уровне протокола. Но более глубокая причина в том, что одной из целей протокола было сделать middlebox'ы невозможными. Практика показала, что иначе протоколы мгновенно закостеневают.
Я попытался понять, как работает этот 0-RTT, правда довольно на бегу и в спешке, так что поправь меня, если я не прав.
У меня сложилось впечатление, при использовании 0-RTT первая порция данных от "клиента" к "серверу" посылается еще до то того как идентичность "сервера" подтверждена. Т.е., например, если у нас HTTP, то параметры HTTP GET посылаются "куда-то там", и лишь к моменту получения ответа можно проверить, что мы именно с тем и разговариваем, с кем собирались.
С TCP+TLS это было не так.
Гражданам, конструирующим всякие там REST API это следовало бы иметь ввиду. Потому что если параметры запроса секретные, то можно получить дыру в защите в неожиданном (из прошлого опыта) месте.
Здравствуйте, CreatorCray, Вы писали:
CC>Что то мне кажется что в реале он как раз будет сосать что тот пылесос. CC>Потому что шторм UDP запросов говномиддлбоксы переваривают плохо.
Миддлбоксам придется подвинуться, потому что google chrome — это чуть менее, чем все мобильные устройства.
Здравствуйте, Pzz, Вы писали:
Pzz>В том, что от внесения шифрования на уровень транспортного протокола, можно добиться существенной экономии.
Экономия будет, если не заставлять всех шифровать все подряд. Тогда в утюг можно будет впихнуть МК на 3 рубля дешевле, что в мировых масштабах вполне существенно.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Pzz>>В том, что от внесения шифрования на уровень транспортного протокола, можно добиться существенной экономии.
Ops>Экономия будет, если не заставлять всех шифровать все подряд. Тогда в утюг можно будет впихнуть МК на 3 рубля дешевле, что в мировых масштабах вполне существенно.
С тех пор, как сети стали радиофицированными, отказ от адекватного шифрования является дырой в защите чуть менее, чем всегда.
Хотите сэкономить 3 рубля на утюге — не надо его вообще подключать к сети.
Ops>>Экономия будет, если не заставлять всех шифровать все подряд. Тогда в утюг можно будет впихнуть МК на 3 рубля дешевле, что в мировых масштабах вполне существенно. Pzz>С тех пор, как сети стали радиофицированными, отказ от адекватного шифрования является дырой в защите чуть менее, чем всегда.
Шифрование не везде и не всегда нужно. Оно не обязательно.
Pzz>Хотите сэкономить 3 рубля на утюге — не надо его вообще подключать к сети.
Шифрование само по себе довольно дорого — это не просто данные ближайшим пакетом по DMA в сетевую карту отправить, это гораздо сложнее.
Поэтому единственно адекватным по скорости решением будет полностью аппаратное шифрование. Т.е. замена всего парка (промежуточного) железа.
PS: Ops в этом совершенно прав.
PS2: Вообщем ерунда все это. Концепция этого протокола нарушает простую истину — делай только одну вещь, но делай ее качественно.
Если этого не придерживаться, то сложность разработки и отладки возрастает как степенная функция вплоть до невозможности правильной реализации.
Поэтому на все это можно смотреть ка кна очередной красноглазый хайп среди хипстеров, но логику и природу то не обманеш.
— quic не предлагают заменить полностью на tcp
— quic предлагают подменить на tcp в http
— quic как и tcp работает на ендпоинтах, а не на всех промежуточных узлах,
поэтому я не представляю что именно вы собрались такое тяжелое гонять по http в криптографии по quic, что бы загнуть ендпоинт девайсы
— все таки гугл смотрит вперед а не на зад, и в обозримом будущем когда quic сможет получить распространение, криптография hw на девайсах я думаю уже будет, а tcp under http подтормаживает
и в этом гуглу видней, так же как они изобретали bbr
Здравствуйте, Pzz, Вы писали:
Pzz>С тех пор, как сети стали радиофицированными, отказ от адекватного шифрования является дырой в защите чуть менее, чем всегда.
В радио сетях оно УЖЕ есть, на канальном уровне. Зачем 2-й раз шифровать? Потому что так гуглу захотелось?
Pzz>Хотите сэкономить 3 рубля на утюге — не надо его вообще подключать к сети.
Ну это, к счастью, не тебе решать.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Somescout, Вы писали:
S>ШИ ТО. Ютуб второй после твитча случай, когда программистам можно пересадить руки макаки и это не ухудшит результат. Гугль гонится за миллисекундами скорости, игнорируя что один из их основных сайтов тормозное ****.
Почему тормозное? У меня очень быстро открывается и работает.
Здравствуйте, eskimo82, Вы писали:
E>PS2: Вообщем ерунда все это. Концепция этого протокола нарушает простую истину — делай только одну вещь, но делай ее качественно. E>Если этого не придерживаться, то сложность разработки и отладки возрастает как степенная функция вплоть до невозможности правильной реализации.
Этого принципа много кто не придерживается. Возьми ядро операционной системы. Вроде бы должны придерживаться микроядерного подхода, как ты говоришь. Но всё пихают в один монолит, т.к. быстрей. Возьми СУБД. Запихали JSON. При чём тут JSON и реляционная база данных? Не при чём, но удобно и быстро. Так и тут. Если это будет быстрей, сделают. Т.к. сделать надо по сути один раз, а остальные будут использовать готовую библиотеку. Концептуально может и не правильно, но на практике нормально.
