Как прочитать первые N байт HTTP HEAD запроса с использованием Proxy? Быстрая проверка на 404 error

[Lord_Alfred]

Быть может, кто-то уже реализовывал похожий функционал для задачи быстрой проверки на 404 ошибку огромного списка URL'ов?

По сути, нужно только получить первые 11-14 байт от сервера и закрыть соединение (этого должно быть достаточно чтоб получить первую строку с кодом ответа). Получать целиком весь HEAD - нет особого смысла, т.к. ссылок много и нужно лишь узнать: 404 / 200 или любой другой код отдал сервер на наш запрос.

Начал сам пытаться реализовать это через `HttpWebRequest` в C#, но т.к. я с ним не работал и всегда предпочитал "синтаксический сахар" от ZennoLab (`ZennoPoster.HttpGet`), то сейчас "прикурил" от того, что не могу вместе реализовать:
- HTTP HEAD запрос
- установка своего User-Agent
- передача произвольного header в запросе
- использование proxy (лучше socks5)
- ответ может быть в gzip / deflate / Brotli (br)
- TSL 1.2 (вроде бы именно его не умеет ZP через свой кубик Http Get, если не путаю)
- чтение только N байт ответа сервера

Буду очень благодарен, если у кого-то в закромах есть C# код, который поможет решить эту задачу, а то я уже немного устал собирать это по частям из гугла Уже даже кажется, что нужно использовать что-то другое, а не `HttpWebRequest`.



PS: в C# не тестировал на сколько быстро читать первые N байт ответа, а не весь header целиком. Но помню, что то ли в php, то ли в python такой подход несколько лет назад уменьшил мне длительность парсинга в пару раз.

PPS: если кто-то ещё покажет дополнительно как лучше распараллелить такую задачу, то будет вообще здорово. Явно это кому-то в будущем поможет Мне в голову приходит только `Parallel.For`/`Parallel.ForEach`, но скорее всего это не очень корректно в данном конкретном случае.

 

[7make]

win 10?
там же на 10 завезли OpenSSH + curl
CMD > curl

первые 15 байт документа
curl -r 0-15 http://google.com

первые 15 байт хедера
curl -r 0-15 --head http://google.com

 

[Lord_Alfred]

win server 2016 )

Юзать curl не сподручно, я подозреваю по скорости его запуска - не будет прибавки в производительности, а здесь вся идея в том, что нужно получить первые N байт чтоб быстрее огромный список урлов обработать в C#.
Ну и плюс, почему-то в скрине у тебя -r не отработал. Там не 0-15 вывело, а целиком весь body и header.

 

[7make]

ну если просто статус код то
https://docs.microsoft.com/en-us/dotnet/api/system.net.httpwebresponse.statuscode?view=netframework-4.7.2

var req = (HttpWebRequest)WebRequest.Create("http://google.com");
var res = (HttpWebResponse)req.GetResponse();

return (int)res.StatusCode;

но это один фиг не то что ты хочешь ибо тут весь обьект тянет
это через стрим тянуть нужно первые байты в буфер

upd:хедеры прилетают одним пакетом в стандартных классах дотнета. так что стримом их не прочитать частично, разве что контент стримом можно побайтово читать

upd2:
Это копать в сторону интерфейсов нужно, и/или пилить свою имплиментацию чтобы хедеры дергать побайтово
IHttpParser

 

[Lord_Alfred]

upd:хедеры прилетают одним пакетом в стандартных классах дотнета. так что стримом их не прочитать частично, разве что контент стримом можно побайтово читать

upd2:
Это копать в сторону интерфейсов нужно, и/или пилить свою имплиментацию чтобы хедеры дергать побайтово
IHttpParser

Вот это сюрприз, конечно Я такое, к сожалению, точно не осилю. Придется, пожалуй, первую итерацию шаблона пилить с получением всего хедера, может через неделю и выпаршу всё что нужно

 

[7make]

Вот это сюрприз, конечно Я такое, к сожалению, точно не осилю. Придется, пожалуй, первую итерацию шаблона пилить с получением всего хедера, может через неделю и выпаршу всё что нужно

ну если ты готов жертвовать тем что получишь весь херед в память, то HttpWebRequest самое то для тебя за исключением сокс5 из каропки.

 

[Lord_Alfred]

ну если ты готов жертвовать тем что получишь весь херед в память, то HttpWebRequest самое то для тебя за исключением сокс5 из каропки.

Тут больше трабл не в памяти будет, а в скорости, т.к. весь хеадер получить, допустим, 0.05 сек, а если бы только первые символы - то 0.03 сек (условно говоря), но ссылок больше 1кк, поэтому такой speed up очень был бы кстати.

И, да, без проксей - точно никак. Я ж удолблю сайты запросами и в баньку много где улечу автоматом(

 

[7make]

уточню тогда, ибо не понял момент.
тебе чекнуть 100500 доменов нужно или в рамках хоста 100500 страниц?
если первое, тебе не нужны прокси ибо по 1 запросу на хост делаешь
если в рамках хоста страницы чекать, то нужны

*вебреквест могет хттп прокси, не могет соксы только

вот примерчики тебе

https://weblog.west-wind.com/posts/2014/Jan/29/Using-NET-HttpClient-to-capture-partial-Responses

* можно дергать частично хедеры, но если сервак настроен на такую отдачу, и обычно это если статика.

https://docs.microsoft.com/ru-ru/dotnet/api/system.net.httpwebrequest.addrange?view=netframework-4.7.2

https://docs.microsoft.com/ru-ru/dotnet/framework/network-programming/how-to-request-data-using-the-webrequest-class

 

[Lord_Alfred]

уточню тогда, ибо не понял момент.
тебе чекнуть 100500 доменов нужно или в рамках хоста 100500 страниц?
если первое, тебе не нужны прокси ибо по 1 запросу на хост делаешь
если в рамках хоста страницы чекать, то нужны

как раз таки сейчас нужно на 3-4 хостах почекать кучу урлов

*вебреквест могет хттп прокси, не могет соксы только

а, ну это уже лучше, конечно. Не всё настолько печально как я подумал

 

[Hartwell]

На баше
Да_этоЖ_гитхуб

С xargs -P100 прогуливается по 450.000 url минут за 7-10

Есть на dotnet оно-же, пошустрее. Если надо залью на gh

З.ы. однако пару моментов по сабжу:
В tcp соединениях данные отправляются пакетами (группой), а не байтами/килобайтами. После такой отправки клиент ожидает от сервера статус получения + делается сверка чек сумм (tcp же у нас 100% гарантирует целостность данных).
Клацк на библию

Отсюда еще выплывает момент с тем что latency будет дико сказывается на пропускной способности канала. Отправить 100мб с задержкой в 100мс займет в 10 раз дольше чем с задержкой 4мс. Из-за сверки целостности с ожиданием ответа от сервера. Иначе говоря сколько бы не было гигабит, оно стремительно уменьшается при наличии задержек, а пропускная способность у нас ни что иное как доставка Х данных за Y времени в Z назначение. Ну это так к слову.

Другой момент, если задача была опросить доступность, то явно быстрее это сделать via dns. Ну а если специфика требовала получение каких то данных, то мб смысл в лимите первых данных и есть, а мб и нету Сугубо от таски, исключительно от специфики таски... наврятли иначе

Ловлю кирпичи (дом буду строить), если я не прав. но кидайте если что - ловлю