GRPC (HTTP / 2) HTTP / 2 ile REST'ten daha mı hızlıdır?

Amaç, gecikme süresinde ve ağ veriminde daha iyi olan bir taşıma ve uygulama katmanı protokolü sunmaktır . Şu anda, uygulama HTTP / 1.1 ile REST kullanıyor ve yüksek bir gecikme yaşıyoruz. Bu gecikme sorununu çözmem gerekiyor ve gRPC (HTTP / 2) veya REST / HTTP2 kullanmaya açığım .

HTTP / 2:

1. Çoklanmış
2. Tek TCP Bağlantısı
3. Metin yerine ikili
4. Üstbilgi sıkıştırma
5. Sunucu İtme

Yukarıdaki tüm avantajların farkındayım. Soru 1: HTTP / 2 ile REST kullanırsam , eminim, HTTP / 1.1 ile REST'e kıyasla önemli bir performans artışı elde edeceğim , ancak bu, gRPC (HTTP / 2) ile nasıl karşılaştırılır ?

Ayrıca gRPC'nin , yapılandırılmış verilerin kablo üzerinden iletimi için en iyi ikili serileştirme tekniği olan proto arabelleği kullandığını da biliyorum . Proto buffer ayrıca dilden bağımsız bir yaklaşım geliştirmeye yardımcı olur. Buna katılıyorum ve aynı özelliği graphQL kullanarak REST'te uygulayabilirim. Ama benim endişem serileştirme bitti: Soru No 2: Ne zaman HTTP / 2 uygular bu ikili özellik , HTTP / 2 üstünde bir katma avantaj sağlayacak tampon proto kullanarak yapar?

Soru 3: Akış açısından , çift yönlü kullanım durumları açısından , gRPC (HTTP / 2) (REST ve HTTP / 2) ile nasıl karşılaştırılır?

Bu kadar çok bloglar / videolar gibi olan gRPC (HTTP / 2) (DİNLENME ve HTTP / 1.1) karşılaştırır internette dışarı bu . Daha önce de belirtildiği gibi, GRPC (HTTP / 2) ve (HTTP / 2 ile REST) ​​karşılaştırmasının farklarını ve faydalarını bilmek istiyorum.

gRPC, varsayılan olarak HTTP / 2 üzerinden REST'ten daha hızlı değildir, ancak size daha hızlı hale getirecek araçları sunar. REST ile yapılması zor veya imkansız olan bazı şeyler vardır.

• Seçici mesaj sıkıştırma. GRPC'de bir akış RPC'si mesajları sıkıştırmaya veya sıkıştırmamaya karar verebilir. Örneğin, tek bir akış üzerinden (veya gerçekten herhangi bir karışık sıkıştırılabilir içerik) karışık metin ve görüntü akışı yapıyorsanız, görüntüler için sıkıştırmayı kapatabilirsiniz. Bu, sizi daha da küçülmeyecek, ancak CPU'nuzu yakacak olan sıkıştırılmış verileri sıkıştırmaktan kurtarır.
• Birinci sınıf yük dengeleme. Noktadan noktaya bağlantılarda bir gelişme olmasa da, gRPC hangi arka ucu akıllıca trafiğe göndereceğini seçebilir. (bu bir kütüphane özelliğidir, bir kablo protokolü özelliği değildir). Bu, isteklerinizi proxy kullanmaya başvurmadan en az yüklenmiş arka uç sunucusuna gönderebileceğiniz anlamına gelir. Bu gecikmeli bir kazançtır.
• Büyük ölçüde optimize edilmiş. gRPC (kütüphane), hız gerilemelerinin olmamasını sağlamak için sürekli kıyaslamalar altındadır . Bu kıyaslamalar sürekli olarak gelişiyor. Yine, bunun protokol olan gRPC ile ilgisi yoktur, ancak programınız gRPC'yi kullandığı için daha hızlı olacaktır.

Nfirvine'in dediği gibi, performans gelişiminizin çoğunu sadece Protobuf kullanarak göreceksiniz. Eğer iken olabilir REST ile proto kullanmak, çok güzel gRPC ile entegre edilmiştir. Teknik olarak JSON'u gRPC ile kullanabilirsiniz, ancak çoğu insan protolara alıştıktan sonra performans maliyetini ödemek istemez.

Bu konuda hiçbir şekilde uzman değilim ve bunların hiçbirini destekleyecek verim yok.

Bahsettiğiniz "ikili özellik", HTTP / 2 çerçevelerinin ikili gösterimidir. İçeriğin kendisi (bir JSON yükü) yine de UTF-8 olacaktır. Bu JSON'u sıkıştırabilir ve Content-Encoding: gzipHTTP / 1 gibi ayarlayabilirsiniz .

Ancak gRPC, gzip sıkıştırması da yapar. Yani gerçekten, gzip-sıkıştırılmış JSON ile gzip-sıkıştırılmış protobuflar arasındaki farktan bahsediyoruz.

Tahmin edebileceğiniz gibi, sıkıştırılmış protobuflar sıkıştırılmış JSON'u her şekilde geçmelidir, aksi takdirde protobuflar hedeflerinde başarısız olmuşlardır.

JSON ile protobufların her yerde bulunmasının yanı sıra, protobuf'ları kullanmanın tek dezavantajı, örneğin bir tcpdump durumunda onları çözmek için .proto'ya ihtiyacınız olmasıdır.