gRPC C-Core дахь прокси болон тойрч гарах хувьсагчдын давуу эрх
Өөр gRPC хэрэгжүүлэлт ижил mapper ашигладаг гэж үзэхгүйгээр gRPC Core-ын прокси болон тойрч гарах давуу эрхийг дагана уу.
Илүү өндөр давуу эрхтэй gRPC тохиргоо аль хэдийн байгаа бол http_proxy-г өөрчлөх нь юу ч хийхгүй байж болно. Эхлээд хэрэгжүүлэлтийг тодорхойлно уу: дараах зан төлөв нь gRPC C-Core-ын анхдагч HTTP прокси mapper болон түүнээс хамааралтай хэсгүүдэд хамаарна.
Mapper нь сувгийн прокси аргумент, дараа нь grpc_proxy, дараа нь https_proxy, дараа нь http_proxy-г шалгаад эхний тохируулсан утга дээр зогсоно.
Тойрч гарахыг илрүүлэх өөрийн дараалалтай: no_grpc_proxy нь no_proxy-оос давуу. Тэнд байгаа хуучин утга нь нэг зорилт яагаад өөрөөр тохируулсан проксигоос зайлсхийж байгааг тайлбарлаж болно.
Энэ mapper нь HTTP CONNECT ашигладаг. Түүний баримтжуулсан прокси URI нь HTTP схем хүлээдэг; TLS-ээр хамгаалагдсан gRPC үйлчилгээ нь өөрөө TLS-ээр хамгаалагдсан прокси төгсгөлийн цэг шаарддаггүй. Хөтчийн ямар ч нэвтрэх схем байгаа гэж үзэхийн оронд дэмжигдсэн баталгаажуулалтыг тусад нь шалгана уу. Нийтийн зуучлагчдыг зөвшөөрдөг нийтийн gRPC зорилтын хувьд HTTP проксийн жагсаалтаас сонгосон HTTP прокси URI-д төгсгөлийн цэгийн нэр дэвшигчдийг санал болгодог; бодит CONNECT зорилт болон портод хүрэх боломжийг баталгаажуулна уу.
Java, Go, JavaScript эсвэл өөр хэл дээрх gRPC хэрэгжүүлэлт нь өөр тээврийн код, тохиргоотой байж болно. C-Core хувьсагчийн жагсаалтыг gRPC гэж нэрлэгддэг бүх зүйлд бүх нийтийн дүрэм болгон бүү хэрэглэ.
Амжилтгүй болсон сувгийн хувьд сонгосон прокси, тойрч гарах шийдвэр, зорилт, алдааны үе шатыг хадгална уу. Өөр клиентээр дамжуулан хүрч болох HTTP API нь энэ mapper ижил тохиргоо ашигласан эсвэл прокси шаардлагатай CONNECT очих газрыг зөвшөөрч байгааг нотлохгүй.