Здравствуйте, Pzz, Вы писали:

Pzz>Ну например, в момент первого присоединения утюга ты можешь нажать кнопку "Это точно мой утюх, мамой клянусь!", и каждый следующий раз идентичность утюга будет проверяться вполне надежно.

Во-первых, это ненадежно, утюг злоумышленника может как раз поджидать такого момента. Во-вторых, это, вероятно, уже за пределами обсуждаемого протокола — зачем тогда "шифрование" именно внутри него, если без надстроек он ничего не обеспечивает?

Здравствуйте, Pzz, Вы писали:

Pzz>Вот смотри, вот нормальное завершение TCP сессии:
Pzz>1) A->B: FIN
Pzz>2) B->A: FIN+ACK
Pzz>3) A->B: FIN+ACK

Зачем А передаёт FIN второй раз?

Здравствуйте, Hobbes, Вы писали:

Pzz>>Вот смотри, вот нормальное завершение TCP сессии:
Pzz>>1) A->B: FIN
Pzz>>2) B->A: FIN+ACK
Pzz>>3) A->B: FIN+ACK

H>Зачем А передаёт FIN второй раз?

Оно передаёт ACK с соответствующим SN, которым подтверждает получение FIN от B. Флаги SYN, FIN считаются за 1 октет в правилах подсчёта SN, но только один раз за жизнь соединения.

FIN же ставится в 3-м пакете... ну а зачем его снимать, если передача от A уже закрыта?
Учтите при этом, что TCP допускает одностороннее закрытие на достаточно долгий период. Это выглядит, например, так:

1) A->B: 200 байт, SN=1000, ACK=5000
2) B->A: 0 байт, SN=5000, ACK=1200 (подтвердила приём 200 байт)
3) A->B: 0 байт, FIN, SN=1200, ACK=5000
4) B->A: 0 байт, SN=5000, ACK=1201 (подтвердила, что увидела FIN)
с этого момента соединение одностороннее; B может писать, но не читать
5) B->A: 1000 байт, SN=5000, ACK=1201
6) A->B: 0 байт, FIN, SN=1201, ACK=6000
... B продолжает слать ...

Да, такие сценарии редкие, но вполне законные. И при этом A нет смысла убирать флаг FIN, даже несмотря на то, что B его запомнила. Может, он кому-то ещё по дороге важен

Здравствуйте, Hobbes, Вы писали:

Pzz>>Вот смотри, вот нормальное завершение TCP сессии:
Pzz>>1) A->B: FIN
Pzz>>2) B->A: FIN+ACK
Pzz>>3) A->B: FIN+ACK

H>Зачем А передаёт FIN второй раз?

Чтобы передать ACK

Здравствуйте, netch80, Вы писали:

N>Повторится ситуация с HTTP/2, который кое-как выкрутили с двадцатой попытки, и то постоянно с проблемами

Как по мне так там нововведений на major версию недостаточно. Скорее HTTP/1.2

Здравствуйте, Cyberax, Вы писали:

C>Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы.

Что то мне кажется что в реале он как раз будет сосать что тот пылесос.
Потому что шторм UDP запросов говномиддлбоксы переваривают плохо.

Здравствуйте, Ops, Вы писали:

Pzz>>Ну например, в момент первого присоединения утюга ты можешь нажать кнопку "Это точно мой утюх, мамой клянусь!", и каждый следующий раз идентичность утюга будет проверяться вполне надежно.

Ops>Во-первых, это ненадежно, утюг злоумышленника может как раз поджидать такого момента.

Этот метод считается достаточно надежным для, например, привязывания брелков к электрическим воротам, или для привязывания bluetooth устройств. Воткнуться, конечно, в нужный момент можно, но это надо очень постараться.

Ops>Во-вторых, это, вероятно, уже за пределами обсуждаемого протокола — зачем тогда "шифрование" именно внутри него, если без надстроек он ничего не обеспечивает?

Без надстроек он обеспечивает TLS-like модель безопасности, при наличии соответствующей инфраструктуры для раздачи сертификатов.

Здравствуйте, CreatorCray, Вы писали:

C>>Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы.
CC>Что то мне кажется что в реале он как раз будет сосать что тот пылесос.
CC>Потому что шторм UDP запросов говномиддлбоксы переваривают плохо.
Они часто UDP тупо блокируют, но тут уже ничего не поделать.

В QUIC плюс в том, что он позволяет существенно уменьшить число пакетов в секунду, по сравнению с TCP.

Здравствуйте, Pzz, Вы писали:

C>>4) FEC для компенсации потерянных пакетов (возможно, что в первую версию стандарта не попадёт).
Pzz>Я читал гуглевскую статью, где они исследовали свой FEC на симуляторе. Пишут, что в большинстве сценариев с FEC'ом хуже, чем без него.
Ага, первая версия оказалась хуже, чем ничего: https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8VEjjnuCPTcLNJewj7Nk

Но они допилили его, так что сейчас стало лучше.

Здравствуйте, Cyberax, Вы писали:

C>В QUIC плюс в том, что он позволяет существенно уменьшить число пакетов в секунду, по сравнению с TCP.
Это всё будет пофигу если оно не будет работать на существующем зоопарке железа, которое никто ради одного этого прокотола не станет менять.

Здравствуйте, netch80, Вы писали:

C>>TCP закостенел. Его невозможно изменить. Простенький ECN (Explicit Congestion Notification) до сих пор не поддерживается всеми middlebox'ами, через 17 лет после RFC.
N>"C++ закостенел, потому что простейшие нормы C++11 до сих пор не поддерживаются всеми компиляторами."
Нет. В случае с С++ мне достаточно одного компилятора, который работал бы. В случае с TCP мне надо, чтобы ВСЕ узлы поддерживали новую фичу, если я Google.

N>Впрочем, будем считать, что ты ответил на вопрос. Тогда следующий — почему это вместо нормального нового стандарта TCP-like (время которого таки пришло) или SCTP (в котором есть уже почти всё нужное) нам предлагают идти калечным путём и строить что-то поверх UDP, теряя множество важных возможностей от интеграции в IP стек.
Протоколы IP-уровня все сдохли, так как middlebox'ы знают только TCP и UDP.

C>>С QUIC так не получится, так как там шифруется практически всё. Для middlebox'ов оставили один незашифрованный бит.
N>Ну вот ты впал в ту же сторону, что гугл — всё, что посреди, назвать "middlebox", назначить этому ярлыку заведомо отрицательную роль и считать свою историческую роль выполненной.
Она и есть заведомо отрицательная, так как (например) делает SCTP бесполезным.

C>>Из конкретных улучшений по сравнению с TCP:
C>>1) PMTU полностью поднят на уровень QUIC, так как на уровне IP оно всё сдохло.
N>На уровне IP его, как ни странно, за последние годы починили чуть менее, чем везде.
Не починили. Как один из видимых эффектов, DNS с DNSSEC работает нормально нынче только через TCP.

N>Если в начале 2000х я постоянно боролся с ним даже как клиент, то за последние лет 5 проблемы не видно.
Просто научились обходить.

C>>4) FEC для компенсации потерянных пакетов (возможно, что в первую версию стандарта не попадёт).
N>И будет точно так же, как с TCP? Первая версия застынет у 90% участников.
Проблема с TCP в том, что если я сейчас попробую использовать мега-кул-фичу, то заметная часть клиентов сломается. QUIC постарались сделать так, что новые мега-кул-фичи будут явно отключаться при установлении соединения.

C>>Бред.
N>Почему? Пока что всё указывает на это — гугл силой проталкивает своё крайне сырое решение, нацеленное исключительно на его интересы.
Закостеневание невыгодно всем, кроме производителей middlebox'ов. О каком контроле Гугла тут речь — непонятно, IETF от Гугла не зависит.

N>Повторится ситуация с HTTP/2, который кое-как выкрутили с двадцатой попытки, и то постоянно с проблемами (знаю места, где сначала включили его на сервере, потом выключили нафиг, ибо реализации глючные аж нимагу).
QUIC уже работает более как 5 лет в Chrome.

N>>>Я знаю проблемы TCP. Но решение от гугла, которое притягивается за уши, может быть ещё хуже.
C>>Чем?
N>Именно сыростью и однобокостью цели.
А зачем всебокий протокол?

Здравствуйте, netch80, Вы писали:

C>>Следующий драфт будет на следующей неделе.
N>"Обіцянки-цецянки" (c)
N>Будет или нет, а нормального времени на подумать миру просто не дают.
Что тут думать? Бежать надо!

C>>У QUIC есть преимущество — это протокол, который уже опробован практически.
N>Одним гуглом, да? Даже при его толщине это просто ни о чём.
https://github.com/quicwg/base-drafts/wiki/Implementations

N>Чтобы понять все проблемы, нужны как минимум две независимые реализации, одна из которых как можно ближе к режиму "чистой комнаты" просто по спеке.
N>Вживую, реальные проблемы выявляются в сильно большем разнообразии условий и источников.
Уже.

C>>Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы. Всё, больше их команду ничего не интересует. У них полная свобода творчества.
C>>Единственное условие — реализуемость протокола внутри Google Chrome.
N>А, то есть это протокол от гугла для гугла для хождения в гугл через гугл.
Ещё Facebook'а.

N>Ну, если так, то я более-менее спокоен пусть гугл сам себе стреляет в ногу.
N>Просто в таком случае непонятно, зачем им вообще IETF.
QUIC уже используют несколько крупных Интернет-гигантов.

Здравствуйте, Pzz, Вы писали:

Pzz>Этот метод считается достаточно надежным для, например, привязывания брелков к электрическим воротам, или для привязывания bluetooth устройств. Воткнуться, конечно, в нужный момент можно, но это надо очень постараться.

BT, WPS и, подозреваю, ворота с брелоками, обеспечивают это вообще на канальном уровне. А уже на уровне IP такой сценарий затруднителен, из-за меньшей локальности хостов в общем случае.

Pzz>Без надстроек он обеспечивает TLS-like модель безопасности, при наличии соответствующей инфраструктуры для раздачи сертификатов.

А в чем польза-то? Ну сделали бы этот протокол без принудительного шифрования, а сверху пустили бы тот же TLS, когда нужно.

C>>>Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы.
CC>>Что то мне кажется что в реале он как раз будет сосать что тот пылесос.
CC>>Потому что шторм UDP запросов говномиддлбоксы переваривают плохо.
C>Они часто UDP тупо блокируют, но тут уже ничего не поделать.

C>В QUIC плюс в том, что он позволяет существенно уменьшить число пакетов в секунду, по сравнению с TCP.

Это как? При старте там может быть меньше пакетов, а во время обмена данными как сделать меньше пакетов и передать тот же объем данных?

Здравствуйте, netch80, Вы писали:

N>4) B->A: 0 байт, SN=5000, ACK=1201 (подтвердила, что увидела FIN)
N>с этого момента соединение одностороннее; B может писать, но не читать

Вот я и думал, что B уже точно-точно подтвердил приём FIN, и отправлять FIN второй раз смысла нет.

Здравствуйте, Ops, Вы писали:

Pzz>>Без надстроек он обеспечивает TLS-like модель безопасности, при наличии соответствующей инфраструктуры для раздачи сертификатов.
Ops>А в чем польза-то? Ну сделали бы этот протокол без принудительного шифрования, а сверху пустили бы тот же TLS, когда нужно.
Ну начнём с того, что 0-RTT connection невозможен без шифрования на уровне протокола. Но более глубокая причина в том, что одной из целей протокола было сделать middlebox'ы невозможными. Практика показала, что иначе протоколы мгновенно закостеневают.

Здравствуйте, Masterspline, Вы писали:

C>>В QUIC плюс в том, что он позволяет существенно уменьшить число пакетов в секунду, по сравнению с TCP.
M>Это как? При старте там может быть меньше пакетов, а во время обмена данными как сделать меньше пакетов и передать тот же объем данных?
Одной из проблем в Интернете является PMTU — поиск максимального размера пакета. Потому многие серверы тупо ставят что-то типа 1380 (Google) для гарантии того, что ответы пройдут через любые разумные тоннели ( https://jamesdobson.name/post/mtu/ ).

В QUIC поиск оптимального размера пакетов вынесен на уровень протокола, и сделан так, что работает оппортунистически в фоновом режиме.

Здравствуйте, Cyberax, Вы писали:

C>Одной из проблем в Интернете является PMTU — поиск максимального размера пакета. Потому многие серверы тупо ставят что-то типа 1380 (Google) для гарантии того, что ответы пройдут через любые разумные тоннели ( https://jamesdobson.name/post/mtu/ ).

А с чего вдруг это проблема? Максимум это немного (действительно ненамного) повышает нагрузку на оборудование провайдера (затраты на маршрутизацию пакетов, но визуально это заметно когда пакеты сильно меньше килобайта. Да и в любом случае геморроя с маршрутизацией UDP будет больше). А само увеличение объёмов данных можно посчитать. Посчитаем, например, оверхэд TCP для передачи 10КБ при разных размерах пакетов:
1380: 10KB/1380 ~ 7.42 ~ 8 пакетов, длинна TCP заголовка — 20 байт, 160 байт на 10KB данных
1490: 10KB/1490 ~ 6.87 ~ 7 пакетов, длинна TCP заголовка — 20 байт, 140 байт на 10KB данных

20 байт оверхэда на 10KB информации ~ 0.2% выигрыша, причём в идеальных условиях, когда на пути только ethernet с максимальным размером кадра.

C>В QUIC поиск оптимального размера пакетов вынесен на уровень протокола, и сделан так, что работает оппортунистически в фоновом режиме.

Eye-roll — сначала браузер превратили в комбайн, теперь протокол.

ЗЫ. Ютуб тупит на любом браузере далеко не из-за протокола, но лучше ведь в очередной раз поставить интернет раком, а не фиксить свои сайты.

Здравствуйте, Cyberax, Вы писали:

Ops>>А в чем польза-то? Ну сделали бы этот протокол без принудительного шифрования, а сверху пустили бы тот же TLS, когда нужно.
C>Ну начнём с того, что 0-RTT connection невозможен без шифрования на уровне протокола. Но более глубокая причина в том, что одной из целей протокола было сделать middlebox'ы невозможными. Практика показала, что иначе протоколы мгновенно закостеневают.

Ты почему то за аксиому берешь что некое обозначенное тобой "закостеневают" это "плохо".
Не стесняйся, расскажи нам, что хорошего каждую неделю переделывать протоколы и форматы. Для кого это будет хорошо. И почему, если это так хорошо раньше этого не делали.

Здравствуйте, Somescout, Вы писали:

C>>Одной из проблем в Интернете является PMTU — поиск максимального размера пакета. Потому многие серверы тупо ставят что-то типа 1380 (Google) для гарантии того, что ответы пройдут через любые разумные тоннели ( https://jamesdobson.name/post/mtu/ ).
S>А с чего вдруг это проблема?
Увеличивает число пакетов. Именно число пакетов в секунду нынче является узким горлышком в железе.

При учёте пакетов не забываем отсутствие тройного рукопожатия, при 0-RTT сервер отправляет данные в первом же пакете.

S>Максимум это немного (действительно ненамного) повышает нагрузку на оборудование провайдера (затраты на маршрутизацию пакетов, но визуально это заметно когда пакеты сильно меньше килобайта. Да и в любом случае геморроя с маршрутизацией UDP будет больше).
ЩИТО?

S>ЗЫ. Ютуб тупит на любом браузере далеко не из-за протокола, но лучше ведь в очередной раз поставить интернет раком, а не фиксить свои сайты.
ЩИТО?