Здравствуйте, netch80, Вы писали:
N>Не пофиг. Где-то есть сущности, персистентные между соединениями, где-то нет.
Ты имеешь ввиду кэширующие прокси сервера всякие?
Здравствуйте, Kernan, Вы писали:
N>>Не пофиг. Где-то есть сущности, персистентные между соединениями, где-то нет. K>Ты имеешь ввиду кэширующие прокси сервера всякие?
При чём тут прокси?
Могут быть элементы состояния, связанные с конкретной парой клиент-сервер, с конкретным клиентом или его сессией.
А где-то их крайне неудобно вводить или вообще нельзя (секьюрити) за пределами одного сетевого соединения. Пока соединение живо — живо и его соответствующее состояние, умерло — отменяем.
То же самое может быть на основе идентификации (авторизованной) вместо соединения. В вебе есть куки. Две стороны на каком-нибудь FIX обязаны хранить состояние друг друга в пределах предполагаемого времени жизни сессии. На протоколах типа UUCP есть докачка. На связях с базой данных мы строим идентификацию клиента, чтобы убивать залипшие соединения. И так далее.
vsb>Сейчас надо использовать QUIC. TCP уже устарел.
QUIC — это UDP. Там 99% соединений из NAT пропадает в течение 5 минут. Т.е. Websocket там не выживет.
IMHO, останется со временем из HTTP только 1.1. и 3.0 и они будут дополнять друг друга. 1.1 для websocket и legacy, 3.0 для остального. HTTP/2.0 при наличии 3.0 не особо нужен, поэтому исчезнет.
vsb>>Кстати, а о каких именно проблемах речь?
Pzz>Ну не рассчитаны все эти дивные сетевые коробочки, из которых свинчен интернет, на то, что по ним пойдет UDP тугим потоком. Пакеты TCP естесвенным образом образуют поток, и все, довольно дорогие, роутинговые решения можно принять один раз, а потом отправлять каждый следующий пакет уже по накатанным рельсам, а в случае UDP каждый пакет роутится отдельно.
Насколько я знаю, аппаратные маршрутизаторы (да и программные, типа WiFi роутера в квартире) роутят по IP адресу. Разница между TCP и UDP может проявиться в очень экзотических ситуациях (типа DPI яровой умеет инспектировать TCP потоки, а все UDP потоки помечает как подозрительные и отправляет на отдельную железку, ресурсы которой более ограничены). Так что провайдерам безразлично что роутить. Для NAT'а есть разница, он не увидит конец QUIC сессии, поэтому там настроены жесткие таймауты. А вот на сервере работа с UDP (по данным из интернет) в ядре Linux в разы CPU-емкая (раз в 8). Клиенту на это наплевать, у него только несколько соединений, а контент провайдеру есть разница.
Так что, IMHO, все не так страшно, как ты тут пытаешься изобразить. Если интернет провайдерам что-то и придется поменять, то не всю инфраструктуру, а хостеры приложений справятся (Гугл, например, совсем не переживает по этому поводу, они же сами все это и затеяли).
Pzz>Что для автоматической миграции, я плохо знаю, как она устроена в QUIC, и рассуждать о ней не могу.
Pzz>У QUIC и HTTP/2 примерно одинаковая семантика, но QUIC в некоторых случаях работает быстрее. Это вопрос эффективности, а не новых возможностей.
Большая часть HTTP клиентов сейчас — это мобилки, которые щас выходят в сеть через домашний WiFi, затем через GSM (G$,5,LTS или как оно там называется), а затем через офисный WiFi и каждый раз с новым IP. В QUIC специально решали задачу, чтобы не нужно было каждый раз устанавливать новую сессию, для этого там передается что-то типа номера сессии внутри QUIC протокола и не важно, с какого IP пришел пакет. Также там сделаны 0-RTT восстановление сессии. В TCP есть fast open, в TLS 1.3 есть 0-RTT восстановление, которые в теории дают нечто похожее, но все это не работает при смене IP (а таких клиентов, как я уже писал, больше половины). Кроме того, HTTP/2.0 — это TCP и там потеря пакета стопорит все мультиплексируемые потоки, в QUIC (UDP) это исправлено. Так что, как я уже писал, останется только HTTP/3.0 (модифицированный QUIC) и HTTP/1.1 для веб сокетов и старта HTTP/3.0.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну не рассчитаны все эти дивные сетевые коробочки, из которых свинчен интернет, на то, что по ним пойдет UDP тугим потоком.
Так торренты уже вроде давно идут. Да и ютубы всякие уже давно через gQUIC работают, вроде достаточно весомый объём трафика должен быть. Так что может не всё так плохо?
Pzz>Пакеты TCP естесвенным образом образуют поток, и все, довольно дорогие, роутинговые решения можно принять один раз, а потом отправлять каждый следующий пакет уже по накатанным рельсам, а в случае UDP каждый пакет роутится отдельно.
Почему? По адресу и порту разве какая-то проблема сопоставить пакеты?
Pzz>Все это, конечно, починят со временем. Но вряд ли крупные провайдеры побегут в магазин за новыми кисками просто потому, что гуглю так приспичило. И киска тоже вряд ли починит эти проблемы тривиальным апгрейдом прошивки, скорее они новые коробочки понавыпускают. А сейчас провайдеры просто поставят UDP-трафику приоритет пониже, чтобы он их инфраструктуру с ума не сводил, и будут жить дальше, как прежде.
А юзеры будут жаловаться, что интернет тормозит и уходить к другим провайдерам.
vsb>>QUIC даёт шифрование, мультиплексирование и автоматическую миграцию при смене адреса. По-моему все три фичи жизненно необходимы в любом сетевом софте.
Pzz>По сравнению с HTTP/2, QUIC дает, в некоторых случаях, более быстрый старт соединения (TLS+TCP требует сначала пары round-trip'ов, чтобы договориться о TCP, а потом примерно столько же, чтобы договориться о шифровании, а QUIC позволяет это совместить, и плюс потом еще round-trip, чтобы договориться о переходе от HTTP/1.1 до HTTP/2).
Другими словами начало соединения в HTTP/2 неимоверно дорогое. Ты так говоришь, как будто с локалхостом соединяешься, пара раунд-трипов сюда, пара сюда. А по факту пинг в мобильной сети до какой-нибудь америки легко может быть в сотни миллисекунд и эти пары раундтрипов это единицы секунд. Это очень много.
А ещё TCP разгоняется неимоверно медленно. Там, где я по гигабитному каналу мог бы вытаскивать мегабитные страницы за доли секунды, он будет кочегариться несколько секунд. И не дай бог пакет потеряется, это всё, вселенская беда, всё наше мультиплексирование зависает, пока этот несчастный пакет, в котором кусок картинки, которую юзер даже не видит, не придет. И потом опять разгоняться. Ух.
Здравствуйте, netch80, Вы писали:
vsb>>Сейчас надо использовать QUIC. TCP уже устарел.
N>QUIC можно предлагать на замену HTTP, да. Но при чём тут TCP? N>Или вы для TCP никакого применения, кроме HTTP, не знаете?
А при чём тут вообще HTTP? QUIC это протокол нижнего уровня. Поверх него можно гнать HTTP. А можно что угодно.
Здравствуйте, Masterspline, Вы писали:
vsb>>Сейчас надо использовать QUIC. TCP уже устарел.
M>QUIC — это UDP. Там 99% соединений из NAT пропадает в течение 5 минут. Т.е. Websocket там не выживет.
Сложно раз в 5 минут послать пинг? Или о чём речь? Так-то и TCP может зависнуть по неизвестным науке причинам. В любом случае надо постоянно пинговать и переустанавливать соединение, если по таймауту не ответили.
Здравствуйте, Masterspline, Вы писали:
M>Насколько я знаю, аппаратные маршрутизаторы (да и программные, типа WiFi роутера в квартире) роутят по IP адресу. Разница между TCP и UDP может проявиться в очень экзотических ситуациях (типа DPI яровой умеет инспектировать TCP потоки, а все UDP потоки помечает как подозрительные и отправляет на отдельную железку, ресурсы которой более ограничены).
Принятие роутингового решения — это достаточно дорогая операция. Для TCP ее результаты кешируются в контексте TCP-потока. Для UDP это тоже можно сделать, но придется как-то научиться выделять UDP-потоки, и соображать, когда поток закончился. В до-QUICовских маршрутизаторах этого сделано не было, за неимением нужды, поэтому они имеют тенденцию отдельно роутить каждый UDP-поток, или около того.
M>Так что, IMHO, все не так страшно, как ты тут пытаешься изобразить. Если интернет провайдерам что-то и придется поменять, то не всю инфраструктуру, а хостеры приложений справятся (Гугл, например, совсем не переживает по этому поводу, они же сами все это и затеяли).
Ну гугль, наверное, заранее подготовился.
С провайдерамы я время от времени общаюсь. Им вся эта возня с UDP не нравится.
Здравствуйте, Masterspline, Вы писали:
Pzz>>У QUIC и HTTP/2 примерно одинаковая семантика, но QUIC в некоторых случаях работает быстрее. Это вопрос эффективности, а не новых возможностей.
M>Большая часть HTTP клиентов сейчас — это мобилки, которые щас выходят в сеть через домашний WiFi, затем через GSM (G$,5,LTS или как оно там называется), а затем через офисный WiFi и каждый раз с новым IP. В QUIC специально решали задачу, чтобы не нужно было каждый раз устанавливать новую сессию, для этого там передается что-то типа номера сессии внутри QUIC протокола и не важно, с какого IP пришел пакет.
В TLS тоже есть рестарт сессии. Но я не знаю, насколько это важно именно в контексте переключения мобилки с WiFi на сотовую сеть. Во-первых, это нечастая операция. Во-вторых, пока мобилка переключится, сколько-то времени пройдет. Не факт, что сохраненная сессия столько проживет, серверу тоже дорого хранить их до бесконечности.
M>Также там сделаны 0-RTT восстановление сессии. В TCP есть fast open, в TLS 1.3 есть 0-RTT восстановление, которые в теории дают нечто похожее, но все это не работает при смене IP (а таких клиентов, как я уже писал, больше половины).
Ну я и говорю, по большей части оптимизация. Я, кстати, не понимаю, почему бы восстановлению сессии в TLS не работать при смене IP-адреса.
M>Кроме того, HTTP/2.0 — это TCP и там потеря пакета стопорит все мультиплексируемые потоки, в QUIC (UDP) это исправлено.
Это да. Они, интересно, сообразили хоть для мултимедийных потоков предусмотреть возможность допускать иногда потерю данных вместо замирания потока?
M>Так что, как я уже писал, останется только HTTP/3.0 (модифицированный QUIC) и HTTP/1.1 для веб сокетов и старта HTTP/3.0.
Здравствуйте, vsb, Вы писали:
Pzz>>Ну не рассчитаны все эти дивные сетевые коробочки, из которых свинчен интернет, на то, что по ним пойдет UDP тугим потоком.
vsb>Так торренты уже вроде давно идут.
По этому поводу провайдеры уже выли.
vsb>Да и ютубы всякие уже давно через gQUIC работают, вроде достаточно весомый объём трафика должен быть. Так что может не всё так плохо?
Ютьюбы идут в среднем через CDN. Т.е., у достаточно крупного провайдера "сервер" ютьюба находится прямо на площадке провайдера, или где-то совсем рядом.
Pzz>>Пакеты TCP естесвенным образом образуют поток, и все, довольно дорогие, роутинговые решения можно принять один раз, а потом отправлять каждый следующий пакет уже по накатанным рельсам, а в случае UDP каждый пакет роутится отдельно.
vsb>Почему? По адресу и порту разве какая-то проблема сопоставить пакеты?
Роутинговые решения довольно дорогие, и их надо кешировать. Для TCP это сделано в контексте TCP-соединения. Для UDP на старом оборудовании это не сделано. А менять старое оборудование на новое только потому, что гуглю это приспичило, провайдерам дороговато.
Pzz>>А сейчас провайдеры просто поставят UDP-трафику приоритет пониже, чтобы он их инфраструктуру с ума не сводил, и будут жить дальше, как прежде.
vsb>А юзеры будут жаловаться, что интернет тормозит и уходить к другим провайдерам.
И выяснят, что у других провайдеров все не сильно лучше, поэтому и жаловаться не на что.
Еще, я полагаю, провайдеры могут на существующем оборудовании протоптать для UDP быструю дорожку к гугловым серверам и прочему крупняку, а простым людям придется подождать с внедрением QUICа на свооих серверах.
vsb>Другими словами начало соединения в HTTP/2 неимоверно дорогое. Ты так говоришь, как будто с локалхостом соединяешься, пара раунд-трипов сюда, пара сюда. А по факту пинг в мобильной сети до какой-нибудь америки легко может быть в сотни миллисекунд и эти пары раундтрипов это единицы секунд. Это очень много.
В HTTP это сильно скомпенсировано тем, что соединения долгоживущие (HTTP keep alive).
vsb>А ещё TCP разгоняется неимоверно медленно. Там, где я по гигабитному каналу мог бы вытаскивать мегабитные страницы за доли секунды, он будет кочегариться несколько секунд. И не дай бог пакет потеряется, это всё, вселенская беда, всё наше мультиплексирование зависает, пока этот несчастный пакет, в котором кусок картинки, которую юзер даже не видит, не придет. И потом опять разгоняться. Ух.
В QUIC примерно те же алгоритмы разгона соединения, что и в TCP. Других-то не придумано. Поэтому что современный TCP, что QUIC разгоняются примерно одинаково.
Здравствуйте, Masterspline, Вы писали:
M>QUIC — это UDP. Там 99% соединений из NAT пропадает в течение 5 минут. Т.е. Websocket там не выживет.
Ну там, наверное, предсмотрено периодически пинги гнать. Чтобы NAT не забывал, да и вообще, чтобы убедиться, что на другом конце соединения никто еще не умер.
M>IMHO, останется со временем из HTTP только 1.1. и 3.0 и они будут дополнять друг друга. 1.1 для websocket и legacy, 3.0 для остального. HTTP/2.0 при наличии 3.0 не особо нужен, поэтому исчезнет.
А что, в HTTP/3 не предусмотрели аналога вебсокета?
M>>Насколько я знаю, аппаратные маршрутизаторы (да и программные, типа WiFi роутера в квартире) роутят по IP адресу. Разница между TCP и UDP может проявиться в очень экзотических ситуациях (типа DPI яровой умеет инспектировать TCP потоки, а все UDP потоки помечает как подозрительные и отправляет на отдельную железку, ресурсы которой более ограничены).
Pzz>Принятие роутингового решения — это достаточно дорогая операция. Для TCP ее результаты кешируются в контексте TCP-потока. Для UDP это тоже можно сделать, но придется как-то научиться выделять UDP-потоки, и соображать, когда поток закончился. В до-QUICовских маршрутизаторах этого сделано не было, за неимением нужды, поэтому они имеют тенденцию отдельно роутить каждый UDP-поток, или около того.
Аппаратный роутер работает примерно так же, как и свитч, только использует DST IP пакета, а не его MAC. При прохождении первого пакета CPU маршрутизатора в ASIC записывает IP адрес назначения, дальнейшая маршрутизация делается аппаратно. Программные роутеры тоже работают по IP адресу назначения. Так что разницы между TCP и UDP я не знаю. Есть еще policy routing, там могут использоваться порты, протоколы, адрес источника, но опять же там нет разницы между TCP и UDP. Я вообще не в курсе, что такое для маршрутизатора TCP поток. В пограничных шлюзах, которые отливают netflow, это имеет значение, но опять же там нет разницы между TCP и UDP (для отслеживания потока используется набор 2 IP, порты, номер протокола и разницы между протоколом 6 и 17 нет). Про NAT я уже писал. В общем, разница между TCP и QUIC (UDP) в том, что конец tcp сессии можно отследить по FIN, а в QUIC такого нет (там все зашифровано как раз с целью, чтобы промежуточные провайдеры не понаделали железок, которые отслеживают содержимое, после чего этот протокол поменять нельзя, потому что где-то ожидают увидеть нулевой бит, а он стал 1). Однако, после FIN пакета какое-то время могут еще летать задержавшиеся пакеты той же сессии, роутер их тоже должен будет отправить куда надо. Так что FIN для роутера тоже не очень полезен, IMHO.
Pzz>С провайдерамы я время от времени общаюсь. Им вся эта возня с UDP не нравится.
Я работал у провайдеров (системным админом и сидел рядом с сетевиками, так что в теме), только с тех пор прошло некоторое время. Про неприязнь UDP интереснее было бы подробнее узнать, иначе это переливание из пустого в порожнее. Повторюсь, я не в курсе, чем QUIC хуже tcp для провайдера, хотя интересуюсь этим. IMHO, если какие-то накладные расходы и есть, то небольшие и в очень экзотических случаях. Даже с какой-нибудь приоритезацией не сравнить, не говоря уже про СОРМ, DPI роскомнадзора и закон яровой.
Pzz>Ну я и говорю, по большей части оптимизация. Я, кстати, не понимаю, почему бы восстановлению сессии в TLS не работать при смене IP-адреса.
TLS может и восстановится, а TCP fast open не сработает при смене IP.
M>>Кроме того, HTTP/2.0 — это TCP и там потеря пакета стопорит все мультиплексируемые потоки, в QUIC (UDP) это исправлено.
Pzz>Это да. Они, интересно, сообразили хоть для мултимедийных потоков предусмотреть возможность допускать иногда потерю данных вместо замирания потока?
Как я понимаю, это можно делать самому. Просто не отдавай в сеть пакеты с видео или аудио, которое точно не успеет доставиться вовремя. Чуваки из mail.ru такое сделали (у них аналог QUIC, причем две версии протокола для разных задач).
Раз, два.
M>>Так что, как я уже писал, останется только HTTP/3.0 (модифицированный QUIC) и HTTP/1.1 для веб сокетов и старта HTTP/3.0.
Pzz>Для старта HTTP/3 не нужен HTTP/1.1
Я в браузере набираю "https_://google.com/", как он сообразит, что нужно использовать http/3.0 (UDP), а не tcp+tls? Про ALPN и NPN я в курсе.
Здравствуйте, Masterspline, Вы писали:
M>Аппаратный роутер работает примерно так же, как и свитч, только использует DST IP пакета, а не его MAC. При прохождении первого пакета CPU маршрутизатора в ASIC записывает IP адрес назначения, дальнейшая маршрутизация делается аппаратно.
Выяснение адреса назначения может для роутера быть нетривиальной задачей, в отличии от выяснения адреса назначения для ethernet-свитча. И поскольку в ASIC'е места не бесконечно, то нельзя туда просто пихнуть адрес, и забыть.
Я понимаю, что логически нет разницы, какие пакеты роутить. Но с точки зрения управления кешом роутинговых решений, эта разница есть. TCP имел тенденцию образовывать потоки, UDP, до появления сначала BT over UDP, а потом QUIC'а, такой тенденции не имел. Т.е., кешировать роутинговое решение для UDP особого смысла не было, их никто и не кешировал. А теперь вот смысл появился.
M>В общем, разница между TCP и QUIC (UDP) в том, что конец tcp сессии можно отследить по FIN, а в QUIC такого нет (там все зашифровано как раз с целью, чтобы промежуточные провайдеры не понаделали железок, которые отслеживают содержимое, после чего этот протокол поменять нельзя, потому что где-то ожидают увидеть нулевой бит, а он стал 1).
Если в QUIC невозможно отследить конец сессии, то гугль — злобные враги человечества, сетевых провайдеров и всего мира.
M> Однако, после FIN пакета какое-то время могут еще летать задержавшиеся пакеты той же сессии, роутер их тоже должен будет отправить куда надо. Так что FIN для роутера тоже не очень полезен, IMHO.
Роутер может по FINACK'у закрыть "сессию", а на все бесхозные пакеты отвечать RST туда, откуда эти пакеты пришли. Это экономно, и работает хорошо.
Здравствуйте, Masterspline, Вы писали:
Pzz>>Ну я и говорю, по большей части оптимизация. Я, кстати, не понимаю, почему бы восстановлению сессии в TLS не работать при смене IP-адреса.
M>TLS может и восстановится, а TCP fast open не сработает при смене IP.
Да и черт бы с ним. Смена IP-адреса — операция небыстрая. TCP handshake на ее фоне особой погоды не делает.
M>Как я понимаю, это можно делать самому. Просто не отдавай в сеть пакеты с видео или аудио, которое точно не успеет доставиться вовремя. Чуваки из mail.ru такое сделали (у них аналог QUIC, причем две версии протокола для разных задач).
Самому много чего можно сделать. Мне любопытно, предусмотрена ли такая возможность именно в протоколе QUIC.
M>Раз, два.
Угу. Я тоже так умею.
Pzz>>Для старта HTTP/3 не нужен HTTP/1.1
M>Я в браузере набираю "https_://google.com/", как он сообразит, что нужно использовать http/3.0 (UDP), а не tcp+tls? Про ALPN и NPN я в курсе.
Я не то, чтобы читаю ежедневные (или, хотя бы, ежемесячные) новости из мира QUIC, но раньше, помнится, сушествовал механизм, с помощью которого браузер как-то сам, без помощи HTTP/1.1 соображал, что можно бы попробовать по QUIC'у подсоединиться.
Pzz>Роутинговые решения довольно дорогие, и их надо кешировать. Для TCP это сделано в контексте TCP-соединения. Для UDP на старом оборудовании это не сделано. А менять старое оборудование на новое только потому, что гуглю это приспичило, провайдерам дороговато.
Во-первых, маршрутизация делается по DST IP, протокол не имеет значения. Может когда-то и были маршрутизаторы с логикой "это TCP, поэтому пропишем маршрут в ASIC, а это UDP, наверняка единичный пакет DNS запроса, поэтому не будет прописывать аппаратный маршрут". Но я в это не верю. IP телефония уже лет 15 как используется повсеместно и такие маршрутизаторы давно должны были исчезнуть. Кстати, вот и причина, почему UDP могут не нравится сетевикам. IP телефония — это много маленьких пакетов (ключевое слово "много").
Pzz>>>А сейчас провайдеры просто поставят UDP-трафику приоритет пониже, чтобы он их инфраструктуру с ума не сводил, и будут жить дальше, как прежде.
vsb>>А юзеры будут жаловаться, что интернет тормозит и уходить к другим провайдерам.
Pzz>И выяснят, что у других провайдеров все не сильно лучше, поэтому и жаловаться не на что.
Pzz>Еще, я полагаю, провайдеры могут на существующем оборудовании протоптать для UDP быструю дорожку к гугловым серверам и прочему крупняку, а простым людям придется подождать с внедрением QUICа на свооих серверах.
Во-первых, приоритезация имеет смысл только при забитом канале. Если канал может пропустить весь трафик, то нет смысла его переупорядочивать. Все что может сделать приоритезация — переупорядочить пакеты в буфере отправки и отбросить малоприоритетные, которые не влезли. Больших буферов на оборудовании у провайдеров тоже нет, в них нет смысла (принял данные — отдал в другой интерфейс) да и трафик там огромный, памяти столько в маршрутизатор никто не поставит. Буферы есть только на маршрутизаторох типа пользовательской WiFi коробочки в квартире, вот там приоритет чуть-чуть имеет смысл, но если у пользователя начнет булькать IP телефония, он просто остановит или ограничит трафик торрента.
Во-вторых, как раз приоритезация и является довольно ресурсоемкой задачей (более ресурсоемкой, чем роутинг). Потому что нужно просматривать каждый пакет и пытаться переупорядочить очередь на отправку, чтобы отбрасывались менее приоритетные пакеты. И делать это с каждым пакетом, даже когда очередь на отправку пуста. При этом, скорее всего, потребуется чуть больше памяти, чтобы не потерять приоритетные пакеты, когда очередь на отправку забита такими же приоритетными (остальные будут отбрасываться). Так что, IMHO, приоритезация имеет смысл, в мелких железках на стороне пользователя, где есть большие буферы на отправку, потому что она может влиять только на положение пакета в этом буфере отправки, но там эта задача решается вручную.
M>>QUIC — это UDP. Там 99% соединений из NAT пропадает в течение 5 минут. Т.е. Websocket там не выживет.
Pzz>Ну там, наверное, предсмотрено периодически пинги гнать. Чтобы NAT не забывал, да и вообще, чтобы убедиться, что на другом конце соединения никто еще не умер.
Через 30 секунд у тебя 5% NAT'ов забывают UDP сессию, через минуту уже почти 50% (через 5 минут все 100%). Так что пинги придется гнать с клиента каждые 20-25 секунд. Т.е. зашел ты с мобилки на сайт с WebSocket (по сути любой сайт) и у тебя JavaScript в каждой странице каждые 20 секунд должен в сеть отправлять пакет и читать, что вернулось, причем даже если страница в фоне (JS в фоне, вроде не работает или работает как-то с ограничениями). Иначе сервер не сможет тебе отправить обновление, уведомление ибо NAT забыл сессию и WebSocket закрылся (только JS не знает об этом).
M>>IMHO, останется со временем из HTTP только 1.1. и 3.0 и они будут дополнять друг друга. 1.1 для websocket и legacy, 3.0 для остального. HTTP/2.0 при наличии 3.0 не особо нужен, поэтому исчезнет.
Pzz>А что, в HTTP/3 не предусмотрели аналога вебсокета?
Веб сокет там есть, как и в любом HTTP, но как предотвратить закрытие UDP сессии на NAT клиента (клиент — мобилка). Потому IPv6 рулит, однозначно. Там решена одна из самых неприятных проблем провайдеров — NAT (его там нет).
