Часто бывает так, что 80 порт по адресу 0.0.0.0 занимает приложение, имя которого определить не просто. Чаще всего таким приложением выступает какая-нибудь служба, запускающаяся автоматически во время старта системы и прослушивающая данный порт. А если 80 порт занят, тогда при установке нужных приложений, которым необходим этот порт, пользователь начнет испытывать трудности. Конечно же, в настройках можно определить другой порт для успешной работы инсталлируемого приложения, однако узнать, кто именно прослушивает и, порой, говорит по нему все же необходимо.

Первая попытка: netstat

Чтобы узнать, кто именно работает с 80 портом в windows 7, нужно открыть от имени администратора консоль командной строки. Там, понадобится ввести команду вызова утилиты netstat с ключами –aobp для протокола tcp. Так, мы сможем определить все ожидающие порты, исполняемые файлы, которые принимают участие в прослушивании сети, узнать PID исполняемых процессов и указать, что вся эта информация нас интересует в связи с tcp-протоколом.

Рис.1. Результат, выданный утилитой netstat. На 80 порту висит системное приложение, имя задачи которого определить не удается.

Как видим, в нашем случае утилита netstat не в состоянии определить имя файла, принимающего участие в создании подключения, но она в состоянии определить PID процесса, который прослушивает 80 порт. Она обнаружила, что процесс, занявший 80 порт, обслуживается системой, так как его PID = 4, поэтому убить просто данный процесс нельзя. Воспользуемся некоторыми другими методами.

Попытка номер два: спецкоманда для netstat

На просторах сети Интернет можно отыскать команду для netstat, благодаря которой также можно определить имя процесса, чтобы узнать, чем занят порт 80. Эта команда довольно длинна и она полностью приведена на изображении, представленном ниже. Также, представим результат работы этой команды, который также оказывается безрезультатным в нашем случае. Из него можно узнать только, что кто-то этот порт прослушивает, но мы об этом узнали более простым способом.

Рис.2. Результат работы спецкоманды. Как видим, вновь об имени процесса ничего не известно.

Рис.3. Еще результат работы спецкоманды.

Попробуем другой метод: http заголовки

Как известно, если кто-то открывает порт 80 для прослушивания, значит другой кто-то должен хоть когда-то в него «говорить». TCP — транспортный протокол, который используется, например, http-протоколом для передачи данных. В нашем случае необходим запуск веб-сервера apache, но 80 порт на локальном хосте занят, а поэтому, запуская службу этого веб-сервера, мы получаем ошибку, которая изображена на рисунке ниже. Эта ошибка записывается в журналы событий сервисов. Точное ее описание можно обнаружить в директории журналов Windows, в журнале приложений, если открыть консоль управления компьютером. Сервер apache не смог получить доступ к 80 порту, а поэтому он не смог создать сокет, который мог бы прослушивать сеть.

Рис.4. Попытка запустить службу Apache приводит к следующей ошибке. Более подробную информацию о ней можно получить в файле журнала событий указываемого стрелкой.

Рис.5. Первая ошибка с подробным описанием. Привязка к порту 80 невозможна.

Рис.6. Тут также сообщается, что привязка к сокету 0.0.0.0:80 невозможна.

Рис.7.  Служба закрывается, так как нет прослушиваемого сокета.

Рис.8. Это уже следствие предыдущих ошибок.

Попробуем поговорить с 80 портом, сделав http запрос на локальный хост, и попробуем получить http заголовки, в которых должна содержаться информация о сервере, что принялся прослушивать нам необходимый порт. Воспользуемся для этого небольшим плагином для firefox под названием «Live http headers». С его помощью определяем, что настоящим именем сервера, что занял порт 80 является Microsoft-HTTAPI/2.0.

Рис.9. С помощью программы просмотра http заголовков определим имя сервера, прослушивающего сокет с портом 80.

Поиск продолжается: возвращаемся к командной строке

Очевидно, что по полученным сведениям мы можем проверить библиотеку httpapi.dll, чтобы узнать, какой из процессов ею пользуется. Вновь запустим от имени администратора командную строку, из которой запустим утилиту tasklist с флагом /m для httpapi.dll. Указанный флаг позволяет узнать все задачи, которые пользуются данной библиотекой. На изображении ниже представлен результат работы утилиты. Она показывает нам задачи, которые потенциально могут использовать порт 80 — т.е. одна из них действительно использует этот порт и является причиной проблем с запуском веб-сервера apache на 80 порту. Теперь нам остается узнать, кого представляют данные задачи.

Рис.10. Результат работы утилиты tasklist.

Применяем Process Explorer

Утилита tasklist услужливо также предоставила сведения о PID задачи, уникальном идентификаторе, который присваивается каждому процессу системы Windows. Для исследования владельцев процессов воспользуемся утилитой Process Explorer Марка Руссиновича, так как она предоставляет весьма глубокую информацию о процессах системы. Возьмемся за процесс MsDepSvc. Его PID — это число 2400. Отыщем его среди запущенных процессов, которые показывает Process Explorer.

Рис.11. В Process Explorer обнаруживаем процесс MsDepServ по PID 2400. В подробной информации видим, что это задача, выполняемая службой агента развертывания веб-сервера IIS.

Утилита Руссиновича показала, что данный процесс запущен службой агента веб-развертывания, как часть родного для Windows сервера IIS. Именно этот остаток с наибольшей долей вероятности и не дает запустить apache на 80 порту. Если это не так, тогда придется определять другие задачи, высвеченные утилитой tasklist. Данная служба запускается автоматически при старте всей системы и работает с «правами» системы (SystemLocal). Чтобы определить является ли причиной наших проблем именно эта служба, ее нужно просто отключить. Поэтому наш путь лежит в консоль служб, где ее нужно обнаружить. В нашем случае остановка агента веб-развертывания освободила 80 порт, а поэтому можем считать, что поиск успешно завершен и можно свободно запускать веб-сервер apache.

Рис.12. Серди служб находим службу агента веб-развертывания. Ее нужно остановить. В нашем случае это выход из ситуации.

После остановки службы и запуска веб-сервера apache, обнаруживаем, что сокет 0.0.0.0:80 занят процессом httpd.exe, который представляет веб-сервер apache.

Рис.13. Как видим, после запуска веб-сервера apache, он нормально "прибиндился" к 80 порту.