спроектированный в лабораторных условиях оказался не рабочим в реальных сетях
из за большого количества мелких пакетов pps, начали загибаться и клиентские роутеры и провайдерские узлы
а пользователи со своей стороны начали жаловаться что никакими опциями в торренте по congestion control не возможно сделать так что бы
работал и торрент и броузер
было где то еще то ли новостью то ли сам БеКо рассказывал как они это все проектировали и лажанулись с congestion control
потом конечно исправили
Здравствуйте, Ops, Вы писали:
C>>Никак. В этом случае не будет никаких гарантий, как и при соединении по обычному TCP. Ops>Тогда это профанация навязанного протоколом обязательного "шифрования" и бессмысленная нагрузка на устройства.
Нет. Как минимум, пассивные атаки работать не будут.
Дополнительно, QUIC сделан так, что предотвращает окостеневание протоколов (protocol ossification).
C>>Единственное, что подслушивать можно будет только активно через MITM. Ops>Что усложняет отладку, но не является непреодолимым препятствием для злоумышленника.
В большинстве случаев это означает, что злоумышленник должен иметь полный контроль за каналом.
S>Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC.
Не взлетит по одной очевидной причине: отказ от уровней OSI приведёт к степенному росту сложности разработки и отладки.
Разработка этого протокола не будет закончена никогда, а если и будет то получится УГ: могу делать все но очень плохо.
Здравствуйте, eskimo82, Вы писали:
E>Не взлетит по одной очевидной причине: отказ от уровней OSI приведёт к степенному росту сложности разработки и отладки.
OSI сдохла уже давно.
E>Разработка этого протокола не будет закончена никогда, а если и будет то получится УГ: могу делать все но очень плохо.
QUIC уже работает. В следующей версии ещё добавляют FEC для борьбы с потерями.
E>>Разработка этого протокола не будет закончена никогда, а если и будет то получится УГ: могу делать все но очень плохо. C>QUIC уже работает. В следующей версии ещё добавляют FEC для борьбы с потерями.
Он будет только начинать "уже работать" когда появится внятный и законченый стандарт.
Пока что пытаются опробовать только несовместимые между собой наколенные прототипы, но и то, судя по бенчмаркам, они уныло сосут перед TCP/IP.
S>>Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC.
E>Не взлетит по одной очевидной причине: отказ от уровней OSI приведёт к степенному росту сложности разработки и отладки.
Строгий стек OSI давно умер, и не участвует тут никаким боком.
Если имеется в виду "народный" стек OSI, который ложится в том числе на TCP/IP, то нарушается минимально, и принципиальных проблем тут не будет. Такого рода нарушения давно отработаны концептуально и практически на туннелировании, на TLS-over-UDP.
E>Разработка этого протокола не будет закончена никогда, а если и будет то получится УГ: могу делать все но очень плохо.
В нём есть, действительно, странные решения.
Но HTTP/2 с похожим подходом уже более-менее взлетел.
Здравствуйте, Cyberax, Вы писали:
C>Дополнительно, QUIC сделан так, что предотвращает окостеневание протоколов (protocol ossification).
Прошу показать, как QUIC позволит устранять какие-то нормы стандарта, которые позднее признаны неадекватными и предложена замена (причём, какие именно, мы ещё не знаем).
Иначе же это выглядит как откровенное бла-бла-бла с использованием баззворда, а в сторону TCP кинуто "он чужой, он плохой".
QUIC is a Google solution and Google is very keen on dumb middleware where everything is controlled by endpoints. Middleware is anything interposed between Google cloud services and Google client software, be it networking equipment, operating systems, any security or control framework. When one endpoint is Google cloud, and the other Google Chrome, or Google Android, and everything else has no control of what happens, that effectively means Google is in control. It's usually sold to the general public as putting some control in the hands of end users. Some control being the power to nullify other forms of power and put Google in the driving seat.
The "ossification" Google harps on is someone else exercising some form of non-Google control, usually by virtue of having bought or being the owner or contractor of the network or computing gear, deploying something designed to be controlled by its owner, or applying standards with the same objective.
Я знаю проблемы TCP. Но решение от гугла, которое притягивается за уши, может быть ещё хуже.
C>>>Единственное, что подслушивать можно будет только активно через MITM. Ops>>Что усложняет отладку, но не является непреодолимым препятствием для злоумышленника. C>В большинстве случаев это означает, что злоумышленник должен иметь полный контроль за каналом.
И всё это на той же централизованной схеме сертификатов?
Здравствуйте, netch80, Вы писали:
C>>Дополнительно, QUIC сделан так, что предотвращает окостеневание протоколов (protocol ossification). N>Прошу показать, как QUIC позволит устранять какие-то нормы стандарта, которые позднее признаны неадекватными и предложена замена (причём, какие именно, мы ещё не знаем).
TCP закостенел. Его невозможно изменить. Простенький ECN (Explicit Congestion Notification) до сих пор не поддерживается всеми middlebox'ами, через 17 лет после RFC.
С QUIC так не получится, так как там шифруется практически всё. Для middlebox'ов оставили один незашифрованный бит.
Из конкретных улучшений по сравнению с TCP:
1) PMTU полностью поднят на уровень QUIC, так как на уровне IP оно всё сдохло.
2) Multi-homing внедрён в QUIC и полностью поддерживается. Для TCP это есть только в расширении MPTCP.
3) Продуманный механизм будущих расширений.
4) FEC для компенсации потерянных пакетов (возможно, что в первую версию стандарта не попадёт).
...
N>The "ossification" Google harps on is someone else exercising some form of non-Google control, usually by virtue of having bought or being the owner or contractor of the network or computing gear, deploying something designed to be controlled by its owner, or applying standards with the same objective.
Бред.
N>Я знаю проблемы TCP. Но решение от гугла, которое притягивается за уши, может быть ещё хуже.
Чем?
Ops>>>Что усложняет отладку, но не является непреодолимым препятствием для злоумышленника. C>>В большинстве случаев это означает, что злоумышленник должен иметь полный контроль за каналом. N>И всё это на той же централизованной схеме сертификатов?
То есть? Никто не мешает использовать DNSSEC+DANE с QUIC. Или свою иерархию. В следующем стандарте будет поддержка PAKE и сильной аутентификации с паролями.
Здравствуйте, eskimo82, Вы писали:
E>>>Разработка этого протокола не будет закончена никогда, а если и будет то получится УГ: могу делать все но очень плохо. C>>QUIC уже работает. В следующей версии ещё добавляют FEC для борьбы с потерями. E>Он будет только начинать "уже работать" когда появится внятный и законченый стандарт.
Так уже: https://www.ietf.org/id/draft-ietf-quic-transport-16.txt — будет по плану ратифицирован в следующем году, во время июльской встречи IETF.
E>Пока что пытаются опробовать только несовместимые между собой наколенные прототипы, но и то, судя по бенчмаркам, они уныло сосут перед TCP/IP.
Бредим как обычно, да?
C>Так уже: https://www.ietf.org/id/draft-ietf-quic-transport-16.txt — будет по плану ратифицирован в следующем году, во время июльской встречи IETF.
Вот как будет (если будет) ратифицирован, тогда и поговорим.
C>Бредим как обычно, да?
Ты опять про свои голоса ?
C>См.: https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop/ C>Что неудивительно, для QUIC применены все современные наработки по TCP. Собственно, над QUIC в Гугле работает Ван Якобсон. Надо рассказывать кто это?
Это абсолютно монопенисуарно в текущий момент времени что там для себя колхозит гугол.
Здравствуйте, eskimo82, Вы писали:
C>>Так уже: https://www.ietf.org/id/draft-ietf-quic-transport-16.txt — будет по плану ратифицирован в следующем году, во время июльской встречи IETF. E>Вот как будет (если будет) ратифицирован, тогда и поговорим.
Ну вот, через год обращайтесь.
C>>Бредим как обычно, да? E>Ты опять про свои голоса ?
Мои голоса не бредят всякий бред.
C>>См.: https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop/ C>>Что неудивительно, для QUIC применены все современные наработки по TCP. Собственно, над QUIC в Гугле работает Ван Якобсон. Надо рассказывать кто это? E>Это абсолютно монопенисуарно в текущий момент времени что там для себя колхозит гугол.
Т.е. слился, аргументов больше нет.
По факту получилось: протокол де-факто готов, работает быстрее TCP в реальных условиях и поддерживается не только Гуглом.
C>По факту получилось: протокол де-факто готов, работает быстрее TCP в реальных условиях и поддерживается не только Гуглом.
По факту все вышеперечисленое как раз наоборот.
Здравствуйте, Cyberax, Вы писали:
E>>>>Разработка этого протокола не будет закончена никогда, а если и будет то получится УГ: могу делать все но очень плохо. C>>>QUIC уже работает. В следующей версии ещё добавляют FEC для борьбы с потерями. E>>Он будет только начинать "уже работать" когда появится внятный и законченый стандарт. C>Так уже:
"Это есть, товарищи, случай так называемого вранья" (tm)
Читаем упомянутый драфт:
5.3. Life of a QUIC Connection
TBD.
Это не "внятный и законченный", это _ничего_ готового нет, потому что нет самого главного.
По сравнению с этим все эти простыни жизни потоков и раскладки битов — бесполезный тлен.
C> https://www.ietf.org/id/draft-ietf-quic-transport-16.txt — будет по плану ратифицирован в следующем году, во время июльской встречи IETF.
Там нечего ратифицировать.
А если ратифицируют, значит, IETF окончательно спятил, потому что протокол такого уровня и масштаба требует не меньше года на вычитку и опробование уже после того, как _вроде бы_ финальный текст готов и отлажен вплоть до запятых.
C>Что неудивительно, для QUIC применены все современные наработки по TCP. Собственно, над QUIC в Гугле работает Ван Якобсон. Надо рассказывать кто это?
У гугла потрясающая манера забирать толковых людей и превращать их работу в унылое дерьмо.
Вопрос не в том, кто там работает. Вопрос в том, на какую цель он работает и в какие рамки он загнан.
Здравствуйте, netch80, Вы писали:
C>>Так уже: N>"Это есть, товарищи, случай так называемого вранья" (tm) N>Читаем упомянутый драфт:
Следующий драфт будет на следующей неделе.
N>Это не "внятный и законченный", это _ничего_ готового нет, потому что нет самого главного. N>По сравнению с этим все эти простыни жизни потоков и раскладки битов — бесполезный тлен.
У QUIC есть преимущество — это протокол, который уже опробован практически.
N>А если ратифицируют, значит, IETF окончательно спятил, потому что протокол такого уровня и масштаба требует не меньше года на вычитку и опробование уже после того, как _вроде бы_ финальный текст готов и отлажен вплоть до запятых.
До июля время есть.
C>>Что неудивительно, для QUIC применены все современные наработки по TCP. Собственно, над QUIC в Гугле работает Ван Якобсон. Надо рассказывать кто это? N>У гугла потрясающая манера забирать толковых людей и превращать их работу в унылое дерьмо. N>Вопрос не в том, кто там работает. Вопрос в том, на какую цель он работает и в какие рамки он загнан.
Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы. Всё, больше их команду ничего не интересует. У них полная свобода творчества.
Единственное условие — реализуемость протокола внутри Google Chrome.
Здравствуйте, Cyberax, Вы писали:
C>>>Так уже: N>>"Это есть, товарищи, случай так называемого вранья" (tm) N>>Читаем упомянутый драфт: C>Следующий драфт будет на следующей неделе.
"Обіцянки-цецянки" (c)
Будет или нет, а нормального времени на подумать миру просто не дают.
N>>Это не "внятный и законченный", это _ничего_ готового нет, потому что нет самого главного. N>>По сравнению с этим все эти простыни жизни потоков и раскладки битов — бесполезный тлен. C>У QUIC есть преимущество — это протокол, который уже опробован практически.
Одним гуглом, да? Даже при его толщине это просто ни о чём.
Чтобы понять все проблемы, нужны как минимум две независимые реализации, одна из которых как можно ближе к режиму "чистой комнаты" просто по спеке.
Вживую, реальные проблемы выявляются в сильно большем разнообразии условий и источников.
А для IT нормальный срок выявления, осознания проблемы и начала её решения, увы, лет 10 в обычном цикле.
N>>А если ратифицируют, значит, IETF окончательно спятил, потому что протокол такого уровня и масштаба требует не меньше года на вычитку и опробование уже после того, как _вроде бы_ финальный текст готов и отлажен вплоть до запятых. C>До июля время есть.
Время будет отсчитываться от final draft, которого ещё нет (и не надо рассказывать про "следующую неделю").
C>>>Что неудивительно, для QUIC применены все современные наработки по TCP. Собственно, над QUIC в Гугле работает Ван Якобсон. Надо рассказывать кто это? N>>У гугла потрясающая манера забирать толковых людей и превращать их работу в унылое дерьмо. N>>Вопрос не в том, кто там работает. Вопрос в том, на какую цель он работает и в какие рамки он загнан. C>Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы. Всё, больше их команду ничего не интересует. У них полная свобода творчества.
C>Единственное условие — реализуемость протокола внутри Google Chrome.
А, то есть это протокол от гугла для гугла для хождения в гугл через гугл.
Ну, если так, то я более-менее спокоен пусть гугл сам себе стреляет в ногу.
Просто в таком случае непонятно, зачем им вообще IETF.
Здравствуйте, Cyberax, Вы писали:
C>>>Дополнительно, QUIC сделан так, что предотвращает окостеневание протоколов (protocol ossification). N>>Прошу показать, как QUIC позволит устранять какие-то нормы стандарта, которые позднее признаны неадекватными и предложена замена (причём, какие именно, мы ещё не знаем). C>TCP закостенел. Его невозможно изменить. Простенький ECN (Explicit Congestion Notification) до сих пор не поддерживается всеми middlebox'ами, через 17 лет после RFC.
"C++ закостенел, потому что простейшие нормы C++11 до сих пор не поддерживаются всеми компиляторами."
"C закостенел, потому что C99 до сих пор не поддерживается всеми компиляторами, через 19 лет после стандарта."
Впрочем, будем считать, что ты ответил на вопрос. Тогда следующий — почему это вместо нормального нового стандарта TCP-like (время которого таки пришло) или SCTP (в котором есть уже почти всё нужное) нам предлагают идти калечным путём и строить что-то поверх UDP, теряя множество важных возможностей от интеграции в IP стек.
"Нормальные герои всегда идут в обход", да.
C>С QUIC так не получится, так как там шифруется практически всё. Для middlebox'ов оставили один незашифрованный бит.
Ну вот ты впал в ту же сторону, что гугл — всё, что посреди, назвать "middlebox", назначить этому ярлыку заведомо отрицательную роль и считать свою историческую роль выполненной.
Про проблемы времени жизни NAT сессий тут уже говорили, не буду повторяться.
C>Из конкретных улучшений по сравнению с TCP: C>1) PMTU полностью поднят на уровень QUIC, так как на уровне IP оно всё сдохло.
На уровне IP его, как ни странно, за последние годы починили чуть менее, чем везде.
Если в начале 2000х я постоянно боролся с ним даже как клиент, то за последние лет 5 проблемы не видно.
C>2) Multi-homing внедрён в QUIC и полностью поддерживается. Для TCP это есть только в расширении MPTCP. C>3) Продуманный механизм будущих расширений. C>4) FEC для компенсации потерянных пакетов (возможно, что в первую версию стандарта не попадёт).
И будет точно так же, как с TCP? Первая версия застынет у 90% участников.
Это если мы полагаем, что его будет использовать кто-то за пределами гугла.
C>...
N>>The "ossification" Google harps on is someone else exercising some form of non-Google control, usually by virtue of having bought or being the owner or contractor of the network or computing gear, deploying something designed to be controlled by its owner, or applying standards with the same objective. C>Бред.
Почему? Пока что всё указывает на это — гугл силой проталкивает своё крайне сырое решение, нацеленное исключительно на его интересы.
Повторится ситуация с HTTP/2, который кое-как выкрутили с двадцатой попытки, и то постоянно с проблемами (знаю места, где сначала включили его на сервере, потом выключили нафиг, ибо реализации глючные аж нимагу).
N>>Я знаю проблемы TCP. Но решение от гугла, которое притягивается за уши, может быть ещё хуже. C>Чем?
Здравствуйте, netch80, Вы писали:
N>Впрочем, будем считать, что ты ответил на вопрос. Тогда следующий — почему это вместо нормального нового стандарта TCP-like (время которого таки пришло) или SCTP (в котором есть уже почти всё нужное) нам предлагают идти калечным путём и строить что-то поверх UDP, теряя множество важных возможностей от интеграции в IP стек. N>"Нормальные герои всегда идут в обход", да.
Это как раз понятно — слишком много сетевых железок, которые выбрасывают всё кроме TCP и UDP и никто их не выбросит. Разве это не аргумент? Вот у меня дома стоит оптический модем от провайдера, который мне даёт интернет. Нормальный провайдер у нас в стране де факто один, альтернатива ещё хуже. Модем этот я сменить не могу, не продают таких модемов в магазинах и настроек никаких у меня нет, у них там вообще своя прошивка с прошитыми параметрами. И шо мне делать с этим протоколом поверх IP? Отключать интернет и идти в пещеру? Конечно у гугла есть сила прогибать кого угодно фразой ютуб не работает, но и он не всесилен.
Здравствуйте, netch80, Вы писали:
N>Почему? Пока что всё указывает на это — гугл силой проталкивает своё крайне сырое решение, нацеленное исключительно на его интересы. N>Повторится ситуация с HTTP/2, который кое-как выкрутили с двадцатой попытки, и то постоянно с проблемами (знаю места, где сначала включили его на сервере, потом выключили нафиг, ибо реализации глючные аж нимагу).
Здравствуйте, Ops, Вы писали:
C>>Для QUIC тоже, можно просто сгенерировать эфемерные сертификаты при старте сервера.
Ops>Объясни механизм. Как я могу доверять каким-то сгенеренным сертификатам без УЦ?
Ну например, в момент первого присоединения утюга ты можешь нажать кнопку "Это точно мой утюх, мамой клянусь!", и каждый следующий раз идентичность утюга будет проверяться вполне надежно.
пусть гугл сам себе стреляет в ногу.
