Pull to refresh

Comments 10

Ничего себе, keep-alive позволяет отправлять несколько запросов в рамках одного соединения. Довольно нестандартное применение, да.
У меня тоже было такое же впечатление от статьи. Но потом я дочитал внимательнее до конца и понял, что автор под нестандартным применением имел ввиду «усиление» задержки, так как запросы keep-alive выполняются последовательно.
То есть, как можно понять, что сервер потратил времени на 2 мс больше? При одном запросе высока ошибка, а если таких запросов несколько сотен, то и задержка будет более заметна. Для pentest'ов вполне неплохой вариант.
По честному, нужно было провести небольшой сравнительный анализ сканеров и выложить табличку, где указать какой сканер какую версию http использует и кто до сих пор не умеет использовать keep-alive. Тогда сразу можно будет видеть, действительно ли это столь насущная проблема. По поводу брута логина для basic авторизации тоже не совсем понял, вот пример со сферического сервера в вакууме:
For abc = 0.00200009346008 sec
For test = 0.0019998550415 sec
For adm = 0.00100016593933 sec
For root = 0.0019998550415 sec
For zzzzz = 0.00200009346008 sec
For user = 0.00100016593933 sec
For epic = 0.000999927520752 sec
For fail = 0.0019998550415 sec
For ping = 0.00100016593933 sec
For latency = 0.000999927520752 sec

Среди этих логинов один правильный, какой? (Server: Apache/2.4.4 (Win64) PHP/5.4.12)
Стоит также отметить, что механизмы установки соединений в различных языках выдают неожиданно разные результаты для разных серверов — к примеру, сокеты Python оказались неспособны нормально пробрутить Apache httpd версии 2.4, однако замечательно работают на ветке 2.2

Прям магия какая то. Какой же клиент использовать для апача 2.4.4?
У меня успешно отрабатывает. Разница, правда, не как у автора (+2сек), но отчетливо видно повышенное время отклика, особенно если раз 5 подряд запустить.

For abc = 0.180999994278 sec
For test = 0.226999998093 sec
For adm = 0.203000068665 sec
For root = 0.486000061035 sec
For bob = 0.193000078201 sec
For kok = 0.204999923706 sec
Не очень понял следующую ситуацию: допустимо ли фигачить в одном соединении несколько реквестов, а потом получить пачку респонзов. И не снесёт ли башню серверу от такой логики?
Это называется pipelinening, для HTTP 1.1 такое поведение предусмотрено стандартом.
Ок. понял, что есть в стандарте. Но используется ли она фактически? Просто вижу кучу проблем с этим: обрыв соединения сразу рушит все запросы, а дальше или забивать на проблемные соединения, или реализовывать логику по повторному докидыванию соединений. Или если один запрос длинный, все остальные встают в очередь и курят. На сервере необходимо реализовывать сложную логику по поддержке таких хитрых соединений с сильным взаимодействием между сервером и обработчиком.
Чаще всего не используется. В Firefox, например, это нужно включать в about:config отдельно, см. network.http.pipelining.
На сервере ничего сложного в обработке таких запросов нет.
Sign up to leave a comment.