LINUX.ORG.RU

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

 


0

2

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

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

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

★★★★★

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

grpc

ещё один оверкомпликейтед «решение» от гугла, с ещё одной сомнительной выгодой.

пока оба http1 и json-rpc2 - простые текстовые протокольчики, которые просто работают, для grpc требуется целый фреймворк с несколькими прицепами функциональности, и всё это может сломаться в любой момент, если вообще есть.

KISS-принцип? - та нахрен он нужен?

anonymous
()

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

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

Дальше почитать. Оно не слоится поверх TLS, оно понадрало оттуда кусков и у имплементоров теперь новое поле для накосячить. Как DTLS, только веселее.

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

пока оба http1 и json-rpc2 - простые текстовые протокольчики, которые просто работают,

Да, они работают на толстых стабильных каналах. А вот в мобильных сетях нужно слать как можно меньший объем, т.к. мобилки не имеют такого как бы непрерывного коннекта. Контроллер как бы накапливает пакеты и потом отправляет в сеть. Если этого не будет и каждый пакет будет отправляться как только был отправлен в сокет, то телефон будет выжирать батарейку моментально. Да и на толстых каналах лишние 100 байт не заметны на фоне 10 гбитного канала, а когда у тебя уже каждый сервис позволяет сократить каждый пакет на 100 байт, то сетка заметно экономится.

для grpc требуется целый фреймворк с несколькими прицепами функциональности, и всё это может сломаться в любой момент, если вообще есть.

Может, но не так часто, чтобы на это обращать внимания. Есть юнит тесты, есть функциональные тесты, есть фазинг.

KISS-принцип? - та нахрен он нужен?

Он применим только в контексте. Ты же не будешь распределенную базу лепить на flock файлов через ssh? Так же и здесь. Задачи меняются, решения делаются максимально простыми для конкретных требований.

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

Дальше почитать. Оно не слоится поверх TLS, оно понадрало оттуда кусков и у имплементоров теперь новое поле для накосячить. Как DTLS, только веселее.

Ну ладно, завтра напишу ребятам из FB, которые сейчас пилят библиотечку, что тут чувак на lor’е говорит что он лучше знает как разрабатывать протоколы.

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

Ты лучше заметь, что TLS 1.3 уже зрелый совсем, а ребята твои че-то еще не допилили мальца свой QUIC. Настолько, что наша команда уже устала ждать.

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

ребята твои че-то еще не допилили мальца свой QUIC

Открой google docs и посмотри по каком протоколу он работает в Chrome.

https://github.com/facebookincubator/mvfst реализация от FB

https://github.com/ngtcp2/nghttp3 вот еще реализация

https://github.com/cloudflare/quiche вот еще реализация на Rust

Настолько, что наша команда уже устала ждать.

Так запилите свою. Делов-то.

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

<три наколеночные реализации от горшка два вершка>

Ой спасибо, а то я о них не знал.

Так запилите свою.

Нам не на двух локалхостах proof-of-concept пощупать и по спинам друг друга похлопать, нам всесторонне оттестировать и клиентам поставлять.

Делов-то.

Ну да, это же так легко, что в каждой нулевой TLS-библиотеке уже по реализации. Там же обычный TLS 1.3 (c).

Слушай, у вас там, наверное, хорошо в 2024, но я тебе пишу из 2020, который начало ковида. В 2020 с QUIC сыряк да голяк.

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

вроде бы обратное проксирование не поддерживалось, не помню точно

Да не, проксирование само по себе ортогонально. Есть конечно ньюансы (первое что гуглится – https://stackoverflow.com/questions/36471077, и ещё раньше видел что у парней были проблемы с балансировкой т.к. с http2 пики трафика по-другому выглядят – https://www.lucidchart.com/techblog/2019/04/10/why-turning-on-http2-was-a-mistake/), но это частности.

Касательно первой ссылки – если и прокси, и бакенд оба поддерживают HTTP2, то перекодировать заголовки проксе придётся и клиенту, и бакенду. А т.к. минимальный размер HPACK-буфера равен 4K (это хардкод; сервер с клиентом могут договориться о бОльшем), то бедному прокси вынь да положь +8K RAM на коннект (а точнее на стрим, т.е. всё ещё хуже). В общем, это вторая претензия к HTTP2 после описанной ТС: память кушает.

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

нам всесторонне оттестировать и клиентам поставлять.

Ну да, ну да. Конечно проще подождать когда за тебя все запилят.

Слушай, у вас там, наверное, хорошо в 2024, но я тебе пишу из 2020, который начало ковида. В 2020 с QUIC сыряк да голяк.

А как ковид повлиял на ойти? У нас как был роадмап на полгода, так и остался. Вот прописали еще на полгода.

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

Ну да, ну да. Конечно проще подождать когда за тебя все запилят.

Такие дела, в энтерпрайзе так вообще полежалое больше любят, не знал? Запилить — это хорошо, но все разом не запилишь, а у нас на тарелке не один этот сыряк.

Слушай, у вас там, наверное, хорошо в 2024, но я тебе пишу из 2020, который начало ковида. В 2020 с QUIC сыряк да голяк.

А как ковид повлиял на ойти?

Никак, я тебе просто напоминаю машину времени вернуть, как накатаешься.

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