← Back to Blog
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

gRPC प्रॉक्सी के माध्यम से माइक्रोसर्विस आर्किटेक्चर में: HTTP/2 टनलिंग सेटअप के लिए पूर्ण मार्गदर्शिका

gRPC ट्रैफ़िक को प्रॉक्सी सर्वरों के माध्यम से माइक्रोसर्विस आर्किटेक्चर में सेटअप करने के लिए विस्तृत गाइड - HTTP/2 टनलिंग से लेकर लोड बैलेंसिंग और TLS टर्मिनेशन तक।

📅August 7, 2026
```html

gRPC — यह Google का एक उच्च प्रदर्शन RPC ढांचा है, जो HTTP/2 के ऊपर काम करता है और यह अंतर-सर्विस इंटरैक्शन के लिए डिफ़ॉल्ट मानक बनता जा रहा है। लेकिन जैसे ही आप gRPC ट्रैफ़िक को प्रॉक्सी के माध्यम से भेजने की कोशिश करते हैं, समस्याएँ तुरंत उत्पन्न होती हैं: अधिकांश पारंपरिक प्रॉक्सी सर्वर HTTP/2 और दीर्घकालिक स्ट्रीमिंग कनेक्शनों के साथ काम नहीं कर सकते। इस लेख में, हम देखेंगे कि gRPC को प्रॉक्सी के माध्यम से सही तरीके से कैसे सेटअप किया जाए — आर्किटेक्चर के चयन से लेकर Nginx, Envoy और HAProxy की विशिष्ट कॉन्फ़िगरेशन तक।

क्यों gRPC सामान्य प्रॉक्सी के साथ ठीक से काम नहीं करता

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

यहाँ कुछ विशिष्ट समस्याएँ हैं जिनका सामना आपको सामान्य HTTP प्रॉक्सी के माध्यम से gRPC भेजने की कोशिश करते समय करना पड़ेगा:

  • HTTP/1.1 पर डाउनग्रेड। कई प्रॉक्सी स्वचालित रूप से प्रोटोकॉल के संस्करण को कम कर देते हैं। gRPC को HTTP/2 की आवश्यकता होती है — इसके बिना कनेक्शन स्थापित नहीं होगा, और क्लाइंट को UNAVAILABLE त्रुटि मिलेगी।
  • दीर्घकालिक कनेक्शनों का टूटना। gRPC सक्रिय रूप से सर्वर-साइड और द्विदिश स्ट्रीमिंग का उपयोग करता है। आक्रामक टाइमआउट वाले प्रॉक्सी (विशेष रूप से AWS ELB क्लासिक, कुछ संस्करणों के साथ Squid) 60 सेकंड से अधिक डेटा नहीं भेजने वाले कनेक्शनों को काट देते हैं।
  • Content-Type के साथ समस्याएँ। gRPC Content-Type: application/grpc हेडर का उपयोग करता है। जो प्रॉक्सी इस प्रकार को नहीं जानता है, वह अनुरोध को अस्वीकार कर सकता है या शरीर को गलत तरीके से बफर कर सकता है।
  • ट्रेलर्स। gRPC HTTP/2 ट्रेलर्स का उपयोग कॉल के समाप्ति स्थिति को भेजने के लिए करता है। HTTP/1.1 प्रॉक्सी ट्रेलर्स का समर्थन नहीं करते हैं — स्थिति की जानकारी खो जाएगी।
  • शरीर का बफरिंग। कुछ प्रॉक्सी सभी उत्तर के शरीर को क्लाइंट को भेजने से पहले बफर करते हैं। स्ट्रीमिंग gRPC कॉल के लिए, इसका मतलब है कि क्लाइंट को कोई संदेश नहीं मिलेगा जब तक कि स्ट्रीम समाप्त नहीं हो जाती।

मुख्य निष्कर्ष:

gRPC को प्रॉक्सी के माध्यम से काम करने के लिए HTTP/2 एंड-टू-एंड का समर्थन करने वाला प्रॉक्सी या विशेष टनलिंग मोड की आवश्यकता होती है। बिना कॉन्फ़िगरेशन के क्लासिक HTTP प्रॉक्सी उपयुक्त नहीं होगा।

HTTP/2 टनलिंग: यह कैसे काम करता है

gRPC ट्रैफ़िक को प्रॉक्सी करने के लिए दो मौलिक दृष्टिकोण हैं, और सही समाधान चुनने के लिए उनके बीच का अंतर समझना महत्वपूर्ण है।

दृष्टिकोण 1: HTTP/2 एंड-टू-एंड (अनुशंसित)

प्रॉक्सी HTTP/2 को समझता है और क्लाइंट और बैकएंड दोनों के साथ HTTP/2 कनेक्शन स्थापित करता है। यह अलग-अलग स्ट्रीम का विश्लेषण कर सकता है, अनुरोध स्तर पर लोड बैलेंसिंग लागू कर सकता है, हेडर जोड़ सकता है और TLS टर्मिनेशन कर सकता है। यह सबसे कार्यात्मक विकल्प है — Envoy, Nginx (संस्करण 1.13.10 से) और क्लाउड प्रदाताओं में gRPC-जानकारी वाले लोड बैलेंसर्स इस तरह काम करते हैं।

दृष्टिकोण 2: TCP टनलिंग (CONNECT)

प्रॉक्सी HTTP/2 ट्रैफ़िक का विश्लेषण नहीं करता है, बल्कि बस CONNECT विधि के माध्यम से एक पारदर्शी TCP टनल बनाता है। क्लाइंट सीधे बैकएंड के साथ टनल के माध्यम से TLS कनेक्शन स्थापित करता है। प्रॉक्सी केवल एन्क्रिप्टेड बाइट स्ट्रीम देखता है। यह विधि सेटअप में सरल है, लेकिन आपको gRPC अनुरोध स्तर पर लोड बैलेंसिंग और हेडर जोड़ने की क्षमताओं से वंचित कर देती है।

विशेषता HTTP/2 एंड-टू-एंड TCP CONNECT टनल
अनुरोधों के लिए लोड बैलेंसिंग ✅ हाँ ❌ नहीं (केवल TCP)
प्रॉक्सी पर TLS टर्मिनेशन ✅ हाँ ❌ नहीं
हेडर जोड़ना ✅ हाँ ❌ नहीं
सेटअप की जटिलता मध्यम कम
स्ट्रीमिंग का समर्थन ✅ पूर्ण ✅ पूर्ण
अवलोकन (मेट्रिक्स) ✅ विस्तृत ❌ केवल TCP

Nginx को gRPC प्रॉक्सी के रूप में सेटअप करना

Nginx संस्करण 1.13.10 (फरवरी 2018) से gRPC प्रॉक्सी का समर्थन करता है। इसके लिए ngx_http_grpc_module मॉड्यूल की आवश्यकता होती है, जो मानक बिल्ड में शामिल है। महत्वपूर्ण: Nginx क्लाइंट (फ्रंटेंड) की ओर HTTP/2 का समर्थन करता है, लेकिन बैकएंड की ओर gRPC के लिए ही HTTP/2 का उपयोग करता है — सामान्य HTTP अपस्ट्रीम HTTP/1.1 पर काम करता है।

Nginx पर gRPC प्रॉक्सी के लिए बुनियादी कॉन्फ़िगरेशन

server {
    listen 443 ssl http2;
    server_name grpc.example.com;

    # TLS प्रमाण पत्र
    ssl_certificate     /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    # आधुनिक TLS पैरामीटर
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        # प्रॉक्सी पास के बजाय grpc_pass निर्देश
        grpc_pass grpc://grpc_backend;

        # दीर्घकालिक स्ट्रीम के लिए टाइमआउट
        grpc_read_timeout  3600s;
        grpc_send_timeout  3600s;
        grpc_connect_timeout 5s;

        # वास्तविक क्लाइंट IP को पास करना
        grpc_set_header X-Real-IP $remote_addr;
        grpc_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

upstream grpc_backend {
    server backend-1:50051;
    server backend-2:50051;
    server backend-3:50051;

    # HTTP/2 कनेक्शनों के लिए कीपअलाइव
    keepalive 32;
}

कुछ महत्वपूर्ण विवरणों पर ध्यान दें। पहले, grpc_pass निर्देश का उपयोग किया गया है, न कि proxy_pass — ये अलग-अलग मॉड्यूल हैं जिनका अलग व्यवहार है। दूसरे, grpc_read_timeout और grpc_send_timeout को 3600 सेकंड (1 घंटा) पर सेट किया गया है — यह सर्वर स्ट्रीम के लिए महत्वपूर्ण है, जो डेटा भेजे बिना लंबे समय तक काम कर सकते हैं। तीसरे, keepalive 32 अपस्ट्रीम में HTTP/2 कनेक्शनों को पुनः उपयोग करने की अनुमति देता है।

गैर-एन्क्रिप्टेड gRPC के लिए कॉन्फ़िगरेशन (grpc://)

server {
    listen 80 http2;
    server_name grpc-internal.example.com;

    location / {
        grpc_pass grpc://127.0.0.1:50051;

        # gRPC त्रुटियों को संभालना
        error_page 502 = /error502grpc;
    }

    location = /error502grpc {
        internal;
        default_type application/grpc;
        add_header grpc-status 14;
        add_header content-length 0;
        return 204;
    }
}

error502grpc ब्लॉक एक महत्वपूर्ण विवरण है: जब बैकएंड अनुपलब्ध होता है, तो यह सही gRPC स्थिति UNAVAILABLE (14) लौटाता है, न कि HTTP 502, जिसे gRPC क्लाइंट सही तरीके से संभाल नहीं पाएगा।

Envoy प्रॉक्सी: माइक्रोसर्विसेज में gRPC के लिए सबसे अच्छा विकल्प

Envoy को Lyft द्वारा विशेष रूप से माइक्रोसर्विस आर्किटेक्चर के लिए बनाया गया था, और इसमें gRPC का समर्थन सबसे गहरे स्तर पर लागू किया गया है। यह प्रोटोकॉल बफर्स को समझता है, gRPC को REST में ट्रांसकोड कर सकता है, प्रत्येक RPC विधि के लिए विस्तृत मेट्रिक्स एकत्र करता है और सेवा मैश समाधानों के लिए आधार है — Istio, AWS App Mesh और अन्य। यदि आप एक गंभीर माइक्रोसर्विस आर्किटेक्चर का निर्माण कर रहे हैं, तो Envoy उद्योग का मानक है।

gRPC के लिए Envoy का बुनियादी कॉन्फ़िगरेशन

static_resources:
  listeners:
  - name: grpc_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 8080
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: grpc_proxy
          codec_type: HTTP2
          route_config:
            name: grpc_routes
            virtual_hosts:
            - name: grpc_services
              domains: ["*"]
              routes:
              - match:
                  prefix: "/com.example.UserService"
                route:
                  cluster: user_service
                  timeout: 30s
                  retry_policy:
                    retry_on: "reset,connect-failure,retriable-status-codes"
                    num_retries: 3
                    retriable_status_codes: [14]
              - match:
                  prefix: "/com.example.OrderService"
                route:
                  cluster: order_service
                  timeout: 60s
          http_filters:
          - name: envoy.filters.http.grpc_stats
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_stats.v3.FilterConfig
              emit_filter_state: true
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

  clusters:
  - name: user_service
    connect_timeout: 5s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    http2_protocol_options: {}
    load_assignment:
      cluster_name: user_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: user-service
                port_value: 50051

इस कॉन्फ़िगरेशन के प्रमुख लाभ: gRPC सेवाओं के लिए मार्गनिर्देशन (पथ का प्रीफिक्स package.ServiceName प्रारूप में सेवा के पूर्ण नाम के साथ मेल खाता है), UNAVAILABLE स्थिति पर स्वचालित पुनः प्रयास और grpc_stats फ़िल्टर के माध्यम से gRPC मेट्रिक्स का संग्रह।

Envoy में gRPC-Web ट्रांसकोडिंग

Envoy की एक प्रमुख विशेषता — अंतर्निहित gRPC-Web ट्रांसकोडर। ब्राउज़र सीधे gRPC का समर्थन नहीं करते हैं (HTTP/2 ट्रेलर्स पर Fetch API की सीमाओं के कारण), इसलिए gRPC-Web प्रोटोकॉल का उपयोग किया जाता है। Envoy स्वचालित रूप से ब्राउज़र से gRPC-Web अनुरोधों को बैकएंड के लिए सामान्य gRPC में परिवर्तित कर सकता है: 

http_filters:
- name: envoy.filters.http.grpc_web
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_web.v3.GrpcWeb
- name: envoy.filters.http.cors
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.cors.v3.CorsPolicy
- name: envoy.filters.http.router
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

HAProxy और gRPC: लोड बैलेंसिंग के साथ कॉन्फ़िगरेशन

HAProxy संस्करण 1.9.2 से gRPC का समर्थन करता है। यह TCP या HTTP/2 स्तर पर काम करता है, gRPC ट्रैफ़िक को लोड बैलेंस कर सकता है और स्वास्थ्य जांच कर सकता है। HAProxy एक अच्छा विकल्प है यदि आप पहले से ही इसे अपने बुनियादी ढाँचे में उपयोग कर रहे हैं और gRPC का समर्थन जोड़ना चाहते हैं बिना किसी नए घटक को शामिल किए। 

global
    maxconn 50000
    log stdout format raw local0

defaults
    log global
    timeout connect 5s
    timeout client  3600s
    timeout server  3600s

frontend grpc_frontend
    bind *:443 ssl crt /etc/haproxy/certs/server.pem alpn h2,http/1.1
    mode http
    option http-use-htx
    default_backend grpc_servers

backend grpc_servers
    mode http
    balance leastconn
    option http-use-htx

    # gRPC स्वास्थ्य जांच प्रोटोकॉल के माध्यम से स्वास्थ्य जांच
    option httpchk GET /grpc.health.v1.Health/Check
    http-check expect status 200

    server grpc1 10.0.0.1:50051 check ssl verify none
    server grpc2 10.0.0.2:50051 check ssl verify none
    server grpc3 10.0.0.3:50051 check ssl verify none

कुछ महत्वपूर्ण सेटिंग्स पर ध्यान दें। alpn h2,http/1.1 बाइंड निर्देश में यह इंगित करता है कि HAProxy TLS ALPN वार्ता के माध्यम से HTTP/2 और HTTP/1.1 दोनों कनेक्शन स्वीकार करता है। timeout client 3600s और timeout server 3600s — दीर्घकालिक gRPC स्ट्रीम के लिए महत्वपूर्ण पैरामीटर हैं। leastconn एल्गोरिदम gRPC के लिए roundrobin की तुलना में बेहतर है, क्योंकि स्ट्रीमिंग कनेक्शन दीर्घकालिक हो सकते हैं और बैकएंड को असमान रूप से लोड कर सकते हैं।

TLS टर्मिनेशन और एंड-टू-एंड एन्क्रिप्शन के लिए gRPC

gRPC डिफ़ॉल्ट रूप से TLS का उपयोग करने की अपेक्षा करता है — यह विनिर्देशन का एक हिस्सा है। व्यावहारिक रूप से माइक्रोसर्विस आर्किटेक्चर में यह प्रश्न उठता है: TLS टर्मिनेशन कहाँ करना है और घटकों के बीच एन्क्रिप्शन कैसे व्यवस्थित करना है? तीन मुख्य पैटर्न हैं।

पैटर्न 1: प्रॉक्सी पर TLS टर्मिनेशन (Edge TLS)

प्रॉक्सी क्लाइंट से एन्क्रिप्टेड ट्रैफ़िक प्राप्त करता है, उसे डिक्रिप्ट करता है और बैकएंड पर अनएन्क्रिप्टेड चैनल (या अलग TLS के साथ) पर भेजता है। यह कॉर्पोरेट नेटवर्क में सबसे सामान्य दृष्टिकोण है। बैकएंड grpc.Insecure() का उपयोग करके कॉन्फ़िगरेशन को सरल बना सकते हैं।

पैटर्न 2: एंड-टू-एंड एन्क्रिप्शन (mTLS)

म्यूचुअल TLS (mTLS) सेवा मैश के लिए मानक है। प्रत्येक सेवा का अपना प्रमाण पत्र होता है, और प्रत्येक कनेक्शन पर दोनों पक्ष एक-दूसरे के प्रमाण पत्र की जांच करते हैं। यह सेवाओं की प्रमाणीकरण और क्लस्टर के भीतर ट्रैफ़िक की एन्क्रिप्शन सुनिश्चित करता है। यही Istio Envoy साइडकार प्रॉक्सी के साथ काम करता है। 

# Go: mTLS के साथ gRPC सर्वर
import (
    "crypto/tls"
    "crypto/x509"
    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials"
)

func createMTLSCredentials() credentials.TransportCredentials {
    cert, _ := tls.LoadX509KeyPair("server.crt", "server.key")
    
    caCert, _ := os.ReadFile("ca.crt")
    caCertPool := x509.NewCertPool()
    caCertPool.AppendCertsFromPEM(caCert)
    
    tlsConfig := &tls.Config{
        Certificates: []tls.Certificate{cert},
        ClientAuth:   tls.RequireAndVerifyClientCert,
        ClientCAs:    caCertPool,
    }
    
    return credentials.NewTLS(tlsConfig)
}

// mTLS के साथ सर्वर बनाना
creds := createMTLSCredentials()
server := grpc.NewServer(grpc.Creds(creds))

पैटर्न 3: TLS पासथ्रू

प्रॉक्सी TCP स्तर पर काम करता है और ट्रैफ़िक को डिक्रिप्ट नहीं करता है — बस एन्क्रिप्टेड बाइट्स को बैकएंड पर रीडायरेक्ट करता है। यह प्रॉक्सी के दृष्टिकोण से सबसे सरल विकल्प है, लेकिन यह gRPC ट्रैफ़िक का विश्लेषण करने, हेडर जोड़ने या अनुरोध स्तर पर लोड बैलेंसिंग करने की क्षमता से वंचित कर देता है।

gRPC स्ट्रीम के लिए लोड बैलेंसिंग: विशेषताएँ और समाधान

gRPC के लिए लोड बैलेंसिंग एक सरल कार्य नहीं है, और इसका कारण यह है। HTTP/1.1 में प्रत्येक अनुरोध एक अलग TCP कनेक्शन (या पूल से कनेक्शन) होता है, और लोड बैलेंसर आसानी से अनुरोधों को बैकएंड पर वितरित करता है। HTTP/2 में एक TCP कनेक्शन कई स्ट्रीम को मल्टीप्लेक्स करता है — यदि लोड बैलेंसर TCP स्तर पर काम कर रहा है, तो एक कनेक्शन के सभी स्ट्रीम एक ही बैकएंड पर जाएंगे।

gRPC के लिए इसका मतलब है: यदि क्लाइंट ने एक HTTP/2 कनेक्शन स्थापित किया है और इसके माध्यम से 100 RPC अनुरोध भेजता है, तो TCP लोड बैलेंसिंग के दौरान सभी 100 अनुरोध एक बैकएंड के एक उदाहरण द्वारा संसाधित किए जाएंगे। अन्य बैकएंड निष्क्रिय रहेंगे। समाधान — HTTP/2 स्ट्रीम स्तर पर लोड बैलेंसिंग (L7 लोड बैलेंसिंग)।

gRPC के लिए लोड बैलेंसिंग एल्गोरिदम

एल्गोरिदम gRPC के लिए उपयुक्त टिप्पणी
राउंड रोबिन ✅ हाँ लगभग समान प्रोसेसिंग समय के साथ युनी RPC के लिए अच्छा
लीस्ट कनेक्शन ✅ सबसे अच्छा विकल्प सक्रिय स्ट्रीम को ध्यान में रखता है, लोड को समान रूप से वितरित करता है
रैंडम ⚠️ सशर्त कई अनुरोधों के लिए काम करता है, कम पर असमान है
IP हैश ❌ खराब क्लाइंट को एक बैकएंड से बांधता है, L7 पर कोई मतलब नहीं
पिक फर्स्ट (gRPC अंतर्निहित) ❌ उत्पादन के लिए नहीं सभी अनुरोध पहले उपलब्ध सर्वर पर जाते हैं

gRPC में क्लाइंट लोड बैलेंसिंग

gRPC क्लाइंट लोड बैलेंसिंग का समर्थन करता है — क्लाइंट स्वयं यह तय करता है कि अनुरोध किस सर्वर पर भेजना है। यह TCP मल्टीप्लेक्सिंग की समस्या को обход करने की अनुमति देता है। सेवा खोज के लिए DNS का उपयोग किया जाता है जिसमें कई A रिकॉर्ड होते हैं या विशेष रिसोल्वर (Consul, etcd) होते हैं। Go में क्लाइंट लोड बैलेंसिंग सेटअप का उदाहरण: 

import (
    "google.golang.org/grpc"
    "google.golang.org/grpc/balancer/roundrobin"
)

// DNS के माध्यम से राउंड-रोबिन लोड बैलेंसिंग वाला क्लाइंट
conn, err := grpc.Dial(
    "dns:///grpc-service.internal:50051",
    grpc.WithDefaultServiceConfig(
        `{"loadBalancingConfig": [{"round_robin":{}}]}`
    ),
    grpc.WithTransportCredentials(creds),
)

// लीस्ट-कनेक्शन के साथ क्लाइंट (gRPC >= 1.58 में उपलब्ध)
conn, err := grpc.Dial(
    "dns:///grpc-service.internal:50051",
    grpc.WithDefaultServiceConfig(
        `{"loadBalancingConfig": [{"least_request":{}}]}`
    ),
    grpc.WithTransportCredentials(creds),
)

gRPC के लिए बाहरी प्रॉक्सी: कब और क्यों आवश्यक हैं माइक्रोसर्विसेज में

आंतरिक प्रॉक्सी घटकों (Nginx, Envoy, HAProxy) के अलावा, माइक्रोसर्विस आर्किटेक्चर में कभी-कभी बाहरी प्रॉक्सी सर्वरों का उपयोग करने की आवश्यकता होती है — उदाहरण के लिए, ट्रैफ़िक को विशिष्ट क्षेत्रों के माध्यम से रूट करने, नेटवर्क प्रतिबंधों को बायपास करने या आउटगोइंग कनेक्शनों को अलग करने के लिए। आइए मुख्य परिदृश्यों पर विचार करें।

परिदृश्य 1: भू-प्रवासी माइक्रोसर्विसेज

यदि आपकी माइक्रोसर्विसेज विभिन्न क्षेत्रों में स्थित हैं (उदाहरण के लिए, कुछ यूरोप में, कुछ अमेरिका में), और आपको यह नियंत्रित करने की आवश्यकता है कि gRPC कनेक्शन किन IP पते के माध्यम से स्थापित किए जाते हैं, तो बाहरी प्रॉक्सी पूर्वानुमानित रूटिंग व्यवस्थित करने में मदद कर सकते हैं। ऐसे कार्यों के लिए डेटा सेंटर प्रॉक्सी उपयुक्त हैं — ये स्थिर IP पते और उच्च कनेक्शन गति प्रदान करते हैं, जो gRPC के लिए महत्वपूर्ण है, जो देरी के प्रति संवेदनशील है।

परिदृश्य 2: आउटगोइंग ट्रैफ़िक का पृथक्करण

कुछ कॉर्पोरेट वातावरणों में, सभी आउटगोइंग ट्रैफ़िक को कॉर्पोरेट प्रॉक्सी के माध्यम से जाना चाहिए। gRPC क्लाइंट के लिए, जिन्हें बाहरी gRPC सेवाओं (जैसे, Google Cloud APIs, जो gRPC का उपयोग करते हैं) से संपर्क करने की आवश्यकता होती है, यह जटिलताएँ उत्पन्न करता है। समाधान — कॉर्पोरेट प्रॉक्सी के माध्यम से CONNECT टनल सेटअप करना।

Go में HTTP CONNECT प्रॉक्सी के माध्यम से gRPC क्लाइंट के लिए सेटअप का उदाहरण: 

import (
    "net"
    "net/http"
    "golang.org/x/net/proxy"
    "google.golang.org/grpc"
)

// gRPC के लिए SOCKS5 प्रॉक्सी का उपयोग करना
proxyDialer, _ := proxy.SOCKS5(
    "tcp",
    "proxy.example.com:1080",
    &proxy.Auth{User: "user", Password: "pass"},
    proxy.Direct,
)

conn, err := grpc.Dial(
    "grpc-service.example.com:443",
    grpc.WithContextDialer(func(ctx context.Context, addr string) (net.Conn, error) {
        return proxyDialer.Dial("tcp", addr)
    }),
    grpc.WithTransportCredentials(creds),
)

परिदृश्य 3: परीक्षण और विकास

माइक्रोसर्विसेज के विकास के दौरान अक्सर विभिन्न नेटवर्क वातावरणों से सेवाओं के व्यवहार का परीक्षण करने की आवश्यकता होती है — यह जांचने के लिए कि सेवा उच्च देरी पर कैसे प्रतिक्रिया करती है, या भू-निर्भर लॉजिक का परीक्षण करने के लिए। ऐसे कार्यों के लिए सुविधाजनक होते हैं रहायशी प्रॉक्सी, जो वास्तविक घरेलू उपयोगकर्ताओं के वास्तविक IP के साथ विशिष्ट क्षेत्रों से अनुरोधों का अनुकरण करने की अनुमति देते हैं।

gRPC को प्रॉक्सी के माध्यम से सेटअप करते समय सामान्य त्रुटियाँ और उनका समाधान

आइए उन सबसे सामान्य समस्याओं पर चर्चा करें जिनका सामना डेवलपर्स को gRPC को प्रॉक्सी के माध्यम से सेटअप करते समय करना पड़ता है, और उनके समाधान के विशिष्ट तरीके।

त्रुटि 1: "transport: received the unexpected content-type"

लक्षण:

क्लाइंट को त्रुटि मिलती है transport: received the unexpected content-type "text/html; charset=utf-8"

कारण: प्रॉक्सी ने gRPC उत्तर के बजाय त्रुटि के साथ HTML पृष्ठ लौटाया (जैसे, 502 Bad Gateway)। gRPC क्लाइंट HTML को संभाल नहीं सकता और यह त्रुटि उत्पन्न करता है।
समाधान: सुनिश्चित करें कि बैकएंड उपलब्ध है। प्रॉक्सी स्तर पर gRPC त्रुटियों को संभालने के लिए जोड़ें (जैसा कि ऊपर Nginx उदाहरण में error502grpc ब्लॉक के साथ दिखाया गया है)।

त्रुटि 2: कनेक्शन 60-120 सेकंड के बाद टूट जाता है

लक्षण:

स्ट्रीमिंग gRPC कनेक्शन अचानक UNAVAILABLE: transport is closing त्रुटि के साथ लगभग समान समयांतराल में बंद हो जाते हैं।

कारण: प्रॉक्सी टाइमआउट के कारण idle कनेक्शनों को बंद कर देता है। क्लासिक मान: AWS ELB — 60 सेकंड, Nginx डिफ़ॉल्ट रूप से — 60 सेकंड।
समाधान 1: प्रॉक्सी पर टाइमआउट बढ़ाएँ (जैसा कि ऊपर के उदाहरणों में दिखाया गया है)।
समाधान 2: gRPC क्लाइंट की ओर कीपअलाइव सेट करें: 

import "google.golang.org/grpc/keepalive"

kaParams := keepalive.ClientParameters{
    Time:                30 * time.Second, // हर 30 सेकंड में पिंग
    Timeout:             10 * time.Second, // 10 सेकंड तक उत्तर की प्रतीक्षा करें
    PermitWithoutStream: true,             // सक्रिय RPC के बिना भी पिंग करें
}

conn, err := grpc.Dial(
    "grpc-service:50051",
    grpc.WithKeepaliveParams(kaParams),
    grpc.WithTransportCredentials(creds),
)

त्रुटि 3: HTTP/2 असहमत (ALPN विफलता)

लक्षण:

त्रुटि transport: failed to dial: context deadline exceeded या no application protocol

कारण: प्रॉक्सी या मध्यवर्ती उपकरण ALPN (एप्लिकेशन-लेयर प्रोटोकॉल वार्ता) का समर्थन नहीं करता है या h2 समर्थित प्रोटोकॉल की सूची में शामिल नहीं है।
समाधान: सुनिश्चित करें कि प्रॉक्सी के TLS कॉन्फ़िगरेशन में स्पष्ट रूप से h2 प्रोटोकॉल निर्दिष्ट किया गया है: alpn h2,http/1.1 (HAProxy) या listen 443 ssl http2 (Nginx)।

त्रुटि 4: स्ट्रीमिंग अटक जाती है — डेटा नहीं आता

लक्षण:

सर्वर स्ट्रीम बैकएंड पर काम कर रहा है (लॉग में देखा जा सकता है), लेकिन क्लाइंट को स्ट्रीम समाप्त होने तक कोई संदेश नहीं मिलता।

कारण: प्रॉक्सी उत्तर को बफर करता है और इसे केवल समाप्ति के बाद क्लाइंट को भेजता है। यह समस्या उन प्रॉक्सी के लिए सामान्य है जो proxy_buffering on के साथ सेट की गई हैं।
Nginx के लिए समाधान: 

location / {
    grpc_pass grpc://backend;
    
    # gRPC स्ट्रीम के लिए बफरिंग बंद करें
    grpc_buffer_size 0;
    
    # या सामान्य proxy_pass के लिए:
    proxy_buffering off;
    proxy_cache off;
}

gRPC के माध्यम से प्रॉक्सी के लिए निदान चेकलिस्ट

✅ चेकलिस्ट: gRPC प्रॉक्सी का निदान

  • प्रॉक्सी HTTP/2 का समर्थन करता है (जांचें curl --http2 -v के माध्यम से)
  • प्रॉक्सी के TLS कॉन्फ़िगरेशन में ALPN h2 शामिल है
  • क्लाइंट और सर्वर के टाइमआउट कम से कम 300 सेकंड पर सेट हैं
  • gRPC एंडपॉइंट्स के लिए उत्तरों की बफरिंग बंद है
  • क्लाइंट पर gRPC कीपअलाइव सेट किया गया है (Time: 30s, Timeout: 10s)
  • बैकएंड की त्रुटियाँ gRPC स्थिति के रूप में लौटाई जाती हैं, न कि HTTP कोड के रूप में
  • स्वास्थ्य जांच gRPC स्वास्थ्य जांच प्रोटोकॉल का उपयोग करती है
  • लोड बैलेंसिंग L7 (HTTP/2 स्ट्रीम) पर काम करती है, न कि L4 (TCP)

निष्कर्ष

gRPC को प्रॉक्सी के माध्यम से सेटअप करना HTTP/2 और HTTP/1.1 के बीच के प्रमुख अंतरों को समझने की आवश्यकता होती है: स्ट्रीम्स का मल्टीप्लेक्सिंग, दीर्घकालिक कनेक्शन, HTTP/2 ट्रेलर्स और ALPN-सहमति। बिना विशेष सेटअप के क्लासिक HTTP प्रॉक्सी gRPC के साथ काम नहीं करते — या तो HTTP/2 का समर्थन करने वाला L7 प्रॉक्सी (Nginx 1.13.10+, Envoy, HAProxy 1.9.2+) या TCP CONNECT टनलिंग की आवश्यकता होती है।

प्रोडक्शन वातावरण के लिए Envoy की सिफारिश की जाती है — इसे विशेष रूप से माइक्रोसर्विस आर्किटेक्चर के लिए बनाया गया है, इसमें gRPC का स्वदेशी समर्थन है, यह प्रत्येक RPC विधि के लिए विस्तृत मेट्रिक्स एकत्र कर सकता है और अधिकांश सेवा मैश समाधानों का आधार है। Nginx एक अच्छा विकल्प है यदि आप पहले से ही इसे API गेटवे के रूप में उपयोग कर रहे हैं और gRPC समर्थन जोड़ना चाहते हैं बिना किसी नए घटक को शामिल किए। HAProxy उपयुक्त है यदि प्रदर्शन महत्वपूर्ण है और आप पहले से ही इसके कॉन्फ़िगरेशन से परिचित हैं।

चाहे जो भी प्रॉक्सी चुनी जाए, तीन नियम अपरिवर्तित रहते हैं: दीर्घकालिक स्ट्रीम के लिए टाइमआउट बढ़ाएँ, उत्तरों की बफरिंग बंद करें और क्लाइंट पर कीपअलाइव सेट करें। ये तीन सेटिंग्स gRPC को प्रॉक्सी के माध्यम से 80% समस्याओं को हल करती हैं।

यदि आपकी आर्किटेक्चर में gRPC सेवाओं को बाहरी नेटवर्क के माध्यम से बातचीत करनी चाहिए या आपको ट्रैफ़िक को विशिष्ट क्षेत्रों के माध्यम से रूट करने की आवश्यकता है, तो डेटा सेंटर प्रॉक्सी पर विचार करें — ये स्थिर IP पते, कम देरी और उच्च बैंडविड्थ प्रदान करते हैं, जो gRPC के लिए विशेष रूप से महत्वपूर्ण है, जो अपने बाइनरी प्रोटोकॉल और लेटेंसी के प्रति संवेदनशीलता के कारण।

```