LINUX.ORG.RU

Покритикуйте HTTP/2 (сам протокол)

 


0

2

Сабж. Ну или ссылок накидайте. Хочется услышать что-то типа «п.1, п.2, п.3 – так что сами видите, эту херь дизайнила школота ЕГЭшная». Гугл чёт ничего подходящего не даёт, а сам я по ощущениям недостаточно в теме (мало протоколов изучал и делал).

Хотя одна вещь, помнится, изумила своим феерическим идиотизмом: имена заголовков стали бинарные, а значения стандартных числовых и date-заголовков (Content-Length, Last-Modified, etc.) – по-прежнему передаются текстом. Если тут я не прав, ссылку на спеку и пункт спеки, плиз.

Кидаю сюда а не в Web-Development, т.к. там всякие PHP и CSS, а нужно мнение матёрых системных программистов.

★★★★★

Ответ на: комментарий от Harald

Ну несколько дней назад я гуглил, к 50% подбирается. Неизвестно, чего стоит эта статистика, но крупняк (ютуб, фейсбук, яху и прочие) его юзает.

dimgel ★★★★★
() автор топика

значения стандартных числовых и date-заголовков (Content-Length, Last-Modified, etc.) – по-прежнему передаются текстом

А то что html передаётся текстом тебя не смущает?

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Смущает. :) Но здесь вопрос не про HTML.

HTML для HTTP это просто непрозрачный payload – такой же непрозрачный, как image/jpeg или там application/file-encrypted-by-vasya-pupkin.

dimgel ★★★★★
() автор топика
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от boowai

Если сравнивать не с http/1.1, то смотри http/3, там упомянут.

Ссылку можно прямую? Насколько я слышал краем глаза, там фичи ортогональные HTTP/2, а именно UDP. Изучать этот HTTP/3 меня не тянет совершенно, и не только потому что он ещё слишком юн. Гугл с помощью нового транспорта хочет сделать трафик непрозрачным для проксей, дескать можно будет добавлять в протокол фишки и не ждать пока все прокси их реализуют. Только вот UDP-оверхед они не преодолеют в принципе; и великолепно проработанный механизм кеширования, благодаря которому – по мнению некоторых REST-гуру – HTTP собственно и рулит, пойдёт лесом (хотя он и так уже там из-за HTTPS).

dimgel ★★★★★
() автор топика
Ответ на: комментарий от boowai

Кроме того, нужна сторонняя критика, а HTTP/3 подозреваю пилят те же хрены что и HTTP/2.

dimgel ★★★★★
() автор топика

Де факто Webpack используется много где, потому HTTP/2, как стандартизация этой хрени, выглядит очень даже неплохо. Претензии у меня совершенно к другому: HTTP в принципе давным давно не нужен для того, чем становится веб — SaaS помойкой, сервисам на базе виртуальной машины браузера.

Я сейчас для интереса пожал проект, над которым я сейчас работаю, при помощи LZMA2, Deflate, и LZ4, получилось 15, 25, и 35 Мб соответственно. Исходный размер — 75 Мб, половина скриптов. Зачем вообще в 2020 году это передавать по каким-то частям? Комп с хилым инетом не потянет этот SaaS в любых раскладах, а достаточно современный девайс с хорошим подключением только скажет спасибо, если сайт будет грузиться раз и целиком.

Хочется услышать что-то типа «п.1, п.2, п.3 – так что сами видите, эту херь дизайнила школота ЕГЭшная». Гугл чёт ничего подходящего не даёт, а сам я по ощущениям недостаточно в теме (мало протоколов изучал и делал)

Иронично написал. HTTP/2 — это SPDY, который сам гугл и создавал.

имена заголовков стали бинарные, а значения стандартных числовых и date-заголовков (Content-Length, Last-Modified, etc.) – по-прежнему передаются текстом

Совместимость с совместимостью. Это особенность западной экономики — говно гниет десятилетиями, потому что пофигизм и безинициативность поощряется сверху, основной твоей работой должна быть грязня за подачки из кормушки, а единственная инициатива, которую тебе полагаться проявлять — это на упреждение лизнуть попу крупному бизнесу a.k.a. государство a.k.a. глобальный бизнес. Не то, чтобы я винил какую-то там систему в каких-то там всех грехах — любое государство должно неизбежно использовать механизм «разделяй и властвуй», чтобы управлять народной массой.

Объективно гугл мог бы ввести новый стандарт, который поднял бы веб на качественно новый уровень. Но зачем? Глобальному бизнесу нужно больше власти, а каким образом развитие веба в этом направлении ведет к укреплению власти? У гугла и его покровителей уже и так есть всё, что нужно, они бы с радостью заморозили технологии на 50 лет. Но есть причины новые технологии вводить, и делать это желательно с минимальными издержками. Я здесь подчеркиваю, что второй частью не является «и с максимальной прибылью», потому что на этом уровне никто не считает прибыли, а просто по необходимости включают печатный станок. Но для минимизации использования печатного станка минимизируются издержки.

byko3y ★★★★
()
Ответ на: комментарий от Harald

а насколько широко он сейчас внедрён, есть какая-то статистика?

Очень широко, потому что менять сайты/сервисы под HTTP/2 не нужно или почти не нужно.

byko3y ★★★★
()
Ответ на: комментарий от no-such-file

А то что html передаётся текстом тебя не смущает?

Меня вот смущает, что передается HTML. И CSS.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Зачем вообще в 2020 году это передавать по каким-то частям? Комп с хилым инетом не потянет этот SaaS в любых раскладах, а достаточно современный девайс с хорошим подключением только скажет спасибо, если сайт будет грузиться раз и целиком.

Согласен. Но решения для «грузануть раз и целиком» тоже есть и не одно: (1) пишешь клиента и юзаешь собственный протокол (плохо, конечно, т.к. у десктопа и мобил клиенты разные); (2) в WebAssembly что-то на эту тему рожали ЕМНИП, и вроде бы даже было специфическое браузерное API для кеширования (и не одно).

Иронично написал. HTTP/2 — это SPDY, который сам гугл и создавал.

Я в курсе. :)

dimgel ★★★★★
() автор топика
Ответ на: комментарий от byko3y

Зачем вообще в 2020 году это передавать по каким-то частям?

Хотя… Если портал огроменный, то хрен ты его целиком в телефон загонишь. Или, мой любимый пример (почему-то я сразу его не вспомнил) – админку не надо всем грузить.

Впрочем, оба эти кейса решаются крупно-гранулированной модуляризацией.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от dimgel

(1) пишешь клиента и юзаешь собственный протокол (плохо, конечно, т.к. у десктопа и мобил клиенты разные); (2) в WebAssembly что-то на эту тему рожали ЕМНИП, и вроде бы даже было специфическое браузерное API для кеширования (и не одно)

Вот потому второе и происходит из-за первого. Но никто не спешит этот процесс подгонять, потому что политической системе конкретно этот прогресс не нужен.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

Ты забыл ещё ссылку на HPACK (7541). Даже пёрнуть в лужу – и то нормально не можешь.

dimgel ★★★★★
() автор топика

Абсолютные цветочки в сравнении с HTTP/3, на его фоне это все будет мелкими придирками.

t184256 ★★★★★
()
Ответ на: комментарий от dimgel

Согласен. Но решения для «грузануть раз и целиком» тоже есть и не одно: (1) пишешь клиента и юзаешь собственный протокол (плохо, конечно, т.к. у десктопа и мобил клиенты разные); (2) в WebAssembly что-то на эту тему рожали ЕМНИП, и вроде бы даже было специфическое браузерное API для кеширования (и не одно).

(3) можно запихать все в json, оставив на JS только шаблонизатор и хранить в local storage после первой загрузки

SR_team ★★★★★
()

очень сложный, но вообще уже всё, http3/quic/udp. Т.е. пока будешь рассусоливать, нужен ли он, уже всё поменяют.

Правда вот есть непонятная история: гугл заявляет, что 60% трафика отдаются уже по http2. Фейсбук заявляет, что по http3 отдается 55% трафика.

Так что инфа 146%

max_lapshin ★★★★★
()
Ответ на: комментарий от dimgel

Знаешь TLS? Такой протокол, которому сто лет в обед и все равно в реализациях находят дырки, от которых в слезы бросает? В HTTP/3 вместо него будет новый, свеженький велосипед с новыми, свеженький и реализациями. Не прям совсем вместо, типа TLS убрали, а новый транспортный уровень вкатили, а такой тесно переплетенный с прикладным слоем подарок злоумышленникам, индустрии в целом и пользователям, конечно.

Все образумится, конечно, со временем, но поначалу будет весело.

t184256 ★★★★★
()
Ответ на: комментарий от max_lapshin

очень сложный, но вообще уже всё, http3/quic/udp. Т.е. пока будешь рассусоливать, нужен ли он, уже всё поменяют.

Что поменяют? http/3 еще из драфта не вышел. После драфта нужно будет разрулить дырки для UDP, т.к. в корпоративных сетях в большинстве случаев UDP режут. Сейчас даже речь о том, чтобы H3 работал независимо не идет, в ближайшие годы будет Alt-Svc. У Firefox H2 запилен костылями, у них если послать Content-Length равный X, а затем передать контент размера X без завершения стрима, а сам стрим завершить отдельным пустым чанком, то FF заресетит все соединение. За дебаг H3 я еще не брался, пока вот готовлюсь сделать мониторинг того сколько пользователей включило его. У Chrome H2 реализован сильно лучше, я пока косяков не находил. У остальных до сих пор SPDY в лучшем случае, а старые IE даже приоритеты не поддерживают.

FB отдеает трафик по H3 через iOS/Android приложения, а не через браузеры. Они пилили movefast для тесной интеграцией с kantran’ом и прочим. Предыдущие полгода копал где можно ускорить TLS(там тоже все грустно в плане поддержки браузерами), поэтому сейчас надо будет списаться с чуваками и узнать что там с патчами для Linux, т.к. в 4.19 ветке UDP жрал CPU сильно большем, чем TCP.

xpahos ★★★★★
()

Хотя одна вещь, помнится, изумила своим феерическим идиотизмом: имена заголовков стали бинарные, а значения стандартных числовых и date-заголовков (Content-Length, Last-Modified, etc.) – по-прежнему передаются текстом. Если тут я не прав, ссылку на спеку и пункт спеки, плиз.

https://tools.ietf.org/html/rfc7541#section-2.3.1

Есть статическая таблица для часто используемых заголовков, есть динамическая таблица для кастомных заголовков. Если ты не используешь всякие NEL и кучу прочего, а шлешь вполне себе стандартные заголовки, то динамическая таблица никогда не будет использоваться. Придется пересылать меньшей байтов.

xpahos ★★★★★
()
Ответ на: комментарий от t184256

В HTTP/3 вместо него будет новый, свеженький велосипед с новыми, свеженький и реализациями.

Что? Там обычный TLSv1.3

xpahos ★★★★★
()

Главный недостаток - это пожалуй замедление скачивания файлов из-за оверхеда на проткол мультиплексирования.

annulen ★★★★★
()
Ответ на: комментарий от annulen

Главный недостаток - это пожалуй замедление скачивания файлов из-за оверхеда на проткол мультиплексирования.

o.0? Какое замедление скачивания файлов? У тебя нет хендшейка на каждое соединение, окно уже оптимальное. Включи себе BBR и радуйся.

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

Разработчики nginx объясняли, что закачка с http/2 всегда медленнее, чем с http, но искать источник мне лень. ЕМНИП это связано с оверхедом от разбивки данных на фреймы.

У тебя нет хендшейка

Без https вообще никакого хэндшейка нет, и задержки от блочного шифра.

annulen ★★★★★
()

главная задача http2 - параллельные потоки. но это и так есть в ssh , который можно пробросить через websocket

в общем и целом, параллельные потоки - не так уж и сильно нужны, не так уж сильно (если вообще) превосходят по производительности, и в целом - сильно усложняют протокол. пока http1 - просто работает.

anonymous
()
Ответ на: комментарий от annulen

тоже самое я видел где-то у разрабов fasthttp. тоже всё свелось к производительности.

anonymous
()
Ответ на: комментарий от annulen

Без https вообще никакого хэндшейка нет, и задержки от блочного шифра.

Есть еще TCP хендшейк. Но тут нужно понимать, что это не самая главная проблема. При использовании двух сокетов ты фактически имеешь то же самое мультиплексирование, т.к. шнурок один и тот же.

Разработчики nginx объясняли, что закачка с http/2 всегда медленнее, чем с http, но искать источник мне лень. ЕМНИП это связано с оверхедом от разбивки данных на фреймы.

Это чуваки из CloudFlare объясняли почему в nginx криво работают буферы. К самому H2 это отношения не имело.

http://mailman.nginx.org/pipermail/nginx-devel/2020-August/013436.html

xpahos ★★★★★
()
Ответ на: комментарий от anonymous

если он есть на лоре

если он не забанен на лоре - очевидный фикс

anonymous
()
Ответ на: комментарий от anonymous

кратко: юзекейсы - весьма расплывчаты и неоднозначны.

Лол, там написано, что наш fasthttp не используют как терминирующую точку, а ставят где-нибудь за nginx, например, в cloudflare. Давайте типа подумаем нужен ли нам вообще H2, т.к. реверс прокси с H2 не работает в nginx. А потом еще видимо говна сожрали и решили сначала реализовать H3, хотя судя по коментариям выше, у них проблема в том, что код не очень гибкий.

Вообще внедрение H2 у нас было достаточно болезненным. Товарищ практически один затащил всю реализацию H2, это все затянулось и чуть не сорвалось из-за косяков в FF. Пришлось даже в wireshark покантрибутить.

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

что ещё раз доказывает не очень-то очевидную выгоду от http2.. в плане реализации API - проще json-rpc 2.0 вообще взять, и не тратить время на http2

anonymous
()
Ответ на: комментарий от anonymous

что ещё раз доказывает не очень-то очевидную выгоду от http2.. в плане реализации API - проще json-rpc 2.0 вообще взять, и не тратить время на http2

Ты херню сморозил. H2 нужен для взаимодействия с браузером, json-rpc для взаимодействия с JS внутри VM, которая находится уже в браузере. Любой RPC запрос будет работать поверх HTTP. Это ортогональные вещи как бы. Если говорить о реверс прокси, то внутри ДЦ требования к HTTP иные. Там хоть HTTP/1.1 гоняй, хоть HTTP/2, т.к. скорее всего будут толстые каналы без потерь и с джамбо фреймами. Для мобилок же бинарный протокол позволяет снизить лейтенси, а мультиплексирование с BBR позволяет быстрее грузить ресурсы. Без BBR 8 соединений(может быть 6, не помню сколько точно браузеры устанавилвают) HTTP/1.x будут быстрее, т.к. конженш эвойденс в нескольких соединения будет позволять быстрее нарастить окно, чем одно окно мультиплексированного соединения. Как раз проблемы с потерей пакетов и решают в H3. Вообще перекладывание конженшн контрола из TCP в UDP довольно древняя историю. Думаю у всех более или менее крупных компаний есть в загашничке свой подобный протокол.

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

http2 - это, прежде всего, параллелизм и приоритеты.

http и json-rpc 2 - это оба - протоколы уровня приложения. последний даже в связке с http использовать не нужно, если речь не о браузерах. по-этому, эти протоколы ни как не влияют на работу более низких уровней.

на более низком уровне у нас tcp, udp и другие.

манипуляциями на одном только уровне приложений, параллелизм по одному физическому каналу возможен только фрагментацией на уровне архитектуры протокола приложения. такая фрагментация есть в ssh и в json-rpc 2. теперь ещё и в http2/3, потому что гуглу опять захотелось выпендриться.

если говорить о транспортном уровне - тут уже свои методики. но весьма сомнительно, что будет отказ от tcp ради сомнительных выгод хоть в http3 хоть 4, хоть 5 etc..

anonymous
()
Ответ на: комментарий от anonymous

Любой RPC запрос будет работать поверх HTTP. Это ортогональные вещи как бы.

«знатоку» http2, следовало бы подучить протокол http, дабы уяснить себе, что в json-rpc 2, http служит только для начального коннекта и всё, а дальше приложения как хотят, так и спариваются - чего и требовалось - http2 - ненужен..

anonymous
()
Ответ на: комментарий от xpahos

Есть статическая таблица для часто используемых заголовков, есть динамическая таблица для кастомных заголовков.

Это я читал и помню. Но ЕМНИП там речь исключительно про имена заголовков (захардкоженные коды), а не про значения.

UPD. Может были и стандартные пары «имя-значение», типа «ContentType: text/html», лень искать таблицу; но Content-Length и Last-Modified стандартных значений иметь не могут.

dimgel ★★★★★
() автор топика
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от xpahos

Вообще внедрение H2 у нас было достаточно болезненным. […] чуть не сорвалось из-за косяков в FF.

Ясно-понятно… Значит, даже H2 ещё рано юзать, не то что H3…

dimgel ★★★★★
() автор топика
Ответ на: комментарий от anonymous

в общем и целом, параллельные потоки - не так уж и сильно нужны, не так уж сильно (если вообще) превосходят по производительности, и в целом - сильно усложняют протокол. пока http1 - просто работает

Если у тебя сервер на расстоянии меньше 20 мс, каналом шириной в LAN, и ничтожным временем ответа на запросы статики — да. В противном случае HTTP/2 позволяет достигать значительного сокращения времени загрузки страницы.

byko3y ★★★★
()
Ответ на: комментарий от xpahos

Вообще перекладывание конженшн контрола из TCP в UDP довольно древняя историю

Да просто TCP — это ублюдочный протокол, который проектировали в расчете на сферических коней в вакууме. А выяснилось, что TCP проблему потери пакетов решает отвратительно. Причем, как на уровне самого протокола, так и по реализациям в тех же никсах — в POSIX нет способов определения перегрузки канала/потери соединения до того, как всё шваркнется полностью и окончательно..

byko3y ★★★★
()
Ответ на: комментарий от anonymous

http2 - это, прежде всего, параллелизм и приоритеты.

Ты путаешь термины, в H2 конкурентность, если говорить о русских терминах.

http и json-rpc 2 - это оба - протоколы уровня приложения. последний даже в связке с http использовать не нужно, если речь не о браузерах. по-этому, эти протоколы ни как не влияют на работу более низких уровней.

Если речь идет не о обраузерах, то есть бинарный grpc, который куда лучше справляется с той же компрессией.

манипуляциями на одном только уровне приложений, параллелизм по одному физическому каналу возможен только фрагментацией на уровне архитектуры протокола приложения. такая фрагментация есть в ssh и в json-rpc 2. теперь ещё и в http2/3, потому что гуглу опять захотелось выпендриться.

Опять же, ты путаешь параллелизм и конкуренцию. Фрагментация это несколько другое. Гугл не выпендривался, они все правильно сделали, протокол бинарный поэтому контрол флоу они вынесли в сам протокол.

если говорить о транспортном уровне - тут уже свои методики. но весьма сомнительно, что будет отказ от tcp ради сомнительных выгод хоть в http3 хоть 4, хоть 5 etc..

Как видишь, уже отказались.

xpahos ★★★★★
()
Ответ на: комментарий от dimgel

Это я читал и помню. Но ЕМНИП там речь исключительно про имена заголовков (захардкоженные коды), а не про значения.

Ну достаточно странно иметь таблицу для таких полей. Она будет достаточно большой и не иметь особого смысла. Да, речь только об именах самих полей.

xpahos ★★★★★
()
Ответ на: комментарий от dimgel

Ясно-понятно… Значит, даже H2 ещё рано юзать, не то что H3…

Это было давно уже. Баг правда до сих пор не пофиксили, но как бы с этим можно жить. Проблема была в том, что пользователей у FF много, а запустить реализацию которая будет ломать их «опыт» нельзя. Поэтому-то и пришлось искать эту проблему. H3 еще из драфта не вышел.

xpahos ★★★★★
()
Ответ на: комментарий от byko3y

Да просто TCP — это ублюдочный протокол, который проектировали в расчете на сферических коней в вакууме. А выяснилось, что TCP проблему потери пакетов решает отвратительно. Причем, как на уровне самого протокола, так и по реализациям в тех же никсах

Нормально он решает. Не надо просто хотеть невозможного.

— в POSIX нет способов определения перегрузки канала/потери соединения до того, как всё шваркнется полностью и окончательно..

есть eBPF, если действительно нужно что-то отслеживать в TCP.

xpahos ★★★★★
()
Ответ на: комментарий от t184256
This document describes how QUIC [QUIC-TRANSPORT] is secured using TLS [TLS13].
...
This document describes how TLS acts as a security component of QUIC.

Что почитать?

xpahos ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.