Kestrel vs IIS+Kestrel（反向代理） vs Nginx

Question

当我研究 .NET 核心机制的托管时，我在许多论坛和网站上看到了这样的评论：“微软建议始终在 Kestrel 前面使用任何 Web 服务器作为网站。”为什么？因为安全问题？ 我很惊讶，因为如果单独使用红隼，请求/秒的性能比 IIS+红隼更好？

Answer 1

@RickStrahl 写了这篇不错的帖子ASP.NET Core In Process Hosting on IIS with ASP.NET Core 2.2，讨论了 IIS 中的 InProcess 托管，它可用于 ASP.NET 2.2。

他还提到，为什么在 Kestrel 前面有一个 Web 服务器是件好事。

简而言之，ASP.NET 核心中内置的 Kestrel Web 服务器并不是面向 Internet 的 Web 服务器，而是充当处理非常具体的数据处理任务的应用程序服务器或边缘服务器。 Kestrel 针对应用场景进行了优化，但并未针对静态文件服务或管理服务器生命周期等其他方面进行优化

因此，您通常不希望直接在 Web 应用程序中运行 Kestrel。在带有 IIS 的 Windows 和 Linux 上都是如此，您倾向于使用 Web 服务器 nginx 或 ha-proxy 来处理非应用程序问题。我写过如何设置 IIS 重写规则来路由常见的静态文件，而不是让 Kestrel 处理它们。这不仅关乎速度，还让您的 Web 应用程序专注于做它设计的动态事情，让 IIS 完成它设计的工作。

以下是关于为什么要使用完整的 Web 服务器而不是运行直接连接到 Web 的应用程序的许多论点：

• 端口共享 Kestrel 目前不能像 IIS 和 http.sys 在 Windows 上那样做端口共享。目前仅通过 Windows 上的 IIS 支持该功能。 （AFAIK 你甚至不能使用 HttpSys 服务器来做到这一点）。此外，虽然可以在 ASP.NET Core 中使用主机头路由，但目前设置它并不容易或可维护。

• 生命周期管理 如果您在没有任何支持基础架构的情况下运行您的应用程序，任何崩溃或故障都会关闭应用程序并使您的站点脱机。无论如何，您需要某种主机监视器来确保您的应用程序在失败时继续运行，并且 IIS 提供了开箱即用的功能。带有 ASP.NET Core 模块的 ASP.NET Core 能够直接重启应用程序池，从而在出现故障时重新启动您的应用程序。

• 静态文件服务 Kestrel 目前在静态文件处理方面不是很好，与 IIS 优化的静态文件缓存和压缩基础设施相比，Kestrel 相对较慢。 IIS 充分利用了内核模式缓存，并内置了比当今的 ASP.NET StaticFile 处理程序（“.UseStaticFiles()”）更高效的压缩基础架构。

还有其他原因：安全性和服务器强化、管理功能、管理 SSL 证书、完整的日志记录和 Http 请求跟踪工具等等。使用专用 Web 服务器平台而不是运行和管理自托管服务器实例的所有充分理由。