问Kestrel诉IIS+Kestrel (反向代理) vs Nginx

EN

@RickStrahl编写了这个很好的文章使用IISCore2.2托管ASP.NET进程中的ASP.NET内核，其中讨论了IIS中的InProcess托管，ASP.NET 2.2中提供了它。

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

简而言之，在ASP.NET核心中内置的Kestrel服务器并不意味着是面向Web服务器的Internet，而是充当处理非常特定的数据处理任务的应用服务器或边缘服务器。Kestrel是针对应用程序场景进行优化的，但它没有针对其他事情进行优化，比如为服务器服务或管理服务器生命周期的静态文件。 因此，通常不希望在Web应用程序中直接运行Kestrel。在使用IIS的Windows和Linux上都是如此，在Linux中，您倾向于使用Web服务器nginx或ha代理来处理非应用程序的问题。我写过如何设置IIS重写规则来路由常见的静态文件，而不是让Kestrel处理它们。这不仅与速度有关，而且还让Web应用程序专注于执行它设计的动态操作，让IIS完成它设计的工作。 以下是关于为什么要使用完整的Web服务器而不是直接连接到Web的应用程序的几个论点：

• 端口共享Kestrel目前不能像IIS和http.sys在Windows上那样进行端口共享。目前，该功能仅通过Windows上的IIS支持。(AFAIK您甚至不能使用HttpSys服务器来完成此操作)。此外，虽然可以在ASP.NET核心中使用主机头路由，但目前设置它并不容易，也不容易维护。
• 如果你在没有任何支持基础设施的情况下运行你的应用程序，任何崩溃或失败都会关闭应用程序并使你的站点离线。不管发生什么，您都需要某种主机监视器来确保应用程序在失败时继续运行，IIS会立即提供这种功能。使用ASP.NET核心模块的ASP.NET核心直接受益于能够重新启动应用程序池，从而在失败时重新启动应用程序。
• 目前，为Kestrel服务的静态文件不是很好的静态文件处理，与IIS优化的静态文件缓存和压缩基础结构相比，Kestrel速度相对较慢。IIS充分利用了内核模式缓存，并内置了比今天的ASP.NET StaticFile处理程序(".UseStaticFiles()")更高效的压缩基础结构。

还有其他原因:安全性和服务器强化、管理特性、管理SSL证书、完整日志记录和Http请求跟踪工具以及列表继续进行。所有的理由都是坐在专用的Web服务器平台后面，而不是运行和管理一个自托管的服务器实例。