Umumiy .NET IWebProxy bir vaqtdagi so'rovlarda xavfsizmi?

IWebProxy proksi siyosatini tavsiflaydi. U har bir tatbiqqa bir xil bir vaqtdalik kafolatlarini bermaydi. Bitta nusxani ishchi vazifalar o'rtasida bo'lishishdan oldin uning aniq tatbiqini va tegishli ish muhitini aniqlang.

Interfeys manzilga bog'liq marshrut so'rovlari va hisob ma'lumotlarini ochib beradi. Maxsus tatbiq qat'iy manzilga, o'zgaruvchan holatga yoki avtomatik konfiguratsiyaga murojaat qilishi mumkin. Bu tanlovlar ham xavfsizlikka, ham unumdorlikka ta'sir qiladi.

Konfiguratsiya o'zgarishlarini so'rov qayta ishlashdan tashqarida saqlang

Bitta umumiy proksi obyektini qoralama sifatida ishlatishdan saqlaning: A ishi uchun uning manzili yoki hisob ma'lumotlarini o'zgartirish, B ishi marshrut tanlayotganda, egalikni noaniq qiladi. Siyosatni mijozga topshirishdan oldin sozlang. Turli proksi hisoblari yoki oxirgi nuqtalari bo'lgan ishlar uchun alohida egalikdagi mijoz konfiguratsiyalaridan foydalaning.

Tarixiy WebProxy hujjatlari nusxa a'zolari uchun oqim xavfsizligi kafolatini bermagan. Bu shartnomani tegishli tatbiqqa qo'llang. Agar sinxronlash talab qilinsa, har bir o'quvchi va yozuvchi ishtirok etishi kerak; o'rovchi qulf asl obyektdan bevosita foydalanadigan chaqiruvchilarni muvofiqlashtira olmaydi.

GetProxy dagi uzoq to'xtash o'rniga aniqlash yoki PAC baholash bilan bog'liq bo'lishi mumkin. Microsoft WinHTTP uchun bloklovchi aniqlashni hujjatlashtirgan; mijoz o'sha backenddan foydalanganda bu tushuntirish amal qiladi. Marshrut qidiruvini ulanish va javob vaqtidan alohida o'lchang. Sekin qidiruvni ketma-ketlashtirish faqat navbat hosil qilishi mumkin.

Qat'iy oxirgi nuqta qat'iy marshrut nazarda tutilganda aniqlashni olib tashlashi mumkin. O'zgaruvchan tizim siyosatidan bitta URI ni ushlash ham uning kelgusi qarorlarini tashlab yuboradi. Eski kodni saqlashda bu farqni saqlang; yangi HTTP ishi uchun HttpClient va uning qo'llab-quvvatlanadigan handler konfiguratsiyasidan foydalaning.