Vai kopīgs .NET IWebProxy ir drošs vienlaicīgu pieprasījumu laikā?
Atšķiriet IWebProxy ieviešanas vienlaicīguma līgumu no kavējumiem, ko izraisa automātiska starpniekservera noteikšana.
IWebProxy apraksta starpniekservera politiku. Tas nenodrošina visām ieviešanām vienādas vienlaicīguma garantijas. Pirms vienas instances kopīgošanas starp darbinieku uzdevumiem nosakiet tās konkrēto ieviešanu un izpildes vidi, kurai tā pieder.
Saskarne atklāj no galamērķa atkarīgus maršruta vaicājumus un akreditācijas datus. Pielāgota ieviešana var konsultēt fiksētu adresi, mainīgu stāvokli vai automātisku konfigurāciju. Šīs izvēles ietekmē gan drošību, gan veiktspēju.
Turiet konfigurācijas izmaiņas ārpus pieprasījumu apstrādes
Izvairieties no viena kopīga starpniekservera objekta izmantošanas kā melnraksta: tā adreses vai akreditācijas datu maiņa uzdevumam A, kamēr uzdevums B izvēlas maršrutu, padara īpašumtiesības neskaidras. Konfigurējiet politiku pirms tās nodošanas klientam. Darbiem ar atšķirīgiem starpniekservera kontiem vai galapunktiem izmantojiet atsevišķi pārvaldītas klienta konfigurācijas.
Vēsturiskā WebProxy dokumentācija nesniedza pavedienu drošības garantiju instances dalībniekiem. Piemērojiet šo līgumu attiecīgajai ieviešanai. Ja nepieciešama sinhronizācija, jāpiedalās katram lasītājam un rakstītājam; ietvara bloķēšana nevar koordinēt izsaucējus, kas tieši izmanto sākotnējo objektu.
Ilga pauze GetProxy laikā var būt saistīta ar noteikšanu vai PAC novērtēšanu. Microsoft dokumentē bloķējošu noteikšanu WinHTTP; šis skaidrojums attiecas, ja klients izmanto šo aizmuguri. Mēriet maršruta meklēšanu atsevišķi no savienojuma un atbildes laika. Lēnas meklēšanas serializēšana var vienkārši radīt rindu.
Fiksēts galapunkts var novērst noteikšanu, ja ir paredzēts fiksēts maršruts. Viena URI tveršana mainīgā sistēmas politikā arī atmet tās turpmākos lēmumus. Saglabājiet šo atšķirību, uzturot veco kodu; jaunam HTTP darbam izmantojiet HttpClient un tā atbalstīto apdarinātāja konfigurāciju.