端口 80 正在被 SYSTEM（PID 4）使用，那是什么？

Question 1

尽管人们指出了具体服务（例如“Web 部署代理服务”），但这并不能解决根本原因。如果您只是禁用引发问题的服务，那么它很有可能会在将来以略有不同的形式再次出现。因此，了解问题所在是值得的，因为这可以带来更好的修复。

当应用服务器想要完全控制端口 80 时，就会出现此问题。这与 Windows 的一项功能相冲突，该功能旨在允许多个进程处理端口 80 上的请求。完全有可能有任意数量的进程都在端口 80 上接收 HTTP 请求，因为 Windows 具有内置的 HTTP 调度机制。每个进程都可以告诉 Windows 它想要处理哪些 URL。

然而，如果应用服务器完全忽略这一点，那么您将回到不太灵活的老式套接字世界，其中只有一个进程可以接收发往任何特定端口的请求。

这可能没问题 - 如果您真的不想要除特定进程处理端口 80 上的 HTTP 请求之外的任何东西，那么使用无法支持 Windows 提供的更灵活机制的应用程序服务器就变得可以容忍了。（并且一些流行的应用服务器有此限制。例如，据我所知，Tomcat 无法与其他服务器很好地协作，并且坚持将端口 80 全部独占。因此，如果您正在使用其他人的应用服务器，则使其适应首选机制可能是不切实际的。）

Windows 尝试通过不将其调度机制绑定到端口 80 来适应这种不灵活的服务，除非有主动请求。（这就是为什么您最初不一定会看到问题，但在某种更新或配置更改后可能会遇到此问题的原因。）但依靠这一点并不是一个非常可靠的解决方案 - 您基本上是相信运气，在应用服务器启动之前没有任何东西尝试在端口 80 下监听。（有各种原因可能导致进程推测性地尝试在端口 80 上注册某些 URL，如果不允许则退出。）

因此，如果您希望某项服务独占访问端口 80 的权限，最好告诉 Windows。尝试关闭所有可能尝试使用常规端口共享机制的服务其实并不够，因为很难确信您已经找到了所有服务。（特别是当 Windows 更新似乎改变了默认启用的服务时。）禁用您知道的服务可能是一种很好的做法，但最好从两端着手：禁用您不想要的服务，同时确保您不知道的服务不会让您绊倒。

默认情况下HTTP.SYS（Windows 中底层的端口共享 HTTP 调度机制）能够监听所有地址。但您可以告诉它不要这样做。此页面展示了一种实现此目的的方法：http://www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/（回溯链接：https://web.archive.org/web/20140329090533/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。一旦你这样做了，你就不必担心禁用服务，也不必担心其他更改会重新引入问题。如果你确保你需要的端点实际上超出了端口共享的范围，那么你应该会发现系统进程停止绑定到它。

Answer

尽管人们指出了具体服务（例如“Web 部署代理服务”），但这并不能解决根本原因。如果您只是禁用引发问题的服务，那么它很有可能会在将来以略有不同的形式再次出现。因此，了解问题所在是值得的，因为这可以带来更好的修复。

当应用服务器想要完全控制端口 80 时，就会出现此问题。这与 Windows 的一项功能相冲突，该功能旨在允许多个进程处理端口 80 上的请求。完全有可能有任意数量的进程都在端口 80 上接收 HTTP 请求，因为 Windows 具有内置的 HTTP 调度机制。每个进程都可以告诉 Windows 它想要处理哪些 URL。

然而，如果应用服务器完全忽略这一点，那么您将回到不太灵活的老式套接字世界，其中只有一个进程可以接收发往任何特定端口的请求。

这可能没问题 - 如果您真的不想要除特定进程处理端口 80 上的 HTTP 请求之外的任何东西，那么使用无法支持 Windows 提供的更灵活机制的应用程序服务器就变得可以容忍了。（并且一些流行的应用服务器有此限制。例如，据我所知，Tomcat 无法与其他服务器很好地协作，并且坚持将端口 80 全部独占。因此，如果您正在使用其他人的应用服务器，则使其适应首选机制可能是不切实际的。）

Windows 尝试通过不将其调度机制绑定到端口 80 来适应这种不灵活的服务，除非有主动请求。（这就是为什么您最初不一定会看到问题，但在某种更新或配置更改后可能会遇到此问题的原因。）但依靠这一点并不是一个非常可靠的解决方案 - 您基本上是相信运气，在应用服务器启动之前没有任何东西尝试在端口 80 下监听。（有各种原因可能导致进程推测性地尝试在端口 80 上注册某些 URL，如果不允许则退出。）

因此，如果您希望某项服务独占访问端口 80 的权限，最好告诉 Windows。尝试关闭所有可能尝试使用常规端口共享机制的服务其实并不够，因为很难确信您已经找到了所有服务。（特别是当 Windows 更新似乎改变了默认启用的服务时。）禁用您知道的服务可能是一种很好的做法，但最好从两端着手：禁用您不想要的服务，同时确保您不知道的服务不会让您绊倒。

默认情况下HTTP.SYS（Windows 中底层的端口共享 HTTP 调度机制）能够监听所有地址。但您可以告诉它不要这样做。此页面展示了一种实现此目的的方法：http://www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/（回溯链接：https://web.archive.org/web/20140329090533/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。一旦你这样做了，你就不必担心禁用服务，也不必担心其他更改会重新引入问题。如果你确保你需要的端点实际上超出了端口共享的范围，那么你应该会发现系统进程停止绑定到它。

Question 2

罪魁祸首是 Web 部署代理服务。

更好的解决方案net stop http是停止名为“Web 部署代理服务”的服务。

Answer

罪魁祸首是 Web 部署代理服务。

更好的解决方案net stop http是停止名为“Web 部署代理服务”的服务。

Question 3

最有可能的是IIS 6.0 或更高版本。

HTTP 协议栈 (HTTP.sys)，运行于内核模式接收客户端请求并将其路由到相应的请求队列。在用户模式下运行的工作进程直接从其自己的内核请求队列中提取请求，从而消除了在 IIS 5.0 中发生的进程跳跃（在 IIS 5.0 隔离模式下也会发生），当 Web 服务器将请求发送到高隔离、进程外应用程序时。由于在工作进程隔离模式下消除了这些额外的进程跳跃，因此 IIS 可以在不牺牲性能的情况下提供应用程序隔离。

Answer

最有可能的是IIS 6.0 或更高版本。

HTTP 协议栈 (HTTP.sys)，运行于内核模式接收客户端请求并将其路由到相应的请求队列。在用户模式下运行的工作进程直接从其自己的内核请求队列中提取请求，从而消除了在 IIS 5.0 中发生的进程跳跃（在 IIS 5.0 隔离模式下也会发生），当 Web 服务器将请求发送到高隔离、进程外应用程序时。由于在工作进程隔离模式下消除了这些额外的进程跳跃，因此 IIS 可以在不牺牲性能的情况下提供应用程序隔离。

Question 4

上次我检查时，你无法结束“系统”进程，如果你这么做，我猜这会带来灾难性的后果。我现在也不会在 PC 上尝试这个！

看起来 Windows 内部有什么东西正在监听 :80 - 我猜这可能是某种恶意程序。找出原因的最佳方法是：

a) 打开 Web 浏览器访问 localhost，查看出现的内容

b) 启动 Telnet 并远程登录到本地主机 80，然后运行一些基本的 HTTP GET（例如 GET /）并查看它返回什么

如果您认为自己可能托管了恶意软件，那么 B 是更好的选择，因为您不想再次感染自己。尽管这可能无关紧要。

Answer