Перевірка списку проксі з обмеженою паралельністю

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);
    });

Використовуйте обмежений пул обробників, а не запускайте окреме завдання для кожної кінцевої точки. Для перевірок дозволених публічних цілей безкоштовний список проксі дає рядки-кандидати; під час побудови зонда зберігайте протокол кожного запису. Цей фрагмент планування .NET припускає ProbeAsync, який знає про проксі, і потокобезпечний збирач observations. Вісім — це ілюстративна межа, а не виміряний оптимум. Зонду все ще потрібні ліміти на спробу та скасування всього завдання.

Зберігайте кожен завершений результат разом із його входом, навіть коли порядок завершення інший. Записуйте протокол, кінцеву точку, ціль, метод, витрачений час і результат. Збій з'єднання, відмова у вході через проксі, відхилений CONNECT і отримана відповідь сайту — це різні спостереження.

Відкритий порт TCP не доводить узгодження з проксі. Отримання адреси проксі як сайту також відрізняється від її використання для запиту цілі.

Обирайте ціль і метод відповідно до потрібної можливості. HEAD може заощадити трафік тіла, але не доводить, що GET повертає корисний вміст; сайт може відхилити одне й дозволити інше. HTTPS додає CONNECT і TLS призначення, яких немає у простому HTTP. Адреса виходу — ще одне спостереження з боку призначення, окреме від налаштованого входу.

Обмежена робота не дає перевіряльнику вичерпати власні сокети, пам'ять чи планувальник до того, як він оцінить маршрут. Поетапний результат залишається корисним для політики вибору, не вдаючи, що один успішний пункт призначення робить кінцеву точку універсально хорошою.