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

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

HTTP / 2:

  1. Мультиплексированных
  2. одно TCP-соединение
  3. бинарный вместо текста
  4. сжатие заголовков
  5. Сервер Push

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

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

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

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

27
google-cloud-platform grpc http http2 rest

2 ответов

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

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

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

29

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

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

но gRPC также выполняет сжатие gzip. Так что действительно, мы говорим о разнице между gzip-compressed JSON и gzip-compressed protobufs.

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

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

5