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

Question

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

Answer 1

@RickStrahl写了这篇很好的文章ASP.NET Core In Process Hosting on IIS with ASP.NET Core 2.2，讨论了 ASP.NET 2.2 中可用的 IIS 中的 InProcess 托管。

在那里他还提到了为什么在 Kestrel 前面有一个 Web 服务器是好的。

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

出于这个原因，您通常不想直接在 Web 应用程序中运行 Kestrel。在带有 IIS 的 Windows 和 Linux 上都是如此，在 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 静态文件处理程序（“.UseStaticFiles()”）高效得多的压缩基础结构。

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