M>> Однако, после FIN пакета какое-то время могут еще летать задержавшиеся пакеты той же сессии, роутер их тоже должен будет отправить куда надо. Так что FIN для роутера тоже не очень полезен, IMHO.
Pzz>Роутер может по FINACK'у закрыть "сессию", а на все бесхозные пакеты отвечать RST туда, откуда эти пакеты пришли. Это экономно, и работает хорошо.
Т.е. мне пришел первый пакет с данными, второй с данными задержался, затем пришел третий (с FIN ACK), а второй роутер мне не станет его доставлять, потому что он сам так решил... Вот поэтому полное шифрование в HTTP/3 (QUIC) вполне оправдано. Да и не провайдерское это дело, решать за меня, какие данные мне получать, а какие нет. Такое можно делать на firewall, но пользователь должен либо точно знать, что там зафильтровано (порты 25, 137-139,445 и ничего другого), либо управлять им (отключите мне вашу защиту от DDOS, потому что у меня трафик теряется).
Кроме того, пойми, что для провайдера tcp сессия легко может выглядеть не так, как для сервера или клиента. Пакеты в одну сторону могут идти совсем по другому линку, чем в другую (так бывает очень часто). Более того, даже в одну сторону пакеты могут идти один по одному линку, другой по другому (такое редко, но возможно, потому что провайдер в случае неполадок сам запарится искать, где пакеты теряются). Так что то, что ты тут описываешь как tcp сессия для большей части оборудования провайдера выглядит как набор пакетов и часть пакетов из этой сессии просто недоступна и в этих условиях это оборудование должно работать надежно, т.е. ориентироваться на FIN,ACK никак нельзя. Сессия будет видна только на маршрутизаторе, который является default gateway клиента (да и то не факт).
Здравствуйте, Masterspline, Вы писали:
Pzz>>Ну там, наверное, предсмотрено периодически пинги гнать. Чтобы NAT не забывал, да и вообще, чтобы убедиться, что на другом конце соединения никто еще не умер.
M>Через 30 секунд у тебя 5% NAT'ов забывают UDP сессию, через минуту уже почти 50% (через 5 минут все 100%).
Это откуда такие сведения?
Я достаточно много протрахался с NAT'ами. По моим наблюдениям, они держат сессию больше 30 секунд.
M>Т.е. зашел ты с мобилки на сайт с WebSocket (по сути любой сайт) и у тебя JavaScript в каждой странице каждые 20 секунд должен в сеть отправлять пакет и читать, что вернулось, причем даже если страница в фоне (JS в фоне, вроде не работает или работает как-то с ограничениями).
Я полагаю, это QUIC делает сам, без напоминания со стороны яваскрипта. Ровно так же, как TCP сам делает TCP keep-alive.
Pzz>>А что, в HTTP/3 не предусмотрели аналога вебсокета?
M>Веб сокет там есть, как и в любом HTTP, но как предотвратить закрытие UDP сессии на NAT клиента (клиент — мобилка). Потому IPv6 рулит, однозначно. Там решена одна из самых неприятных проблем провайдеров — NAT (его там нет).
Здравствуйте, Masterspline, Вы писали:
Pzz>>Роутер может по FINACK'у закрыть "сессию", а на все бесхозные пакеты отвечать RST туда, откуда эти пакеты пришли. Это экономно, и работает хорошо.
M>Т.е. мне пришел первый пакет с данными, второй с данными задержался, затем пришел третий (с FIN ACK), а второй роутер мне не станет его доставлять, потому что он сам так решил...
FINACK посылается в ответ на FIN. Пока тебе не пришли все данные, и FINACK не придет.
M>Кроме того, пойми, что для провайдера tcp сессия легко может выглядеть не так, как для сервера или клиента. Пакеты в одну сторону могут идти совсем по другому линку, чем в другую (так бывает очень часто).
Теоретически могут. Но магистральные провайдеры знают, когда могут, а когда нет.
M>>Через 30 секунд у тебя 5% NAT'ов забывают UDP сессию, через минуту уже почти 50% (через 5 минут все 100%).
Pzz>Это откуда такие сведения?
Отсюда (Ctrl+F "Дополнительная плюшка по поводу UDP").
M>>Т.е. зашел ты с мобилки на сайт с WebSocket (по сути любой сайт) и у тебя JavaScript в каждой странице каждые 20 секунд должен в сеть отправлять пакет и читать, что вернулось, причем даже если страница в фоне (JS в фоне, вроде не работает или работает как-то с ограничениями).
Pzz>Я полагаю, это QUIC делает сам, без напоминания со стороны яваскрипта. Ровно так же, как TCP сам делает TCP keep-alive.
QUIC — это полностью userspace код. К ядру там обращаются только для отправки и приема UDP пакетов.
Pzz>>>А что, в HTTP/3 не предусмотрели аналога вебсокета?
M>>Веб сокет там есть, как и в любом HTTP, но как предотвратить закрытие UDP сессии на NAT клиента (клиент — мобилка). Потому IPv6 рулит, однозначно. Там решена одна из самых неприятных проблем провайдеров — NAT (его там нет).
Pzz>В HTTP/2 вебсокета нет.
В смысле ты не можешь сделать Upgrade (или как там это называется), чтобы создать WebSocket соединение? Это же фишка HTTP. Для меня это новость.
Здравствуйте, Masterspline, Вы писали:
M>Отсюда (Ctrl+F "Дополнительная плюшка по поводу UDP").
Спасибо, очень интересная статья.
Pzz>>Я полагаю, это QUIC делает сам, без напоминания со стороны яваскрипта. Ровно так же, как TCP сам делает TCP keep-alive.
M>QUIC — это полностью userspace код. К ядру там обращаются только для отправки и приема UDP пакетов.
И что с того? Ты же не хочешь сказать, что в юзерспейсе невозможна фоновая активность?
Pzz>>В HTTP/2 вебсокета нет.
M>В смысле ты не можешь сделать Upgrade (или как там это называется), чтобы создать WebSocket соединение? Это же фишка HTTP. Для меня это новость.
HTTP/2 сам образуется в результате апгрейда с HTTP/1.1, и возможности второго апгрейда там не предусмотренно.
Pzz>>>Я полагаю, это QUIC делает сам, без напоминания со стороны яваскрипта. Ровно так же, как TCP сам делает TCP keep-alive.
M>>QUIC — это полностью userspace код. К ядру там обращаются только для отправки и приема UDP пакетов.
Pzz>И что с того? Ты же не хочешь сказать, что в юзерспейсе невозможна фоновая активность?
Активность возможна, но я сомневаюсь, что такое реализовано (да и не помню я ничего про keepalive в QUIC). Однако, если каждая вкладка в браузере мобильника будет каждые 20 секунд отправлять и принимать keepalive, то никакие оптимизации не помогут сохранить батарейку (даже если работать будет не код приложения, но часть ядра, обслуживающая сеть все-таки должна работать). Кроме того, на мобилке все равно приключиться потеря сети больше, чем на 20 секунд и тогда уже нужно полностью переустанавливать сессию и тут потребуется работа всего кода ниже JavaScript (не только в ядре ОС), или даже вместе с JS. В общем такой ping-alive в QUIC — батарейка кирдык.
На мобилках настолько стараются беречь батарейку, что во время бездействия может вообще ничего не работать довольно длительное время. Подробности я не очень знаю (к тому же на том же Android это постоянно меняется и довольно заметно), но если бы можно было держать запущенным в фоне приложение даже с tcp сессией (пока не бегают данные, ни один такт CPU не тратится), то гугловый сервис рассылки уведомлений не был бы никому нужен. Можно было бы обойтись tcp сессией с собственным сервером (когда данные не бегают — приложение не работает, а keepalive там достаточно раз в пару часов кидать для чего достаточно будить ядро ОС мобилки раз в 2 часа). Однако, рассылка уведомлений на Android довольно актуальная тема и многие крупные конторы реализуют собственную схему, потому что привязка к гуглу и его ограничения не всем подходят. С таким раскладом никаких keepalive каждые 20 секунд для каждой вкладки в браузере не может быть.
Здравствуйте, vsb, Вы писали:
vsb>>>Сейчас надо использовать QUIC. TCP уже устарел.
N>>QUIC можно предлагать на замену HTTP, да. Но при чём тут TCP? N>>Или вы для TCP никакого применения, кроме HTTP, не знаете?
vsb>А при чём тут вообще HTTP? QUIC это протокол нижнего уровня. Поверх него можно гнать HTTP. А можно что угодно.
Таки да. Я ориентировался на ранние версии, там ещё была связь. Нынешний, даром что ещё не определён до конца, это мультиплексор произвольных байтовых потоков.
Но всё равно утверждение про устарелость выглядит поспешным.
Например, проблема серверного сокета. В случае TCP отцепить сокет на соединение — штатная операция (собственно, accept() это делает). Что делать в случае UDP? Даже если гугл завтра запилит соответствующее решение в своей версии Linux и Fuchsia, то это будет какая-то форма костыля.
Дальше, что делать, если не предполагается шифрование (оно не нужно вообще или обеспечено внешними средствами, типа IPSec)?
Наконец, спек QUIC до сих пор не имеет принципиально важных частей вроде connection lifetime. Ориентироваться на 1-2 реализации без твёрдого спека нельзя.
Здравствуйте, Masterspline, Вы писали:
M>Веб сокет там есть, как и в любом HTTP, но как предотвратить закрытие UDP сессии на NAT клиента (клиент — мобилка). Потому IPv6 рулит, однозначно. Там решена одна из самых неприятных проблем провайдеров — NAT (его там нет).
NAT нет (хотя можно и сделать), но проблема аж никак не решена.
Пусть у тебя IPv6 клиент с честным мировым адресом. Если допустить на него произвольные соединения извне, то получится то же, что сейчас шумит в виде новостей "очередные хакеры сломали 100500 виндей через RDP и CIFS".
Если не допускать такого, то будет то же, что с NAT, кроме несовпадения адресов: таймаут прошёл — доступ пакетов закрылся.
А при подходе QUIC типа "промежуточные узлы могут знать только один бит, остальное зашифровано" у них и не будет, как на TCP, возможности подольше подержать установленное соединение.
Здравствуйте, netch80, Вы писали:
N>Таки да. Я ориентировался на ранние версии, там ещё была связь. Нынешний, даром что ещё не определён до конца, это мультиплексор произвольных байтовых потоков.
Угу, разделили всё. Стандартизация идёт на пользу.
N>Например, проблема серверного сокета. В случае TCP отцепить сокет на соединение — штатная операция (собственно, accept() это делает). Что делать в случае UDP? Даже если гугл завтра запилит соответствующее решение в своей версии Linux и Fuchsia, то это будет какая-то форма костыля.
Я может чего-то не понимаю. Но сейчас же UDP-серверы прекрасно работают.
N>Дальше, что делать, если не предполагается шифрование (оно не нужно вообще или обеспечено внешними средствами, типа IPSec)?
Здравствуйте, vsb, Вы писали:
N>>Например, проблема серверного сокета. В случае TCP отцепить сокет на соединение — штатная операция (собственно, accept() это делает). Что делать в случае UDP? Даже если гугл завтра запилит соответствующее решение в своей версии Linux и Fuchsia, то это будет какая-то форма костыля. vsb>Я может чего-то не понимаю. Но сейчас же UDP-серверы прекрасно работают.
Это не "прекрасно", когда часть соединений нельзя отделить в другой тред/процесс.
На TCP это перебрасывается запросто в пределах одного экземпляра стека (контейнера, хоста).
Можно исхитриться сделать это на разделении IP, например. Но опять же это статика, если в протоколе нет явных
команд "переключись на другой ремотный адрес", то управление нагрузкой резко усложняется.
N>>Дальше, что делать, если не предполагается шифрование (оно не нужно вообще или обеспечено внешними средствами, типа IPSec)? vsb>Угу, IPSec: https://www.zdnet.com/article/new-vulnerability-lets-attackers-sniff-or-hijack-vpn-connections/ даже если вы думаете, что вам не нужно шифрование, оно всё равно вам нужно.
Закроют. Но на прошлой работе, например, получалось местами, что шифрование в само соединение не вворачивается принципиально — существующие средства это не вытягивают функционально. Поэтому строились туннели.
Здравствуйте, Masterspline, Вы писали:
Pzz>>И что с того? Ты же не хочешь сказать, что в юзерспейсе невозможна фоновая активность?
M>Активность возможна, но я сомневаюсь, что такое реализовано (да и не помню я ничего про keepalive в QUIC). Однако, если каждая вкладка в браузере мобильника будет каждые 20 секунд отправлять и принимать keepalive, то никакие оптимизации не помогут сохранить батарейку (даже если работать будет не код приложения, но часть ядра, обслуживающая сеть все-таки должна работать).
Мобильник потратит на отправку одного пакета микросекунд сто, со всеми шифрованиями и прочей мутью. Т.е., одна вкладка, отправляющая пакеты каждые 20 секунд, загрузит процессор аж на 0.0005%. Сто вкладок, число, совершенно невероятное для мобильника, загрузит процессор аж на 0.05%. В общем, было бы, о чем переживать.
M>На мобилках настолько стараются беречь батарейку, что во время бездействия может вообще ничего не работать довольно длительное время. Подробности я не очень знаю (к тому же на том же Android это постоянно меняется и довольно заметно), но если бы можно было держать запущенным в фоне приложение даже с tcp сессией (пока не бегают данные, ни один такт CPU не тратится), то гугловый сервис рассылки уведомлений не был бы никому нужен.
На андроидах с этим довольно либерально. Вот на макакосе, там да, фоновым приложениям в общем случае разрешается только спать, и даже сны видеть не разрешается. Но бывают и исключения (технически они возможны). Договорится ли гугль с эплом о таком исключении — вопрос чисто политический.
M>Можно было бы обойтись tcp сессией с собственным сервером (когда данные не бегают — приложение не работает, а keepalive там достаточно раз в пару часов кидать для чего достаточно будить ядро ОС мобилки раз в 2 часа).
Если статистика моего телефона не врет, основные потребители электричества — это "Сервисы Google Play", "Платформа Android", "ОС Android", "Режим ожидания", "Экран" и "Сеть оператора связи". Причем нафиг мне не нижный "Google Play" лидирует с большим отрывом.
Так что не надо мне пересказывать чужие сказки о том, как на мобиле берегут батарейку. Для своего браузера, разумеется, гугль сделает исключение при необходимости.
Здравствуйте, ononim, Вы писали:
Pzz>>(TLS+TCP требует сначала пары round-trip'ов, чтобы договориться о TCP, а потом примерно столько же, чтобы договориться о шифровании, O>Это не так если использовать TCP fast open и TLS 0-RTT:
Да, я в курсе. Я рассматриваю худший случай для TCP+TLS, чтобы оценить максимальную выгоду от QUIC.
На самом деле, TCP fast open и TLS 0-RTT работают все же, если соединение достаточно быстро переоткрывается. Но в этом случае работает и HTTP keep-alive.
O>>Это не так если использовать TCP fast open и TLS 0-RTT: Pzz>Да, я в курсе. Я рассматриваю худший случай для TCP+TLS, чтобы оценить максимальную выгоду от QUIC.
Ну, худший случай это закрытый порт 443
Pzz>На самом деле, TCP fast open и TLS 0-RTT работают все же, если соединение достаточно быстро переоткрывается. Но в этом случае работает и HTTP keep-alive.
Ну время хранения кук настраиваемо. Кроме того подозпреваю что у QUIC под капотом аналогичные механизмы, но ковырять этого монстрика пока не приходилось, тьфутьфутьфу.
Как много веселых ребят, и все делают велосипед...
Pzz>Мобильник потратит на отправку одного пакета микросекунд сто, со всеми шифрованиями и прочей мутью. Т.е., одна вкладка, отправляющая пакеты каждые 20 секунд, загрузит процессор аж на 0.0005%. Сто вкладок, число, совершенно невероятное для мобильника, загрузит процессор аж на 0.05%. В общем, было бы, о чем переживать.
Дело не только в циклах CPU. Выход из глубокого сна и впадение в него для SoC сама по себе дорогостоящая в плане энергопотребления вещь, так что нет большой разницы будет там 0.0005%CPU протрачено или 0.5%. Основные джоули будут потрачены на запуск и стабилизацию PLL в генератора тактовой частоты и завершения прочих переходных процессов: https://www.embedded.com/understanding-mcu-sleep-modes-and-energy-savings/
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Дело не только в циклах CPU. Выход из глубокого сна и впадение в него для SoC сама по себе дорогостоящая в плане энергопотребления вещь, так что нет большой разницы будет там 0.0005%CPU протрачено или 0.5%. Основные джоули будут потрачены на запуск и стабилизацию PLL в генератора тактовой частоты и завершения прочих переходных процессов: https://www.embedded.com/understanding-mcu-sleep-modes-and-energy-savings/
Здравствуйте, ononim, Вы писали:
Pzz>>Я хочу сказать, это копейки в любом случае. O>вот изза таких наплевателей на копейки у меня на мобиле нету скайпа
В скайпе понаплевано не на копейки, а на рубли. Если не на сотни рублей.
Pzz>>(TLS+TCP требует сначала пары round-trip'ов, чтобы договориться о TCP, а потом примерно столько же, чтобы договориться о шифровании, O>Это не так если использовать TCP fast open и TLS 0-RTT:
Будет ли TCP fast open работать при смене IP клиента? Насколько я знаю, нет.
Pzz>>>(TLS+TCP требует сначала пары round-trip'ов, чтобы договориться о TCP, а потом примерно столько же, чтобы договориться о шифровании, O>>Это не так если использовать TCP fast open и TLS 0-RTT: M>Будет ли TCP fast open работать при смене IP клиента? Насколько я знаю, нет.
Смена ип клиента сама по себе не быстрая операция, странно экономить на спичках спалив тонну дров.
Как много веселых ребят, и все делают велосипед...
