Kontrollér en proxy-liste med begrænset parallelitet

Begræns parallelle proxykontroller, og registrér hvad hver kontrol faktisk fastslog for målwebstedet.

var options = new ParallelOptions
{
    MaxDegreeOfParallelism = 8,
    CancellationToken = cancellationToken
};
await Parallel.ForEachAsync(endpoints, options,
    async (endpoint, token) =>
    {
        var result = await ProbeAsync(endpoint, target, token);
        observations.Add(result);
    });

Brug en begrænset arbejdspulje i stedet for at starte en opgave for hvert endepunkt. Til kontroller mod tilladte offentlige mål leverer den gratis proxy-liste kandidatrækker; bevar hver posts protokol, når sonden bygges. Dette .NET-planlægningsuddrag forudsætter en proxybevidst ProbeAsync og en trådsikker observations-opsamler. Otte er en illustrativ grænse, ikke et målt optimum. Sonden har stadig brug for grænser pr. forsøg og annullering af hele opgaven.

Gem hvert afsluttet resultat sammen med dets input, selv når færdiggørelsesrækkefølgen er anderledes. Registrér protokol, endepunkt, mål, metode, forløbet tid og udfald. Forbindelsesfejl, afvist proxy-login, afvist CONNECT og et modtaget svar fra webstedet er forskellige observationer.

En åben TCP-port beviser ikke proxy-forhandling. At hente proxyadressen som et websted er også noget andet end at bruge den til at anmode om målet.

Vælg mål og metode efter den krævede egenskab. HEAD kan spare kropstrafik, men beviser ikke, at GET returnerer brugbart indhold; et websted kan afvise det ene og tillade det andet. HTTPS tilføjer CONNECT og destinations-TLS, som mangler i almindelig HTTP. En udgangsadresse er en anden observation på destinationssiden, adskilt fra den konfigurerede indgang.

Begrænset arbejde forhindrer kontrolløren i at udtømme sine egne sockets, hukommelse eller planlægger, før den kan vurdere ruten. Et trinvis resultat forbliver nyttigt for udvælgelsespolitikken uden at foregive, at ét vellykket mål gør et endepunkt universelt godt.

Relaterede artikler