Ответ
gRPC работает поверх HTTP/2. Этот выбор является фундаментальным и обусловлен ключевыми возможностями HTTP/2, которые необходимы для эффективной работы gRPC:
-
Мультиплексирование (Multiplexing): HTTP/2 позволяет отправлять множество запросов и ответов одновременно через одно TCP-соединение, не блокируя друг друга. Это критически важно для высокопроизводительных микросервисных архитектур, где один клиент может одновременно общаться с множеством сервисов.
-
Двунаправленная потоковая передача (Bidirectional Streaming): gRPC активно использует стриминг (серверный, клиентский и двунаправленный). HTTP/2 предоставляет нативную поддержку потоков, что делает реализацию стриминга в gRPC естественной и эффективной.
-
Бинарный протокол (Binary Protocol): В отличие от текстового HTTP/1.1, HTTP/2 использует бинарный фреймовый протокол. Он более компактен, эффективен и менее подвержен ошибкам при парсинге, что снижает задержки и нагрузку на сеть.
-
Сжатие заголовков (Header Compression with HPACK): Уменьшает накладные расходы за счет эффективного сжатия HTTP-заголовков, что особенно полезно при большом количестве мелких запросов.
Из-за этих требований gRPC несовместим с HTTP/1.1, который не поддерживает мультиплексирование и потоковую передачу в том виде, который нужен gRPC.
Примечание: Для работы gRPC в браузерах, где прямой контроль над HTTP/2 ограничен, используется прокси-технология gRPC-Web, которая транслирует вызовы в совместимый с браузерами формат (например, HTTP/1.1).
Ответ 18+ 🔞
Да ты послушай, на что они эту gRPC посадили! Прям как на ракету — на HTTP/2, блядь. И это не просто так, а потому что старый добрый HTTP/1.1 для ихних затей — это как телега для формулы-1, ебать мои старые костыли.
Смотри, в чём тут соль, а то сейчас мозг взорвёшь:
-
Мультиплексирование (Multiplexing): Это когда по одной трубе (TCP-соединению) можно одновременно запустить кучу запросов-ответов, и они друг другу не мешают. Представь, не надо ждать, пока один допиздится, чтобы следующий отправить. Для микросервисов, которые друг друга дергают без остановки — это просто пиздец как важно. Без этого — пиши пропало, производительность на нуле.
-
Двунаправленная потоковая передача (Bidirectional Streaming): А это вообще их конёк, ёпта! gRPC же умеет не просто запрос-ответ, а прям поток данных в обе стороны — как чат. Так вот, HTTP/2 эту фичу поддерживает нативно, из коробки. Не надо костылей городить, всё красиво и быстро.
-
Бинарный протокол (Binary Protocol): А вот это уже не текстовые сопли, как в HTTP/1.1, которые парсить — тот ещё геморрой. Тут всё упаковано в бинарные фреймы. Компактнее, быстрее, надёжнее. Меньше лишних байт по сети летает — меньше лаг.
-
Сжатие заголовков (Header Compression with HPACK): Ну и вишенка на торте. Заголовки не тупо каждый раз целиком шлются, а сжимаются по уму. Когда запросов овердохуища — экономия просто космическая.
И вот из-за всего этого великолепия gRPC с HTTP/1.1 просто не дружит, они на разных планетах. Тот старичок не потянет ни мультиплексирование, ни нормальный стриминг.
Ах да, про браузеры! Там же своя атмосфера, блядь. Прямой доступ к HTTP/2 не всегда есть. Так вот умные головы придумали gRPC-Web — этакую переводчицу-шпионку, которая преобразует ихние навороты в то, что браузер проглотит (типа того же HTTP/1.1). Хитрая жопа, но работает!