Я пытаюсь использовать порт 80 для своего сервера приложений, но когда я выполняю "netstat -aon", я получаю
TCP 0.0.0.0:80 0.0.0.0:0 ПРОСЛУШИВАНИЕ 4
Когда я просматриваю процесс в диспетчере задач, он показывает, что PID 4 - это SYSTEM, вот и все, а не расширение ... ничего, просто «SYSTEM». Что тут происходит?
Боюсь закончить этот процесс, что мне делать?
Хотя люди указывают на определенные службы (например, «Службу агента веб-развертывания»), это не устраняет основную причину. Если вы просто отключите службы, которые вызывают проблему, скорее всего, в будущем она снова поднимет голову в несколько другом обличье. Так что стоит понять, что идет не так, потому что это поможет лучше исправить.
Эта проблема возникает, когда серверу приложений требуется полный контроль над портом 80. Это конфликтует с функцией Windows, которая позволяет нескольким процессам обрабатывать запросы через порт 80. Вполне возможно, чтобы любое количество процессов принимало HTTP-запросы на порт. 80, потому что Windows имеет встроенный механизм отправки HTTP. Каждый процесс может сообщить Windows, какие URL-адреса он хочет обрабатывать.
Однако, если сервер приложений полностью игнорирует это, вы снова оказываетесь в менее гибком мире сокетов старой школы, где только один процесс может получать запросы, предназначенные для любого конкретного порта.
Это может быть хорошо - если вам действительно не нужно ничего, кроме определенного процесса, обрабатывающего HTTP-запрос на порт 80, становится допустимым использование сервера приложений, который не поддерживает более гибкие механизмы, предлагаемые Windows. (И некоторые популярные серверы приложений имеют это ограничение. Например, AFAIK, Tomcat не может хорошо взаимодействовать с другими и настаивает на том, чтобы порт 80 был полностью сам себе. Поэтому, если вы используете чужой сервер приложений, вполне может быть непрактично адаптировать его для использования предпочтительного механизма.)
Windows пытается приспособиться к таким негибким службам, не привязывая свой механизм отправки к порту 80 до тех пор, пока что-то не попросит об этом. (Вот почему вы не обязательно увидите проблему изначально, но можете столкнуться с этой проблемой после какого-либо обновления или изменения конфигурации.) Но полагаться на это не очень надежное решение - вы, по сути, полагаетесь на удачу, что ничего пытается прослушивать порт 80 перед запуском сервера приложений. (Существуют различные причины, по которым процесс может предположительно попытаться зарегистрироваться для определенных URL-адресов на порту 80 и отступить, если это не разрешено.)
Поэтому, если вы хотите, чтобы одна служба имела монопольный доступ к порту 80, лучше сообщите об этом Windows. На самом деле недостаточно пытаться отключить все службы, которые могут попытаться использовать обычный механизм разделения портов, потому что трудно быть уверенным, что вы нашли их все. (В частности, когда обновления Windows, кажется, меняют то, что включено по умолчанию.) Вероятно, хорошая практика - отключить те, о которых вы знаете, но лучше всего подходить к этому с обеих сторон: отключите службы, которые вам не нужны, а также убедитесь, что это не так. возможно для тех, о которых вы не знали, чтобы сбить вас с толку.
По умолчанию HTTP.SYS (базовый механизм отправки HTTP с совместным использованием порта в Windows) может прослушивать все адреса. Но вы можете сказать ему этого не делать. На этой странице показан один из способов сделать это: http://www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/
Это относительно легкий способ сделать это, потому что он по-прежнему позволяет прослушивать локальный хост для IPv6. Он просто освобождает порт 80 IPv4. Вы можете пойти дальше с более специализированной конфигурацией. (Вы даже можете отключить HTTP.SYS полностью, но это может сломать работу с использованием портов, отличных от 80, поэтому это может вызвать проблемы.)
Но что бы вы ни делали, главное - чтобы HTTP.SYS не пытается прослушивать порт 80 на интересующем вас IP-адресе. После того, как вы это сделаете, вам не нужно беспокоиться об отключении служб, и вам не нужно беспокоиться о других изменениях, которые повторно вводят проблему. Если вы убедились, что нужная вам конечная точка фактически находится за пределами границ для совместного использования порта, то вы должны обнаружить, что системный процесс перестает связываться с ней.
Виновником была служба агента веб-развертывания.
Лучшее решение, чем net stop http заключается в том, чтобы остановить службы с именем «Служба агента веб-развертывания».
Скорее всего IIS 6.0 или новее.
Стек протокола HTTP (HTTP.sys), который работает в режим ядра, принимает клиентские запросы и направляет их в соответствующую очередь запросов. Рабочие процессы, которые выполняются в пользовательском режиме, извлекают запросы непосредственно из своих очередей запросов ядра, устраняя переходы процессов, которые происходят в IIS 5.0 (и которые также происходят в режиме изоляции IIS 5.0), когда веб-сервер отправляет запрос на высокий уровень. -изоляция, внепроцессное применение. Поскольку эти дополнительные переходы процесса исключаются в режиме изоляции рабочих процессов, IIS может обеспечить изоляцию приложений без ущерба для производительности.
Попытайтесь остановить HTTP.SYS войдя в Device Manager/Non Plug and Play Drivers и выберите HTTP, попробуйте остановить его, и вы увидите, что службы, запускающие этот HTTP, используют порт 80.
Последний раз я проверил, что вы не можете завершить "системный" процесс, и если вы это сделаете, я предполагаю, что это будет иметь катастрофические последствия. Я тоже не собираюсь пробовать это на ПК, который сейчас использую!
Казалось бы, что-то внутри самой Windows подслушивает: 80 - Я предполагаю, что это может быть что-то вредоносное. Лучший способ узнать это:
а) Откройте веб-браузер на localhost и посмотрите, что произойдет.
б) Запустите Telnet и telnet на localhost 80 и запустите базовый HTTP GET (например, GET /) и посмотрите, что он вернет.
B - лучший вариант, если вы думаете, что можете размещать вредоносное ПО, поскольку на самом деле вы не хотите снова заразить себя. Хотя, может, и не беда.
Я нашел ответ на этот вопрос по адресу: https://superuser.com/questions/352017/pid4-using-port-80
В частности, если это системный процесс 4, вам необходимо отключить драйвер HTTP.sys, который запускается по запросу другой службой, такой как удаленное управление Windows или диспетчер очереди печати в Windows 7 или 2008.
Перезагрузитесь и используйте netstat -nao | найдите «: 80 ″, чтобы проверить, используется ли еще 80.
Я также попытался вернуть порт, просто запустив "net stop http", но порт, похоже, так и не освободился. Однако все вышеперечисленное сработало для меня, и мне не понадобились другие службы, которые зависели от этого драйвера.
Windows Sync Share - это то, что нас убило в Windows 2012 R2. Как только мы отключили эту функцию, все стало нормально.
В моем случае это произошло из-за того, что антивирус Carbon Black каким-то образом захватил порт 80. Я потратил часы, пытаясь понять это, поэтому чувствую себя обязанным поделиться на всякий случай, если это приведет к свету беднягу :) Не знаю, как именно это было исправлено, спросите свою команду сервера / сети!
Я решил это с помощью вопроса о переполнении стека. Перейдите по этой ссылке чтобы найти решение, как заставить IIS прекратить прослушивание порта 80 для указанного IP-адреса.