Является ли gRPC (HTTP/2) быстрее, чем REST с HTTP/2?

Цель состоит в том, чтобы внедрить протокол транспортного уровня и уровня приложений, который лучше работает в латентности и пропускной способности сети. В настоящее время приложение использует REST с HTTP/1.1, и мы испытываем высокую задержку. Мне нужно решить эту проблему с задержкой, и я открыт для использования gRPC (HTTP/2) или REST/HTTP2.

HTTP/2:

Multiplexed
Одиночное TCP-соединение
Двоичный вместо текстового
сжатие заголовка
Сервер Push

Я знаю все вышеперечисленные преимущества. Вопрос № 1: Если я использую REST с HTTP/2, я уверен, я получу значительное улучшение производительности по сравнению с REST с HTTP/1.1, но как это соотносится с gRPC (HTTP/2)?

Мне также известно, что gRPC использует прото-буфер, который является лучшим методом двоичной сериализации для передачи структурированных данных на провод. Прото-буфер также помогает в разработке агностического подхода к языку. Я согласен с этим, и я могу реализовать ту же функцию в REST, используя graphQL. Но моя озабоченность связана с сериализацией: Вопрос № 2: Когда HTTP/2 реализует эту двоичную функцию, использует ли прото-буфер дополнительное преимущество поверх HTTP/2?

Вопрос № 3: Что касается потоковых, двунаправленных прецедентов, как сравнить gRPC (HTTP/2) с (REST и HTTP/2 )?

В Интернете существует так много блогов/видео, которые сравнивают gRPC (HTTP/2) с (REST и HTTP/1.1), например это. Как уже говорилось ранее, я хотел бы знать различия, преимущества при сравнении GRPC (HTTP/2) и (REST с HTTP/2).

Ответ 1

gRPC по умолчанию не быстрее, чем REST по HTTP/2, но он дает вам инструменты для ускорения работы. Есть некоторые вещи, которые было бы трудно или невозможно сделать с REST.

Выборочное сжатие сообщений. В gRPC потоковый RPC может решить сжимать или не сжимать сообщения. Например, если вы перемещаете смешанный текст и изображения поверх одного потока (или действительно любого смешанного сжимаемого содержимого), вы можете отключить сжатие для изображений. Это избавит вас от сжатия уже сжатых данных, которые не будут уменьшаться, но сгорит ваш процессор.
Первичная балансировка нагрузки. Хотя это не улучшает соединения с точкой, точка gRPC может разумно выбирать, какой сервер для отправки трафика. (это функция библиотеки, а не функция проводного протокола). Это означает, что вы можете отправлять свои запросы на наименее загруженный серверный сервер, не прибегая к использованию прокси-сервера. Это латентный выигрыш.
Тяжелая оптимизация. gRPC (библиотека) находится под непрерывными эталонами, чтобы гарантировать отсутствие регрессий по скорости. Эти тесты постоянно совершенствуются. Опять же, это не имеет ничего общего с протоколом gRPC, но ваша программа будет быстрее использовать gRPC.

Как сказал nfirvine, вы увидите большую часть своего улучшения производительности только от использования Protobuf. Хотя вы можете использовать proto с REST, он очень хорошо интегрирован с gRPC. Технически вы можете использовать JSON с gRPC, но большинство людей не хотят платить за производительность после использования в протосах.

Ответ 2

Я не эксперт по этому поводу, и у меня нет данных, чтобы поддержать это.

"Бинарная функция", о которой вы говорите, - это двоичное представление кадров HTTP/2. Сам контент (полезная нагрузка JSON) по-прежнему будет UTF-8. Вы можете сжать этот JSON и установить Content-Encoding: gzip, как HTTP/1.

Но gRPC также делает сжатие gzip. Итак, мы говорим о разнице между сжатыми gzip JSON и gzip-сжатыми protobufs.

Как вы можете себе представить, сжатые протобуфы должны бить сжатый JSON во всех отношениях, иначе протобуфы потерпели неудачу в их цели.

Помимо вездесущности JSON против protobufs, единственный недостаток, который я могу видеть в использовании protobufs, заключается в том, что вам нужно использовать .proto для их декодирования, например, в ситуации tcpdump.