Порт 80 используется SYSTEM (PID 4), что это?

Я пытаюсь использовать порт 80 для моего сервера приложений, но когда я выполняю "netstat -aon", я получаю

TCP 0.0.0.0:80 0.0.0.0:0 СЛУШАТЬ 4

Когда я смотрю процесс в диспетчере задач, он показывает, что PID 4 - это СИСТЕМА, вот и все, а не расширение ... ничего, просто "СИСТЕМА". Что тут происходит?

Я боюсь закончить этот процесс, что мне делать?

Хотя люди указывают на конкретные службы (например, «Служба агента веб-развертывания»), это не помогает устранить основную причину. Если вы просто отключите сервисы, которые вызывают проблему, скорее всего, в будущем он снова встанет в тупик в несколько ином виде. Так что стоит понять, что происходит не так, потому что это приводит к лучшему решению.

Эта проблема возникает, когда серверу приложений требуется полный контроль над портом 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-адреса, который вас интересует. После того, как вы это сделали, вам не нужно беспокоиться об отключении служб, а также не нужно беспокоиться о других изменениях, вновь вызывающих проблему. Если вы убедились, что необходимая конечная точка фактически выходит за границы общего доступа к портам, то вы должны обнаружить, что системный процесс перестает привязываться к ней.

Culprit - это служба агента веб-развертывания.

Лучшее решение, чем net stop httpостановка служб с именем «Служба агента веб-развертывания».

Это скорее всего IIS 6.0 или более поздняя версия.

Стек протоколов HTTP (HTTP.sys), который работает в режиме ядра , получает клиентские запросы и направляет их в соответствующую очередь запросов. Рабочие процессы, которые выполняются в пользовательском режиме, извлекают запросы непосредственно из своих собственных очередей запросов к ядру, устраняя скачки процессов, возникающие в IIS 5.0 (а также в режиме изоляции IIS 5.0), когда веб-сервер отправляет запрос в High -изолирование, внепроцессное применение. Поскольку эти дополнительные скачки процессов исключаются в режиме изоляции рабочих процессов, IIS может обеспечить изоляцию приложений без ущерба для производительности.

Попробуйте остановить HTTP.SYS, зайдя в Device Manager/Non Plug and Play Driversи выберите HTTP, попробуйте остановить его, и вы увидите службы, которые запускают этот HTTP для использования порта 80.

Последнее, что я проверил, вы не можете завершить «системный» процесс, и если вы это сделаете, я предполагаю, что он будет иметь катастрофические последствия. Я не собираюсь пробовать это на ПК, на котором я сейчас тоже!

Казалось бы, что-то внутри самой Windows слушает: 80 - Я собираюсь догадаться, что это может быть что-то вредоносное. Лучший способ выяснить это:

а) Откройте веб-браузер для localhost и посмотрите, что произойдет

б) Запустите Telnet и telnet на localhost 80 и запустите базовый HTTP GET (например, GET /) и посмотрите, что он возвращает

B - лучший вариант, если вы считаете, что вы можете размещать вредоносное ПО, поскольку вы не хотите снова заражать себя. Хотя, возможно, это не будет иметь значения.

Я нашел ответ на этот вопрос по адресу: /superuser/352017/pid4-using-port-80.

В частности, когда это Системный процесс 4, вам необходимо отключить драйвер HTTP.sys, который запускается по требованию другой службой, такой как удаленное управление Windows или диспетчер очереди печати в Windows 7 или 2008.

1. Зайдите в диспетчер устройств, выберите «показать скрытые устройства» в меню / представлении, перейдите к «Драйвер без Plug and Play» / HTTP, дважды щелкните по нему, чтобы отключить его (или установите его вручную, некоторые службы зависят от него).

Перезагрузите компьютер и используйте netstat -nao | найдите «: 80», чтобы проверить, используется ли еще 80.

Я также попытался вернуть порт, просто запустив «net stop http», но порт никогда не возвращался обратно. Выше все работало для меня, хотя, и я не нуждался в других службах, которые зависели от этого драйвера.

Windows Sync Share - это то, что убило нас в Windows 2012 R2. Как только мы отключили эту функцию, все прошло нормально.

В моем случае это произошло из-за того, что антивирус Carbon Black каким-то образом захватил порт 80. Я потратил часы, пытаясь это выяснить, поэтому я чувствую себя обязанным поделиться на тот случай, если он выведет бедную душу на свет :) не знаете, как это было исправлено, иди спроси свой сервер / сетевая команда!

Я решил это через вопрос переполнения стека. Перейдите по этой ссылке, чтобы найти решение о том, как заставить IIS прекратить прослушивание порта 80 для указанного IP-адреса.