Чи швидше gRPC (HTTP / 2), ніж REST з HTTP / 2?

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

HTTP / 2:

1. Мультиплекс
2. Єдине підключення TCP
3. Двійковий замість текстового
4. Стиснення заголовка
5. Серверне натискання

Мені відомі всі вищезазначені переваги. Питання №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. Хоча ви можете використовувати прото з REST, він дуже приємно інтегрований з gRPC. Технічно ви можете використовувати JSON з gRPC, але більшість людей не хочуть платити за продуктивність після звикання до протоколів.

Я не фахівець у цьому жодним чином, і у мене немає даних, щоб підтвердити це.

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

Але gRPC також виконує стиснення gzip. Отже, ми говоримо про різницю між стиснутим gzip JSON та стиснутим gzip протобуфами.

Як ви можете собі уявити, стислі protobufs повинні перемагати стиснений JSON у будь-якому випадку, інакше protobufs не справляються зі своєю метою.

Окрім повсюдної дії JSON проти protobufs, єдиним недоліком, який я бачу при використанні protobufs, є те, що вам потрібен .proto для їх декодування, скажімо в ситуації tcpdump.