アプリケーションサーバーにポート80を使用しようとしていますが、「netstat -aon」を実行すると
TCP 0.0.0.0:80 0.0.0.0:0リスニング4
タスクマネージャーでプロセスを調べると、PID 4がSYSTEMであることがわかります。つまり、拡張子ではなく、「SYSTEM」だけです。何が起きてる？
このプロセスを終了するのが怖いのですが、どうすればよいですか？
回答:
人々は特定のサービス（「Web配置エージェントサービス」など）を指摘していますが、これは根本的な原因に対処できません。問題を引き起こすサービスを無効にするだけの場合、将来的には少し異なる見方をして、再び頭をもたげる可能性があります。したがって、何が問題になっているのかを理解することは価値があります。
この問題は、アプリケーションサーバーがポート80を完全に制御する必要がある場合に発生します。これは、複数のプロセスがポート80で要求を処理できるように設計されたWindowsの機能と競合します。ポートでHTTP要求を受信するプロセスをいくつでも持つことは完全に可能です。 80。WindowsにはHTTPディスパッチメカニズムが組み込まれているためです。各プロセスは、処理するURLをWindowsに通知できます。
ただし、アプリケーションサーバーがこれを完全に無視すると、特定のポート宛ての要求を1つのプロセスしか受信できない、柔軟性の低い旧式のソケットの世界に戻ります。
ポート80でHTTPリクエストを処理する特定のプロセス以外が本当に必要ない場合は、Windowsが提供するより柔軟なメカニズムをサポートできないアプリケーションサーバーを使用することが許容できるようになります。（そして、一部の一般的なアプリサーバーにはこの制限があります。たとえば、AFAIK、Tomcatは他のアプリサーバーとうまく機能できず、ポート80をすべてそれ自体に使用することを要求します。したがって、他の誰かのアプリサーバーを使用している場合、優先メカニズムを使用するようにそれを適合させてください。）
Windowsは、何かを積極的に要求するまで、ディスパッチメカニズムをポート80にバインドしないことで、このような柔軟性のないサービスに対応しようとします。（これが必ずしも最初に問題が発生するとは限らないが、何らかの更新または構成の変更後にこの問題に遭遇する可能性がある理由です。）しかし、これに依存することは非常に確固たる解決策ではありません。アプリサーバーが起動する前に、ポート80でリッスンしようとします。（プロセスが投機的にポート80で特定のURLに登録を試み、許可されていない場合はバックオフするさまざまな理由があります。）
したがって、1つのサービスにポート80への排他的アクセスを許可する場合は、Windowsに通知することをお勧めします。通常のポート共有メカニズムを使用しようとする可能性のあるすべてのサービスをオフにしようとするだけでは十分ではありません。すべてのサービスを見つけたと確信するのは難しいためです。（特にWindowsの更新により、デフォルトでオンになっているものが変更されるように思われる場合。）知っているサービスを無効にすることはおそらく良い習慣ですが、両端からアプローチすることをお勧めします。知らない人がつまずく可能性があります。
デフォルトではHTTP.SYS（Windowsの基になるポート共有HTTPディスパッチメカニズム）は、すべてのアドレスをリッスンできます。しかし、そうではないと言うことができます。このページは、そのための1つの方法を示しています。http：//www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/
これは、IPv6のローカルホストでの待機を可能にするため、比較的簡単な方法です。IPv4ポート80を解放するだけです。より特化した構成を使用して、それをさらに進めることができます。（HTTP.SYS完全に無効にすることもできますが、80以外のポートを使用すると問題が発生する可能性があるため、問題が発生する可能性があります。）
しかし、何をするにしても、重要なのは、それが、HTTP.SYS気になるIPアドレスのポート80をリッスンしないようにすることです。それが完了したら、サービスを無効にすることを心配する必要はありません。また、問題を再導入する他の変更について心配する必要もありません。必要なエンドポイントが実質的にポート共有の範囲外であることを確認した場合は、システムプロセスがそのエンドポイントへのバインドを停止していることがわかります。
犯人はWeb配置エージェントサービスでした。
net stop http「Web展開エージェントサービス」という名前のサービスを停止するよりも優れたソリューションです。
World Wide Web Publishing Serviceです。「net stop http」自体は厄介な副作用に満ちた非常に残忍な答えですが、印刷スプーラーやWindows 10のログインプロセスの一部などのサービスはhttpに依存しています-試した場合の動作は、 httpに依存するサービス、およびバックアウトするオプション。リストにある少数のサービスを1つずつ試してみると、WWW Publishing Serviceが原因であることがわかりました。
ほとんどの場合、IIS 6.0以降です。
カーネルモードで実行されるHTTPプロトコルスタック（HTTP.sys）は、クライアント要求を受け取り、適切な要求キューにルーティングします。ユーザーモードで実行されるワーカープロセスは、独自のカーネル要求キューから直接要求をプルし、Webサーバーが要求をHighに送信するときにIIS 5.0で発生する（およびIIS 5.0分離モードでも発生する）プロセスホップを排除します。 -分離、アウトプロセスアプリケーション。これらの余分なプロセスホップはワーカープロセス分離モードで排除されるため、IISはパフォーマンスを犠牲にすることなくアプリケーションの分離を提供できます。
最後に確認したところ、「システム」プロセスを終了することはできません。終了すると、壊滅的な影響が出ると思います。今使っているPCでもやってみません！
Windows自体の内部で何かが：80をリッスンしているように思われます-悪意のあるものである可能性があると思います。調べる最良の方法は、次のいずれかです。
a）Webブラウザーを開いてlocalhostにアクセスし、表示される内容を確認します
b）Telnetを開始してlocalhost 80にTelnetで接続し、基本的なHTTP GET（例：GET /）を実行して、何が返されるかを確認します。
マルウェアにホスティングしている可能性があると思われる場合は、Bを選択することをお勧めします。多分それは問題ではないでしょうが。
私はこの質問への答えを見つけました：https : //superuser.com/questions/352017/pid4-using-port-80
具体的には、システムプロセス4の場合、Windowsリモート管理やWindows 7または2008の印刷スプーラーなどの別のサービスによってオンデマンドで開始されるHTTP.sysドライバーを無効にする必要があります。
再起動してnetstat -naoを使用します。「：80」を見つけて、80がまだ使用されているかどうかを確認します。
また、「net stop http」を実行するだけでポートを元に戻そうとしましたが、ポートが解放されないようでした。上記は私にとってもうまくいきました、そしてIIはこのドライバーに依存する他のサービスを必要としませんでした。
私の場合、それはカーボンブラックのアンチウイルスがどういうわけかポート80で首を絞めているためでした。私はそれを理解しようと何時間も費やしたので、それが仲間の貧しい魂を光に導く場合に備えて共有する義務を感じます:)私はしませんそれがどのように正確に修正されたのかわからない場合は、サーバー/ネットワークチームにお問い合わせください！
私はこれをスタックオーバーフローの質問で解決しました。 このリンクに従って、 IISが指定されたIPアドレスのポート80でのリッスンを停止する方法の解決策を見つけてください。