gRPC C-Core ရှိ ပရောက်စီနှင့် ရှောင်ကွင်းကိန်းရှင် ဦးစားပေး

ပိုမြင့်သော ဦးစားပေးရှိ gRPC ဆက်တင် ရှိပြီးဖြစ်ပါက http_proxy ကို ပြောင်းလဲခြင်းက ဘာမှ မဖြစ်စေနိုင်ပါ။ အကောင်အထည်ဖော်မှုကို ဦးစွာ ဖော်ထုတ်ပါ။ အောက်ပါ အပြုအမူသည် gRPC C-Core ၏ မူရင်း HTTP ပရောက်စီ mapper နှင့် ၎င်းအပေါ် မှီခိုသူများ၏ အပြုအမူ ဖြစ်သည်။

mapper သည် channel ပရောက်စီ အငြင်းအခုံ၊ ထို့နောက် grpc_proxy၊ ထို့နောက် https_proxy၊ ထို့နောက် http_proxy ကို စစ်ဆေးပြီး ပထမဆုံး သတ်မှတ်ထားသော တန်ဖိုးတွင် ရပ်တန့်သည်။

ရှောင်ကွင်း ရှာဖွေမှုတွင် ကိုယ်ပိုင် အစီအစဉ် ရှိသည်။ no_grpc_proxy သည် no_proxy ထက် ဦးစားပေးသည်။ ထိုနေရာရှိ ဟောင်းနေသော တန်ဖိုးက ပစ်မှတ်တစ်ခုက အခြားနည်းဖြင့် သတ်မှတ်ထားသော ပရောက်စီကို အဘယ်ကြောင့် ရှောင်နေသည်ကို ရှင်းပြနိုင်သည်။

ဤ mapper သည် HTTP CONNECT ကို အသုံးပြုသည်။ ၎င်း၏ မှတ်တမ်းတင်ထားသော ပရောက်စီ URI သည် HTTP scheme ကို မျှော်လင့်သည်။ TLS ဖြင့် ကာကွယ်ထားသော gRPC ဝန်ဆောင်မှုသည် သူ့အလိုလို TLS ဖြင့် ကာကွယ်ထားသော ပရောက်စီ အဆုံးမှတ် မလိုအပ်ပါ။ မည်သည့် ဘရောက်ဇာ အကောင့်ဝင်ရောက်မှု scheme မဆို ရနိုင်သည်ဟု မယူဆဘဲ ပံ့ပိုးထားသော အထောက်အထား စစ်ဆေးမှုကို သီးခြား စစ်ဆေးပါ။ အများသူငှာ ကြားခံများကို ခွင့်ပြုသော အများသူငှာ gRPC ပစ်မှတ်အတွက် HTTP proxy စာရင်းမှ ရွေးချယ်ထားသော HTTP ပရောက်စီ URI အတွက် အဆုံးမှတ် ကိုယ်စားလှယ်လောင်းများကို ပေးသည်။ အမှန်တကယ် CONNECT ပစ်မှတ်နှင့် ပေါက်သို့ ရောက်ရှိမှုကို အတည်ပြုပါ။

Java၊ Go၊ JavaScript သို့မဟုတ် အခြား ဘာသာစကားဖြင့် gRPC အကောင်အထည်ဖော်မှုသည် မတူညီသော သယ်ယူပို့ဆောင်ရေး ကုဒ်နှင့် ဖွဲ့စည်းမှု ရှိနိုင်သည်။ gRPC ဟု ခေါ်သော အရာအားလုံးအတွက် C-Core ကိန်းရှင် စာရင်းကို ယေဘုယျ စည်းမျဉ်းအဖြစ် မသုံးပါနှင့်။

မအောင်မြင်သော channel အတွက် ရွေးချယ်ထားသော ပရောက်စီ၊ ရှောင်ကွင်း ဆုံးဖြတ်ချက်၊ ပစ်မှတ်နှင့် အမှား အဆင့်ကို သိမ်းဆည်းပါ။ အခြား client မှတစ်ဆင့် ရောက်ရှိနိုင်သော HTTP API သည် ဤ mapper က တူညီသော ဆက်တင်များ သုံးခဲ့သည်ကို သော်လည်းကောင်း ပရောက်စီက လိုအပ်သော CONNECT ဦးတည်ရာကို ခွင့်ပြုသည်ကို သော်လည်းကောင်း သက်သေမပြပါ။