Czy gRPC (HTTP / 2) jest szybszy niż REST z HTTP / 2?

Question 1

Celem jest wprowadzenie protokołu warstwy transportowej i aplikacji o lepszych opóźnieniach i przepustowości sieci . Obecnie aplikacja korzysta z REST z HTTP / 1.1 i doświadczamy dużego opóźnienia. Muszę rozwiązać ten problem z opóźnieniami i jestem otwarty na korzystanie z gRPC (HTTP / 2) lub REST / HTTP2 .

HTTP / 2:

Multipleksowane
Pojedyncze połączenie TCP
Binarny zamiast tekstowy
Kompresja nagłówka
Serwer Push

Mam świadomość wszystkich powyższych zalet. Pytanie nr 1: Jeśli używam REST z HTTP / 2 , jestem pewien, że uzyskam znaczną poprawę wydajności w porównaniu do REST z HTTP / 1.1 , ale jak to się ma do gRPC (HTTP / 2) ?

Zdaję sobie również sprawę, że gRPC używa bufora proto, który jest najlepszą techniką serializacji binarnej do transmisji danych strukturalnych w sieci. Bufor Proto pomaga również w opracowaniu podejścia agnostycznego językowego. Zgadzam się z tym i mogę zaimplementować tę samą funkcję w REST za pomocą GraphQL. Ale moje obawy dotyczą serializacji: Pytanie nr 2: Kiedy HTTP / 2 implementuje tę funkcję binarną , czy użycie bufora proto daje dodatkową przewagę nad HTTP / 2?

Pytanie nr 3: Pod względem przesyłania strumieniowego, dwukierunkowych przypadków użycia , jak wypada porównanie gRPC (HTTP / 2) z (REST i HTTP / 2)?

W Internecie jest tak wiele blogów / filmów , które porównują gRPC (HTTP / 2) z (REST i HTTP / 1.1) w ten sposób . Jak wspomniano wcześniej, chciałbym poznać różnice, korzyści płynące z porównania GRPC (HTTP / 2) i (REST z HTTP / 2).

Question 2

gRPC nie jest domyślnie szybszy niż REST przez HTTP / 2, ale zapewnia narzędzia, które przyspieszą. Jest kilka rzeczy, które byłyby trudne lub niemożliwe do zrobienia z REST.

Selektywna kompresja wiadomości. W gRPC przesyłanie strumieniowe RPC może zdecydować o kompresji lub nie kompresji wiadomości. Na przykład, jeśli przesyłasz strumieniowo mieszany tekst i obrazy w jednym strumieniu (lub naprawdę dowolną mieszaną zawartość podlegającą kompresji), możesz wyłączyć kompresję obrazów. Oszczędza to kompresję już skompresowanych danych, które nie będą już mniejsze, ale spowodują spalenie procesora.
Równoważenie obciążenia pierwszej klasy. Chociaż nie jest to poprawa w zakresie połączeń punktowych, gRPC może inteligentnie wybierać zaplecze, do którego ma kierować ruch. (jest to funkcja biblioteki, a nie funkcja protokołu przewodowego). Oznacza to, że możesz wysyłać żądania do najmniej obciążonego serwera zaplecza bez uciekania się do korzystania z serwera proxy. To jest wygrana z opóźnieniem.
Mocno zoptymalizowany. gRPC (biblioteka) podlega ciągłym testom porównawczym, aby zapewnić, że nie ma regresji szybkości. Te standardy są stale ulepszane. Ponownie, nie ma to nic wspólnego z protokołem gRPC, ale program będzie działał szybciej, jeśli używał gRPC.

Jak powiedział nfirvine, większość poprawy wydajności zauważysz tylko dzięki zastosowaniu Protobuf. Chociaż można używać protokołu Proto z REST, jest on bardzo ładnie zintegrowany z gRPC. Technicznie rzecz biorąc, można użyć JSON z gRPC, ale większość ludzi nie chce płacić kosztów wydajności po przyzwyczajeniu się do protosów.

Question 3

W żadnym wypadku nie jestem ekspertem w tej dziedzinie i nie mam danych, aby to potwierdzić.

„Funkcja binarna”, o której mówisz, to binarna reprezentacja ramek HTTP / 2. Sama zawartość (ładunek JSON) nadal będzie w formacie UTF-8. Możesz skompresować ten JSON i ustawić Content-Encoding: gzip, tak jak HTTP / 1.

Ale gRPC obsługuje również kompresję gzip. Więc tak naprawdę mówimy o różnicy między JSON skompresowanymi gzip a protobufami skompresowanymi gzip.

Jak możesz sobie wyobrazić, skompresowane protobufy powinny pod każdym względem pokonać skompresowany JSON, w przeciwnym razie protobufy nie osiągnęły swojego celu.

Oprócz wszechobecności JSON i protobufs, jedyną wadą, jaką widzę w używaniu protobufów, jest to, że potrzebujesz .proto do ich odkodowania, powiedzmy w sytuacji tcpdump.