当我研究.NET核心机制的托管时，我在许多论坛和网站上看到了这一评论：“微软建议始终在Kestrel前面使用任何Web服务器作为网站。”为什么？因为安全问题？ 我很惊讶，因为如果单独使用kestrel，则每秒请求的性能要比IIS + Kestrel更好？
答案 0 :(得分：0)
@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服务器，而是充当处理非常具体的数据处理任务的应用程序服务器或Edge Server。 Kestrel已针对应用程序场景进行了优化，但并未针对诸如静态文件服务或管理服务器生命周期之类的其他事情进行优化因此，您通常不希望直接在Web应用程序中运行Kestrel。在带有IIS的Windows上以及在您倾向于使用Web服务器nginx或ha-proxy处理非应用程序问题的Linux上，都是如此。我写了关于如何设置IIS重写规则以路由普通静态文件而不是让Kestrel处理它们的文章。这不仅关系到速度，它还使您的Web应用程序能够专注于完成其设计要执行的动态工作，让IIS来完成其设计的工作。
以下是您为什么要使用完整的Web服务器而不是运行直接连接到Web的应用程序的许多争论：
端口共享 Kestrel当前无法以与IIS和http.sys在Windows上相同的方式进行端口共享。当前，仅Windows上的IIS支持该功能。 （AFAIK，您甚至不能使用HttpSys Server来执行此操作）。此外，尽管可以在ASP.NET Core中使用主机头路由，但目前设置起来并不容易或难以维护。
终身管理 如果您在没有任何支持基础结构的情况下运行应用程序，则任何崩溃或故障都将关闭该应用程序并使您的网站脱机。无论如何，您都需要某种主机监视器来确保您的应用程序在失败时仍能继续运行，而IIS提供了开箱即用的功能。带有ASP.NET Core模块的ASP.NET Core直接受益于能够重新启动应用程序池，该应用程序池可以在失败时重新启动应用程序。
静态文件服务 Kestrel目前在静态文件处理方面还不是很好，并且与IIS优化的静态文件缓存和压缩基础结构相比，Kestrel相对较慢。 IIS充分利用了内核模式缓存，并内置了压缩基础结构，该结构比当今的ASP.NET StaticFile处理程序（“ .UseStaticFiles（）”）效率更高。
还有其他原因：安全性和服务器强化，管理功能，管理SSL证书，完整的日志记录和Http Request跟踪功能，列表继续存在。所有有理由坐在专用Web服务器平台后面，而不是运行和管理自托管服务器实例。