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

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

HTTP / 2:

1. Мультиплексированный
2. Одно TCP-соединение
3. Двоичный вместо текстового
4. Сжатие заголовка
5. Сервер 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).

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

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

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

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

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

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

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

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