Здравствуйте, Quadri, Вы писали:
Q>я тут провожу некоторое изыскание по реализациям протоколов поверх tcp сокетов (не webscoket) с постоянной связью. Q>мне доводилось реализовывать подобную связь однажды: Q>- связь: постоянная Q>- протокол типа запрос-ответ (запрос инициируется клиентом) Q>- текстовый (xml) Q>- обоснование использования именно tcp сокетов(а не HTTP, например): так было проще на тот момент реализовать на стороне сервера
Q>1. могли бы вы поделиться своим опытом, с кратким описанием типа как я привел выше?
Очень много неизвестных пока в этом описании. Цель протокола под NDA, или что-то таки можете описать?
Какого рода взаимодействие? Есть ли в нём долгоживущие сущности двух сторон?
Похоже ли это на RPC?
Может ли сервер проявлять инициативу в конкретных действиях, а не просто отвечать клиенту?
Q>2. как часто и с какой целью делается не "запрос-ответ", а когда сервер тоже может писать внезапно в клиентский сокет? плюсы/минусы такого подхода?
Сколько угодно.
IMAP: сервер присылает оповещения типа "в ящике появилось новое письмо", "соседний клиент удалил 20 писем и поменял флаги на остальных".
SIP, IAX и прочая телефония: ремота решила послать факс, включить шифрование, положить трубку и т.п.
До чёрта разных веб-сервисов: появилось что угодно новое. Чат — новое сообщение. Мониторилка — обновились статусы объектов. Обычно их стараются, да, загонять на websocket, но есть и альтернативы.
Мессенджеры: и снова — новое сообщение.
Минус по сути только один: не ложится в схему "запрос-ответ" и пассивного сервера. Поэтому надо уметь в асинхронность.
Q>3. какие есть общепринятые протоколы подобной схемы, которые можно реализовать самостоятельно. На ум приходит HTTP, но хотелось бы что-то еще и попроще, к тому же он не всегда keep-alive
Ну тот же IMAP для начала. Всю почтовую специфику можно выкинуть из рассмотрения, смотрите на тегирование сообщений в обе стороны.
Здравствуйте, Quadri, Вы писали:
Q>- обоснование использования именно tcp сокетов(а не HTTP, например): так было проще на тот момент реализовать на стороне сервера
Я бы взял HTTP, и JSON вместо XML.
Q>2. как часто и с какой целью делается не "запрос-ответ", а когда сервер тоже может писать внезапно в клиентский сокет? плюсы/минусы такого подхода?
Когда на сервере может что-то произойти само по себе, а не в ответ на клиентский запрос, и клиенту про это стоило бы знать.
Q>3. какие есть общепринятые протоколы подобной схемы, которые можно реализовать самостоятельно. На ум приходит HTTP, но хотелось бы что-то еще и попроще, к тому же он не всегда keep-alive
HTTP самый удобный, потому что вся сетевая инфраструктура под него уже заточена. Например, под HTTP вряд ли придется ковырять дырку в фаирволе.
Keep-alive он или нет, это вопрос оптимизации, а не семантики. Хотя мне вот попался киосеровский МФУ, которому оказалось не все равно, с кипалайвом к нему приходят, или без. Но это уж его бага, а не фича.
Здравствуйте, vsb, Вы писали:
vsb>Кстати, а о каких именно проблемах речь?
Ну не рассчитаны все эти дивные сетевые коробочки, из которых свинчен интернет, на то, что по ним пойдет UDP тугим потоком. Пакеты TCP естесвенным образом образуют поток, и все, довольно дорогие, роутинговые решения можно принять один раз, а потом отправлять каждый следующий пакет уже по накатанным рельсам, а в случае UDP каждый пакет роутится отдельно.
Все это, конечно, починят со временем. Но вряд ли крупные провайдеры побегут в магазин за новыми кисками просто потому, что гуглю так приспичило. И киска тоже вряд ли починит эти проблемы тривиальным апгрейдом прошивки, скорее они новые коробочки понавыпускают. А сейчас провайдеры просто поставят UDP-трафику приоритет пониже, чтобы он их инфраструктуру с ума не сводил, и будут жить дальше, как прежде.
Pzz>>Во-вторых, у QUIC'а, насколько я в курсе, не очень хорошо с практическими реализациями.
Pzz>>Семантически QUIC более-менее эквиавалентен HTTP/2.
vsb>QUIC даёт шифрование, мультиплексирование и автоматическую миграцию при смене адреса. По-моему все три фичи жизненно необходимы в любом сетевом софте.
По сравнению с HTTP/2, QUIC дает, в некоторых случаях, более быстрый старт соединения (TLS+TCP требует сначала пары round-trip'ов, чтобы договориться о TCP, а потом примерно столько же, чтобы договориться о шифровании, а QUIC позволяет это совместить, и плюс потом еще round-trip, чтобы договориться о переходе от HTTP/1.1 до HTTP/2). Шифрование и мультиплексирование есть в HTTP/2.
Что для автоматической миграции, я плохо знаю, как она устроена в QUIC, и рассуждать о ней не могу.
У QUIC и HTTP/2 примерно одинаковая семантика, но QUIC в некоторых случаях работает быстрее. Это вопрос эффективности, а не новых возможностей.
Здравствуйте, vsb, Вы писали:
vsb>Сейчас надо использовать QUIC. TCP уже устарел.
Я бы поспорил. Во-первых, есть такое мнение, что сетевая инфраструктура просто не готова к тому, что весь трафик из TCP вдруг превратится в UDP. Во-вторых, у QUIC'а, насколько я в курсе, не очень хорошо с практическими реализациями.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, netch80, Вы писали:
N>> смотрите на тегирование сообщений в обе стороны.
S>А можно где почитать или в кратце рассказать о чем речь?
Похоже речь об этом:
The client command begins an operation. Each client command is
prefixed with an identifier (typically a short alphanumeric string,
e.g., A0001, A0002, etc.) called a "tag". A different tag is
generated by the client for each command.
Example: C: A003 CREATE owatagusiam/
S: A003 OK CREATE completed
C: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed
Здравствуйте, reversecode, Вы писали:
R>вас на гитхабе забанили ?
Гитхаб сейчас не сильно отличается от всего интернета — "искать в нём это как пить из включенного пожарного брандспойта" (c).
Так что без указаний на конкретные названия это, мягко говоря, не ответ.
Здравствуйте, 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 разгоняются примерно одинаково.
Pzz>Роутинговые решения довольно дорогие, и их надо кешировать. Для TCP это сделано в контексте TCP-соединения. Для UDP на старом оборудовании это не сделано. А менять старое оборудование на новое только потому, что гуглю это приспичило, провайдерам дороговато.
Во-первых, маршрутизация делается по DST IP, протокол не имеет значения. Может когда-то и были маршрутизаторы с логикой "это TCP, поэтому пропишем маршрут в ASIC, а это UDP, наверняка единичный пакет DNS запроса, поэтому не будет прописывать аппаратный маршрут". Но я в это не верю. IP телефония уже лет 15 как используется повсеместно и такие маршрутизаторы давно должны были исчезнуть. Кстати, вот и причина, почему UDP могут не нравится сетевикам. IP телефония — это много маленьких пакетов (ключевое слово "много").
Pzz>>>А сейчас провайдеры просто поставят UDP-трафику приоритет пониже, чтобы он их инфраструктуру с ума не сводил, и будут жить дальше, как прежде.
vsb>>А юзеры будут жаловаться, что интернет тормозит и уходить к другим провайдерам.
Pzz>И выяснят, что у других провайдеров все не сильно лучше, поэтому и жаловаться не на что.
Pzz>Еще, я полагаю, провайдеры могут на существующем оборудовании протоптать для UDP быструю дорожку к гугловым серверам и прочему крупняку, а простым людям придется подождать с внедрением QUICа на свооих серверах.
Во-первых, приоритезация имеет смысл только при забитом канале. Если канал может пропустить весь трафик, то нет смысла его переупорядочивать. Все что может сделать приоритезация — переупорядочить пакеты в буфере отправки и отбросить малоприоритетные, которые не влезли. Больших буферов на оборудовании у провайдеров тоже нет, в них нет смысла (принял данные — отдал в другой интерфейс) да и трафик там огромный, памяти столько в маршрутизатор никто не поставит. Буферы есть только на маршрутизаторох типа пользовательской WiFi коробочки в квартире, вот там приоритет чуть-чуть имеет смысл, но если у пользователя начнет булькать IP телефония, он просто остановит или ограничит трафик торрента.
Во-вторых, как раз приоритезация и является довольно ресурсоемкой задачей (более ресурсоемкой, чем роутинг). Потому что нужно просматривать каждый пакет и пытаться переупорядочить очередь на отправку, чтобы отбрасывались менее приоритетные пакеты. И делать это с каждым пакетом, даже когда очередь на отправку пуста. При этом, скорее всего, потребуется чуть больше памяти, чтобы не потерять приоритетные пакеты, когда очередь на отправку забита такими же приоритетными (остальные будут отбрасываться). Так что, IMHO, приоритезация имеет смысл, в мелких железках на стороне пользователя, где есть большие буферы на отправку, потому что она может влиять только на положение пакета в этом буфере отправки, но там эта задача решается вручную.
я тут провожу некоторое изыскание по реализациям протоколов поверх tcp сокетов (не webscoket) с постоянной связью.
мне доводилось реализовывать подобную связь однажды:
— связь: постоянная
— протокол типа запрос-ответ (запрос инициируется клиентом)
— текстовый (xml)
— обоснование использования именно tcp сокетов(а не HTTP, например): так было проще на тот момент реализовать на стороне сервера
1. могли бы вы поделиться своим опытом, с кратким описанием типа как я привел выше?
2. как часто и с какой целью делается не "запрос-ответ", а когда сервер тоже может писать внезапно в клиентский сокет? плюсы/минусы такого подхода?
3. какие есть общепринятые протоколы подобной схемы, которые можно реализовать самостоятельно. На ум приходит HTTP, но хотелось бы что-то еще и попроще, к тому же он не всегда keep-alive
Здравствуйте, Quadri, Вы писали:
Q>- связь: постоянная
Пофиг. Важно наличие NAT и путей его обхода, важно качество сети и производительность клиента. Q>- протокол типа запрос-ответ (запрос инициируется клиентом)
Это везде так. Q>- текстовый (xml)
Лучше json, xml слишком ибыточный в 95% случаев. Q>- обоснование использования именно tcp сокетов(а не HTTP, например): так было проще на тот момент реализовать на стороне сервера
С т.з. сети это одно и тоже. ХТТП даёт только доп. уровень абстракции с плюшками в виде HTTPS.
Q>1. могли бы вы поделиться своим опытом, с кратким описанием типа как я привел выше?
Это мало что даёт для нормального ответа тебе. Q>2. как часто и с какой целью делается не "запрос-ответ", а когда сервер тоже может писать внезапно в клиентский сокет?
Когда на сервере меняются шареные данные в общем смысле и их надо показывать всем клиентам в режиме online. Q>3. какие есть общепринятые протоколы подобной схемы, которые можно реализовать самостоятельно.
ТСП и протокол поверх него, например, на базе protobuf.
В общем, почему сейчас все юзают HTTP и вёбсокеты, причина проста — одна дырка под 80/8080 порт всегда открыта на фаерволе, не надо обходить НАТ в общем случае, есть куча способов аутентификации/шифрования из коробки которая есть любом HTTP сдк, и ещё, поддержка http есть в любых фреймворках, любых языках и платформах вроде уродства Node.js.
Q>>1. могли бы вы поделиться своим опытом, с кратким описанием типа как я привел выше? K>Это мало что даёт для нормального ответа тебе.
Спасибо.
Все это (json лучше, что такое HTTP и почему используется и прочее прочее) я и так прекрасно знаю.
Мне нужны примеры конкретных случаев, для примера я описал свой опыт.
Если мне нужно будет больше, я создам другую тему или задам уточняющие вопросы, но сейчас мне нужно именно то что я спросил в исходном посте.
Здравствуйте, Quadri, Вы писали:
Q>Мне нужны примеры конкретных случаев, для примера я описал свой опыт.
Я писал всё, в разных видах и под разным соусом под клиент-сервер. Единственное что я вынес из этого — любое написание нового это повторение старого, но с новыми граблями. Единсвтенное что я не делал, это децентрализованные P2P системы. Вот там HTTP особого смысла не имеет.
Здравствуйте, Kernan, Вы писали:
K>Я писал всё, в разных видах и под разным соусом под клиент-сервер.
отлично, так поделитесь соответствующим примером!
K>Единственное что я вынес из этого — любое написание нового это повторение старого, но с новыми граблями.
Абсолютно согласен, но у меня интерес академический.
K>Единсвтенное что я не делал, это децентрализованные P2P системы. Вот там HTTP особого смысла не имеет.
+
Здравствуйте, Kernan, Вы писали:
Q>>- связь: постоянная K>Пофиг. Важно наличие NAT и путей его обхода, важно качество сети и производительность клиента.
Не пофиг. Где-то есть сущности, персистентные между соединениями, где-то нет.
Q>>- протокол типа запрос-ответ (запрос инициируется клиентом) K>Это везде так.
Нет, не везде. Есть симметричные (SIP), есть с асинхронными оповещениями от сервера (IMAP4).
K>В общем, почему сейчас все юзают HTTP и вёбсокеты, причина проста — одна дырка под 80/8080 порт всегда открыта на фаерволе, не надо обходить НАТ в общем случае, есть куча способов аутентификации/шифрования из коробки которая есть любом HTTP сдк, и ещё, поддержка http есть в любых фреймворках, любых языках и платформах вроде уродства Node.js.
Здравствуйте, Kernan, Вы писали:
K>В общем, почему сейчас все юзают HTTP и вёбсокеты, причина проста — одна дырка под 80/8080 порт всегда открыта на фаерволе, не надо обходить НАТ в общем случае, есть куча способов аутентификации/шифрования из коробки которая есть любом HTTP сдк, и ещё, поддержка http есть в любых фреймворках, любых языках и платформах вроде уродства Node.js.
И еще куча всякого готового. Прокси, балансировщики и тд и тп.
это называется сделайте ресерч за меня
ТС можно сказать с нулевыми знаниями в сетевом кодинге набросил и ждет..
я больше чем уверен что дальше этого топика он не уйдет
те кому надо делают молча ресерчи и создают решения
Здравствуйте, netch80, Вы писали:
N>Очень много неизвестных пока в этом описании. Цель протокола под NDA, или что-то таки можете описать? N>Какого рода взаимодействие? Есть ли в нём долгоживущие сущности двух сторон? N>Похоже ли это на RPC? N>Может ли сервер проявлять инициативу в конкретных действиях, а не просто отвечать клиенту?
Никакого конкретного протокола нет и не планируется. Вопрос задан с целью расширить кругозор и посмотреть "а как оно бывает/принято в жизни"
N>Сколько угодно. N>IMAP: сервер присылает оповещения типа "в ящике появилось новое письмо", "соседний клиент удалил 20 писем и поменял флаги на остальных". N>SIP, IAX и прочая телефония: ремота решила послать факс, включить шифрование, положить трубку и т.п. N>До чёрта разных веб-сервисов: появилось что угодно новое. Чат — новое сообщение. Мониторилка — обновились статусы объектов. Обычно их стараются, да, загонять на websocket, но есть и альтернативы. N>Мессенджеры: и снова — новое сообщение.
N>Минус по сути только один: не ложится в схему "запрос-ответ" и пассивного сервера. Поэтому надо уметь в асинхронность.
+
N>Ну тот же IMAP для начала. Всю почтовую специфику можно выкинуть из рассмотрения, смотрите на тегирование сообщений в обе стороны.
Здравствуйте, Pzz, Вы писали:
vsb>>Сейчас надо использовать QUIC. TCP уже устарел.
Pzz>Я бы поспорил. Во-первых, есть такое мнение, что сетевая инфраструктура просто не готова к тому, что весь трафик из TCP вдруг превратится в UDP.
Но это проблемы сетевой инфраструктуры. Причём очень скоро весь интернет начнёт работать через QUIC, поэтому эти проблемы ответственным за инфраструктуру придётся решать так или иначе. Гугловые серверы уже работают, кстати. Гугл это как стихийное бедствие. Можно его не любить, но не считаться с ним нельзя.
Кстати, а о каких именно проблемах речь?
Pzz>Во-вторых, у QUIC'а, насколько я в курсе, не очень хорошо с практическими реализациями.
Pzz>Семантически QUIC более-менее эквиавалентен HTTP/2.
QUIC даёт шифрование, мультиплексирование и автоматическую миграцию при смене адреса. По-моему все три фичи жизненно необходимы в любом сетевом софте.
Здравствуйте, 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.
Здравствуйте, 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'у подсоединиться.
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 (его там нет).
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 клиента? Насколько я знаю, нет.
Смена ип клиента сама по себе не быстрая операция, странно экономить на спичках спалив тонну дров.
Как много веселых ребят, и все делают велосипед...
M>>Будет ли TCP fast open работать при смене IP клиента? Насколько я знаю, нет. O>Смена ип клиента сама по себе не быстрая операция, странно экономить на спичках спалив тонну дров.
Итого, TCP Fast Open в большинстве случаев (смена IP мобильным клиентом) вообще не работает. А кроме того, оказывается, это экономия на спичках (и в реальности на большинстве клиентов вообще выключен). Так нафига про него вспоминают при каждом сравнении HTTP/3 и TCP+TLS 1.3?
Смена IP клиента происходит при переходе с WiFi на GSM (когда ты вышел из метро или офиса) и от нее никак не избавиться. Происходит один раз при смене подключения (и, скорее всего, в большинстве случаев в фоне), после этого каждое соединение, которое у тебя было в метро или офисе устанавливается заново (часто интерактивно). В GSM RTT нифига не спички (раза в 2 выше latency по сравнению даже с тормозным WiFi) — минимум пару сотен миллисекунд ожидания к каждому соединению (которое совсем не новое, просто было сделано с другого IP).
В общем, мой посыл, что HTTP/3 (QUIC) сильно лучше для мобильных клиентов, чем TCP Fast Open + TLS 1.3. Там реализована миграция клиента, полноценное мультиплексирование каналов в соединении, больше возможностей управления трафиком (повторная передача, управление насыщением канала), шифрование всего, чтобы провайдеры не лезли в трафик.
M>Итого, TCP Fast Open в большинстве случаев (смена IP мобильным клиентом) вообще не работает. А кроме того, оказывается, это экономия на спичках (и в реальности на большинстве клиентов вообще выключен). Так нафига про него вспоминают при каждом сравнении HTTP/3 и TCP+TLS 1.3? M>Смена IP клиента происходит при переходе с WiFi на GSM (когда ты вышел из метро или офиса)
4 раза в день сайт откроется чуть медленней чем обычно. Проблема высосана из пальца.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Pzz, Вы писали:
Pzz>Ну не рассчитаны все эти дивные сетевые коробочки, из которых свинчен интернет, на то, что по ним пойдет UDP тугим потоком.
Это ты про железки уровня домашнего WiFi?
Pzz>Пакеты TCP естесвенным образом образуют поток, и все, довольно дорогие, роутинговые решения можно принять один раз, а потом отправлять каждый следующий пакет уже по накатанным рельсам, а в случае UDP каждый пакет роутится отдельно.
Это только если необходимо собирать сессию и делать DPI, но и это уже давно решенные задачи для скоростей 10+Gb, уровни вложеннсти протоколов могут быть очень сложными (условно MPLS->IP->TCP->IP->UDP), TCP/UDP на одном уровне никакой погоды не делает. Для обычной маршрутизации ничего этого не надо. Там зачастую и IP нет (MPLS).
Здравствуйте, Pzz, Вы писали:
Pzz>Роутинговые решения довольно дорогие, и их надо кешировать. Для TCP это сделано в контексте TCP-соединения.
"-1" В общем случае TCP на решение о маршруте не влияет никак.
Здравствуйте, ononim, Вы писали:
O>4 раза в день сайт откроется чуть медленней чем обычно. Проблема высосана из пальца.
Ну на самом деле, UDP сильно лучше в плане медиастриминга. Только надо бы, чтобы оно еще и понимало, что передает (задержался пакет из кина дольше разумного времени — можно смело дропать его, и все остальное до ближайшего I-frame. Но при этом надо понимать, где какие пакеты в потоке). И я что-то сомневаюсь, что на данном этапе это сделано.
