2015-10-07 7 views
0

В настоящее время я пытаюсь автоматически восстановить HTTP-просмотр только с помощью pcap (в основном это означает соответствие HTTP-ответа на следующие HTTP-запросы). В большинстве случаев он отлично работает, но иногда в данных нескольких HTTP-ответов присутствует определенный url, u.Восстановить HTTP-просмотр из pcap

Например, если u1 и u2 содержат u в своих данных ответа, и если запрос на u происходит после запроса на u2, как я могу решить, был ли запрос u вызван u1 или u2? Обратите внимание, что между u1 и u2 не было запрошено u.

Есть ли какие-либо поля на любом сетевом уровне, которые я могу использовать для создания этого совпадения?

Спасибо!

ответ

0

HTTP работает поверх TCP, который является ориентированным на соединение. У вас есть доступ к IP-заголовку соединения, используемого для HTTP-запроса (IP-порт/IP-порт сервера -> IP-порт сервера).

HTTP - протокол команды/ответа, для каждого запроса имеется 1 ответ.

Итак, просто найдите ответ HTTP сразу после HTTP-запроса в том же TCP-соединении (IP-порт/IP-порт -> IP-порт клиента).

HTTP не имеет отношения к состоянию, соединение может быть закрыто между запросами, не влияя на общую модель просмотра (закрытие соединений является необходимым поведением в HTTP 0.9, является поведением по умолчанию в HTTP 1.0 и не является поведением по умолчанию в HTTP 1.1+), поэтому ответ HTTP может инициировать последующие запросы на новые подключения, поэтому вам нужно быть готовым к этому. Заголовок Connection в HTTP-запросе скажет вам, будет ли клиент запрашивать, чтобы соединение оставалось открытым или нет. Заголовок Connection в ответе HTTP скажет вам, действительно ли сервер закрывает соединение или нет после отправки ответа. Но даже если сервер покидает соединение открытым, это не означает, что клиент фактически повторно использует одно и то же соединение для последующих запросов на тот же сервер (хотя, вероятно, это произойдет, если между запросами не истечет таймаут).

+0

Спасибо за эти объяснения. На самом деле, я пытаюсь сопоставить ответы с запросами, а не наоборот (я использую tcptrace для разделения различных сеансов TCP). Я понимаю, что для запросов на тот же сервер, что и предыдущий ответ, клиент может использовать или не поддерживать одно и то же соединение и всегда будет запускать новое соединение для другого сервера. Это означает, что нет «сетевого» способа связывания различных HTTP-пакетов, принадлежащих различным TCP-соединениям. –

+0

Если вы разделили TCP-соединения, ответы на запросы с запросами просты, они всегда находятся на одном и том же соединении друг с другом. Начиная с ответа, найдите запрос, который непосредственно предшествует ему в том же соединении. –

+0

Попытка сопоставить связанные запросы через несколько соединений сложнее. Нет, нет окончательного идентификатора только для сети, чтобы связать их вместе. Вы можете сравнить IP-адрес клиента (порт обычно случайный) и IP-адрес сервера пакетов в пределах заданного временного интервала. Но вам, скорее всего, понадобится проанализировать фактические данные HTTP-запроса/ответа, которые ищут, например, перенаправление HTTP на новые URL-адреса, проверяя, есть ли у запросов заголовок «Referer», соответствующий URL-адресу предыдущих ответов, отслеживая поток HTTP-файлов cookie и т. Д. –