क्या GRPC(HTTP/2) HTTP/2 के साथ REST से तेज है?




google-cloud-platform http2 (2)

लक्ष्य एक परिवहन और अनुप्रयोग परत प्रोटोकॉल शुरू करना है जो इसकी विलंबता और नेटवर्क थ्रूपुट में बेहतर है। वर्तमान में, एप्लिकेशन HTTP / 1.1 के साथ REST का उपयोग करता है और हम एक उच्च विलंबता का अनुभव करते हैं। मुझे इस विलंबता समस्या को हल करने की आवश्यकता है और मैं gRPC (HTTP / 2) या REST / HTTP2 का उपयोग करने के लिए खुला हूं

HTTP / 2:

  1. मल्टिप्लेक्स
  2. सिंगल टीसीपी कनेक्शन
  3. पाठ के बजाय द्विआधारी
  4. हैडर सम्पीडन
  5. सर्वर पुश

उपरोक्त सभी फायदों से मैं अवगत हूँ। प्रश्न नंबर 1: अगर मैं HTTP / 2 के साथ REST का उपयोग करता हूं, तो मुझे यकीन है, HTTP / 1.1 के साथ REST की तुलना में मुझे एक महत्वपूर्ण प्रदर्शन सुधार मिलेगा, लेकिन यह gRPC (HTTP / 2) के साथ तुलना कैसे करता है?

मुझे यह भी पता है कि जीआरपीसी प्रोटो बफर का उपयोग करता है, जो तार पर संरचित डेटा के संचरण के लिए सबसे अच्छा द्विआधारी क्रमांकन तकनीक है। प्रोटो बफर भी एक भाषा अज्ञेय दृष्टिकोण विकसित करने में मदद करता है। मैं इससे सहमत हूं और मैं ग्राफ़िकल का उपयोग करके आरईएसटी में उसी सुविधा को लागू कर सकता हूं। लेकिन मेरी चिंता क्रमबद्धता पर है: प्रश्न संख्या 2: जब HTTP / 2 इस बाइनरी फीचर को लागू करता है, तो क्या प्रोटो बफर का उपयोग करने से HTTP / 2 के शीर्ष पर अतिरिक्त लाभ मिलता है?

प्रश्न संख्या 3: स्ट्रीमिंग के संदर्भ में , द्वि-दिशात्मक उपयोग-मामलों , gRPC (HTTP / 2) की तुलना (REST और HTTP / 2) से कैसे की जाती है?

इंटरनेट में बहुत सारे ब्लॉग / वीडियो हैं जो this तरह (REST और HTTP / 1.1) के साथ gRPC (HTTP / 2) की तुलना this । जैसा कि पहले कहा गया था, मैं जीआरपीसी (HTTP / 2) और (REST HTTP / 2 के साथ तुलना करने पर) अंतर, लाभ जानना चाहूंगा।


जीआरपीसी डिफ़ॉल्ट रूप से HTTP / 2 पर REST से अधिक तेज़ नहीं है, लेकिन यह आपको इसे तेज़ बनाने के लिए उपकरण देता है। कुछ चीजें हैं जो REST के साथ करना मुश्किल या असंभव होगा।

  • चयनात्मक संदेश संपीड़न। GRPC में एक स्ट्रीमिंग RPC संदेशों को संपीड़ित या संपीड़ित करने का निर्णय ले सकती है। उदाहरण के लिए, यदि आप किसी एकल स्ट्रीम (या वास्तव में मिश्रित मिश्रित सामग्री) पर मिश्रित पाठ और छवियां स्ट्रीम कर रहे हैं, तो आप छवियों के लिए संपीड़न बंद कर सकते हैं। यह आपको पहले से संपीड़ित डेटा को संपीड़ित करने से बचाता है जो किसी भी छोटे से नहीं मिलेगा, लेकिन आपके सीपीयू को जला देगा।
  • फर्स्ट क्लास लोड बैलेंसिंग। पॉइंट टू पॉइंट कनेक्शन में सुधार नहीं होने पर, जीआरपीसी समझदारी से चुन सकता है कि ट्रैफ़िक भेजने के लिए कौन सा बैकएंड है। (यह एक लाइब्रेरी फीचर है, न कि वायर प्रोटोकॉल फीचर)। इसका अर्थ है कि आप प्रॉक्सी का उपयोग किए बिना अपने अनुरोधों को कम से कम लोड किए गए बैकएंड सर्वर पर भेज सकते हैं। यह एक विलंबता जीत है।
  • भारी अनुकूलित। जीआरपीसी (पुस्तकालय) यह सुनिश्चित करने के लिए निरंतर मानदंड के अधीन है कि कोई गति प्रतिगमन नहीं है। वे बेंचमार्क लगातार सुधर रहे हैं। फिर से, इसका जीआरपीसी प्रोटोकॉल से कोई लेना-देना नहीं है, लेकिन आपका प्रोग्राम जीआरपीसी का उपयोग करने के लिए तेज होगा।

जैसा कि nfirvine ने कहा, आप अपने अधिकांश प्रदर्शन सुधार को केवल प्रोटोबॉफ़ के उपयोग से देखेंगे। जबकि आप REST के साथ प्रोटो का उपयोग कर सकते हैं, यह बहुत अच्छी तरह से gRPC के साथ एकीकृत है। तकनीकी रूप से, आप JSON को gRPC के साथ उपयोग कर सकते हैं, लेकिन अधिकांश लोग प्रोटॉज़ के अभ्यस्त होने के बाद प्रदर्शन लागत का भुगतान नहीं करना चाहते हैं।


मैं किसी भी तरह से इस पर एक विशेषज्ञ नहीं हूं और मेरे पास इसका कोई भी डेटा नहीं है।

जिस "बाइनरी फ़ीचर" के बारे में आप बात कर रहे हैं वह HTTP / 2 फ्रेम का बाइनरी प्रतिनिधित्व है। सामग्री स्वयं (एक JSON पेलोड) अभी भी UTF-8 होगी। आप उस JSON को संपीड़ित कर सकते हैं और Content-Encoding: gzip सेट कर सकते हैं Content-Encoding: gzip , जैसे HTTP / 1।

लेकिन gRPC संपीड़न के रूप में भी gzip करता है। तो वास्तव में, हम बात कर रहे हैं gzip- संपीड़ित JSON बनाम gzip- संपीड़ित प्रोटोबुफ़ के बीच के अंतर के बारे में।

जैसा कि आप कल्पना कर सकते हैं, संपीड़ित प्रोटोबोफ्स को हर तरह से संपीड़ित JSON को हरा देना चाहिए, अन्यथा प्रोटोबॉफ़ अपने लक्ष्य पर विफल रहे हैं।

JSON बनाम प्रोटोबॉफ़्स की सर्वव्यापकता के अलावा, केवल नकारात्मक पहलू जो मैं प्रोटोबोफ़्स का उपयोग करके देख सकता हूं, वह यह है कि आपको उन्हें डिकोड करने के लिए .proto की आवश्यकता है, एक tcpdump स्थिति में कहें।







grpc