gRPC C-Core-ലെ പ്രോക്സി, ബൈപ്പാസ് വേരിയബിൾ മുൻഗണന

ഉയർന്ന മുൻഗണനയുള്ള gRPC ക്രമീകരണം നേരത്തെ ഉണ്ടെങ്കിൽ http_proxy മാറ്റുന്നത് ഒന്നും ചെയ്തെന്നിരിക്കാം. ആദ്യം നടപ്പാക്കൽ തിരിച്ചറിയുക: താഴെപ്പറയുന്ന പെരുമാറ്റം gRPC C-Core-ന്റെ സ്വതവേയുള്ള HTTP പ്രോക്സി മാപ്പറിന്റെതും അതിനെ ആശ്രയിക്കുന്നവയുടെതുമാണ്.

മാപ്പർ ചാനൽ പ്രോക്സി ആർഗ്യുമെന്റ്, പിന്നീട് grpc_proxy, പിന്നീട് https_proxy, പിന്നീട് http_proxy എന്നിവ പരിശോധിച്ച് ആദ്യം കോൺഫിഗർ ചെയ്ത മൂല്യത്തിൽ നിൽക്കുന്നു.

ബൈപ്പാസ് കണ്ടെത്തലിന് സ്വന്തം ക്രമമുണ്ട്: no_grpc_proxy-ന് no_proxy-യേക്കാൾ മുൻഗണനയുണ്ട്. അവിടെയുള്ള പഴയ മൂല്യം ഒരു ലക്ഷ്യം മറ്റൊരു രീതിയിൽ കോൺഫിഗർ ചെയ്ത പ്രോക്സി ഒഴിവാക്കുന്നതെന്തുകൊണ്ടെന്ന് വിശദീകരിച്ചേക്കാം.

ഈ മാപ്പർ HTTP CONNECT ഉപയോഗിക്കുന്നു. അതിന്റെ രേഖപ്പെടുത്തിയ പ്രോക്സി URI HTTP സ്കീം പ്രതീക്ഷിക്കുന്നു; TLS സംരക്ഷിത gRPC സേവനത്തിന് സ്വയം TLS സംരക്ഷിത പ്രോക്സി എൻഡ്പോയിന്റ് ആവശ്യമില്ല. ഏതെങ്കിലും ബ്രൗസർ ലോഗിൻ സ്കീം ലഭ്യമാണെന്ന് കരുതുന്നതിനു പകരം പിന്തുണയ്ക്കുന്ന പ്രാമാണീകരണം വെവ്വേറെ പരിശോധിക്കുക. പൊതു ഇടനിലക്കാർ അനുവദിച്ചിട്ടുള്ള പൊതു gRPC ലക്ഷ്യത്തിന്, HTTP പ്രോക്സി പട്ടികയിൽനിന്ന് തിരഞ്ഞെടുത്ത HTTP പ്രോക്സി URI-ക്കായി എൻഡ്പോയിന്റ് സ്ഥാനാർഥികൾ നൽകുന്നു; യഥാർത്ഥ CONNECT ലക്ഷ്യത്തിലേക്കും പോർട്ടിലേക്കുമുള്ള പ്രവേശനം സ്ഥിരീകരിക്കുക.

Java, Go, JavaScript അല്ലെങ്കിൽ മറ്റൊരു ഭാഷയിലെ gRPC നടപ്പാക്കലിന് വ്യത്യസ്ത ട്രാൻസ്പോർട്ട് കോഡും കോൺഫിഗറേഷനും ഉണ്ടാകാം. gRPC എന്ന് വിളിക്കപ്പെടുന്ന എല്ലാറ്റിനും C-Core വേരിയബിൾ പട്ടിക സാർവത്രിക നിയമമായി പ്രയോഗിക്കരുത്.

പരാജയപ്പെട്ട ചാനലിന് തിരഞ്ഞെടുത്ത പ്രോക്സി, ബൈപ്പാസ് തീരുമാനം, ലക്ഷ്യം, പിശകിന്റെ ഘട്ടം എന്നിവ സൂക്ഷിക്കുക. മറ്റൊരു ക്ലയന്റിലൂടെ ലഭ്യമായ HTTP API ഈ മാപ്പർ അതേ ക്രമീകരണങ്ങൾ ഉപയോഗിച്ചു എന്നോ പ്രോക്സി ആവശ്യമായ CONNECT ലക്ഷ്യസ്ഥാനം അനുവദിക്കുന്നു എന്നോ തെളിയിക്കുന്നില്ല.