Назад | Перейти на главную страницу

Как я могу регистрировать исходящие HTTP-запросы из моих веб-приложений?

Одно из наших приложений вызывает сторонний веб-сервис, который недавно был переключен на другой URI. Нам нужно исследовать это, чтобы попытаться увидеть, где используется старый адрес (код / ​​конфигурация уже были изменены на новый). Есть ли быстрый и легкий способ регистрации любых исходящих HTTP-запросов, которые делает сервер?

Это приложение ASP.Net, работающее на Windows 2008 Server с IIS 7.

Установить http://www.winpcap.org/windump/ на сервере и запустите его со следующими флагами:

windump -w "C: \ Temp \ tcpdump.log" dst-хост {старый IP-адрес} dst-порт 80

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

Обратите внимание, что я использовал только tcpdump, программу, на которой основан windump, поэтому, если между ними есть различия, вам, возможно, придется настроить флаги. Но существует множество руководств по tcpdump, которые помогут вам в правильном направлении.

wirehark! Правила !!! что представляет собой версию с графическим интерфейсом пользователя того, что Дэвид Бишоп предложил выше ^^^^^

Однако, если вы хотите более интегрированный с Windows инструмент, который также перечисляет задействованные локальные процессы, есть sysвнутренние инструменты которые бесплатны от Microsoft.

В частности TCPView можно использовать, чтобы увидеть, какой процесс подключен к какому удаленному хосту. (однако вам нужно вернуться к windump или wirehark, чтобы сопоставить соединение с URL-адресом запроса, если эта функция не была добавлена ​​недавно)

Существует также версия командной строки Tcpvcon, если вы хотите записывать все эти запросы в какой-либо файл. Но я полагаю, что это имеет те же соображения, что и запуск любого дампа пакета в файл в течение длительного периода времени: будьте осторожны, вы не заполняете свой диск и полностью разбить коробку.

К сожалению, у меня нет опыта работы с ASP.Net, но я могу предложить обходной метод, с помощью которого вы могли бы это отслеживать. Если вы запускаете Squid перед рассматриваемым сервером, довольно легко быстро просмотреть журналы Squid, чтобы определить запросы, сделанные на неправильный URI. Я бы не советовал устанавливать Squid box просто по этой причине, но, вероятно, это будет самый быстрый способ определить неправильные URI, если у вас уже есть прокси-сервер Squid.