អាទិភាពអថេរ proxy និង bypass នៅក្នុង gRPC C-Core

ការផ្លាស់ប្តូរ http_proxy អាចមិនមានប្រសិទ្ធភាព នៅពេលការកំណត់ gRPC ដែលមានអាទិភាពខ្ពស់ជាងមានរួចហើយ។ ចាប់ផ្តើមដោយកំណត់អត្តសញ្ញាណការអនុវត្ត៖ ឥរិយាបថខាងក្រោមជារបស់ mapper proxy HTTP លំនាំដើមរបស់ gRPC C-Core និងអ្នកដែលពឹងផ្អែកលើវា។

mapper ពិនិត្យអាគុយម៉ង់ proxy របស់ឆានែល បន្ទាប់មក grpc_proxy បន្ទាប់មក https_proxy បន្ទាប់មក http_proxy ហើយឈប់នៅតម្លៃដែលបានកំណត់ដំបូង។

ការស្វែងរក bypass មានលំដាប់រៀងខ្លួន៖ no_grpc_proxy មានអាទិភាពលើ no_proxy។ តម្លៃចាស់នៅទីនោះអាចពន្យល់ថាហេតុអ្វីគោលដៅមួយជៀសវាង proxy ដែលបានកំណត់ខុសពីនេះ។

mapper នេះប្រើ HTTP CONNECT។ URI proxy ដែលបានចងក្រងទុករបស់វារំពឹង scheme HTTP។ សេវា gRPC ដែលការពារដោយ TLS មិនតម្រូវដោយខ្លួនឯងនូវចំណុចបញ្ចប់ proxy ដែលការពារដោយ TLS ទេ។ ពិនិត្យការផ្ទៀងផ្ទាត់ដែលគាំទ្រដោយឡែក ជំនួសឱ្យការសន្មតថា scheme ចូលរបស់កម្មវិធីរុករកណាមួយមាន។ សម្រាប់គោលដៅ gRPC សាធារណៈដែលអនុញ្ញាតឱ្យមានអន្តរការីសាធារណៈ បញ្ជីប្រូកស៊ី HTTP ផ្តល់បេក្ខជនចំណុចបញ្ចប់សម្រាប់ URI proxy HTTP ដែលបានជ្រើស។ បញ្ជាក់ការចូលទៅដល់គោលដៅ CONNECT និងច្រកពិតប្រាកដ។

ការអនុវត្ត gRPC ជា Java Go JavaScript ឬភាសាផ្សេងទៀតអាចមានកូដដឹកជញ្ជូន និងការកំណត់ខុសគ្នា។ កុំអនុវត្តបញ្ជីអថេរ C-Core ជាច្បាប់សកលសម្រាប់អ្វីៗទាំងអស់ដែលហៅថា gRPC។

សម្រាប់ឆានែលដែលបរាជ័យ រក្សាទុក proxy ដែលបានជ្រើស ការសម្រេច bypass គោលដៅ និងដំណាក់កាលកំហុស។ HTTP API ដែលអាចទៅដល់តាមកម្មវិធីភ្ញៀវផ្សេងមិនបញ្ជាក់ថា mapper នេះប្រើការកំណត់ដូចគ្នា ឬថា proxy អនុញ្ញាតគោលដៅ CONNECT ដែលត្រូវការនោះទេ។