ポート80はシステム（PID 4）によって使用されていますが、それは何ですか？
アプリケーションサーバーにポート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 Deployment Agent Service」という名前のサービスを停止することです。
おそらく IIS 6.0以降
カーネルモードで実行されるHTTPプロトコルスタック（HTTP.sys）は、クライアント要求を受信し、適切な要求キューにルーティングします。ユーザーモードで実行されるワーカープロセスは、独自のカーネル要求キューから直接要求をプルし、IIS 5.0（およびIIS 5.0分離モード）Webサーバーが要求を高分離のアウトプロセスアプリケーションに送信する場合、これらの余分なプロセスホップはワーカープロセス分離モードで排除されるため、IIS =パフォーマンスを犠牲にすることなくアプリケーションを分離できます。
HTTP.SYSDevice Manager/Non Plug and Play DriversおよびHTTPを選択し、停止しようとすると、このHTTPをトリガーしてポート80を使用するサービスが表示されます。
私はこの質問への答えを見つけました： https://superuser.com/questions/352017/pid4-using-port-8
具体的には、システムプロセス4の場合、Windowsリモート管理やWindows 7または2008の印刷スプーラーなどの別のサービスによってオンデマンドで開始されるHTTP.sysドライバーを無効にする必要があります。
- デバイスマネージャーに移動し、メニュー/ビューから[非表示のデバイスを表示]を選択し、[非プラグアンドプレイドライバー]/HTTPに移動し、ダブルクリックして無効にします（または手動に設定し、一部のサービスはそれに依存します）。
再起動してnetstat -naoを使用します。 「：80」を見つけて、80がまだ使用されているかどうかを確認します。
また、「net stop http」を実行するだけでポートを元に戻そうとしましたが、ポートが解放されないようでした。上記は機能しましたが、このドライバーに依存する他のサービスは必要ありませんでした。
Windows Sync Shareは、Windows 2012 R2で私たちを殺したものです。この機能を無効にすると、すべて正常に機能しました。
最後に確認したところ、「システム」プロセスを終了することはできません。終了すると、壊滅的な影響が出ると思います。今使っているPCでもやってみません！
Windows自体の内部で何かがリッスンしているようです：80-悪意のあるものである可能性があると推測します。調べる最良の方法は、次のいずれかです。
a）Webブラウザーを開いてlocalhostにアクセスし、表示される内容を確認します
b）Telnetを開始してlocalhost 80にTelnetで接続し、基本的なHTTP GET（例：GET /）を実行して、何が返されるかを確認します。
マルウェアをホストしている可能性がある場合は、Bを選択することをお勧めします。これは、自分自身に再び感染したくないためです。多分それは問題ではないでしょうが。