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 இலக்கை அனுமதிக்கிறது என்பதை நிரூபிக்காது.