当我研究.NET核心机制的托管时，我在许多论坛和网站上看到了这条评论，"Microsoft建议始终使用Kestrel前面的任何Web服务器进行网站。为什么？因为安全问题？ 我很惊讶，因为如果单独使用红隼请求/秒性能优于 IIS+ 红隼？
@RickStrahl写了这篇不错的文章 ASP.NET 核心进程托管在 IIS 上使用 ASP.NET Core 2.2 讨论了 IIS 中的进程内托管，该托管可在 ASP.NET 2.2 中使用。
在那里，他还提到了，为什么在Kestrel面前有一个Web服务器是件好事。
简而言之，核心内置的 Kestrel Web 服务器 ASP.NET 并不意味着面向 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 核心模块的 ASP.NET Core 能够重新启动应用程序池，从而在发生故障时重新启动应用程序池，从而直接受益。
静态文件服务 Kestrel 目前在静态文件处理方面不是很好，与 IIS 优化的静态文件缓存和压缩基础结构相比，Kestrel 相对较慢。IIS 充分利用了内核模式缓存，并内置了比当今的 ASP.NET 静态文件处理程序 (".使用静态文件()")。
还有其他原因：安全性和服务器强化，管理功能，管理SSL证书，完整日志记录和Http请求跟踪工具等等。所有很好的理由都坐在专用的 Web 服务器平台后面，而不是运行和管理自承载的服务器实例。