GRPC (HTTP / 2) быстрее, чем REST с HTTP / 2?

Question 1

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

HTTP / 2:

Мультиплексированный
Одно 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).

Question 2

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

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

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

Question 3

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

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

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

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

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