我正在评估 ASP.NET Core 应用程序的各种托管选项。在 ASP.NET 的新编程模型中，您使用一组中间件（它们是旧的IHttpModule&的混合体IHttpHandler）处理请求。
您可以拥有一个中间件，它可以负责身份验证、处理静态文件或在发送之前压缩响应（仅举几例）。混乱来了。
在责任范围内，在哪里设置服务器和应用程序之间的边界？
哪一方应该负责压缩响应？使用 IIS，这由服务器处理并在 web.config 中进行配置。Kestrel 不提供此功能 AFAIK，因此您需要在应用程序中实现一个自定义中间件，该中间件将为您处理此问题。哪一个更合适？
认证呢？IIS 提供身份验证设置（匿名、模拟、表单身份验证）。相反，在 ASP.NET Core 中，我们也可以编写一个应用程序中间件来为我们处理这个问题。
好的，SSL由服务器处理，因为它位于协议层的下方，并且应用程序仅在 HTTP(S) 上运行。
服务器应该承担什么责任？一个应用程序应该有什么责任？
如维基百科所述：
“Web 服务器的主要功能是存储、处理和交付网页给客户端”
问题是所有著名的http服务器（nginx，apache，IIS，...）都带有许多可以处理许多不同任务的模块，包括您在问题中提到的那些（身份验证，压缩，...）。
您添加的模块越多，您的 http 服务器的速度就越慢。例如，到目前为止，IIS 并不是最快的 http 服务器，但是如果您删除所有模块并将其仅用于提供资源，那么它会变得非常快，因为它是为早在天！
所有类型的软件应用程序都存在责任问题。
想想主要作用是存储数据的数据库。像 Oracle 或 SQL Server 这样的 RDBMS 非常擅长。但是一旦他们发布了一个新版本，他们也发布了一个与存储数据无关的新功能。人们使用它！;-)
人们有多少次将他们的数据库用作搜索引擎？我看到人们使用 SQL Server 发送邮件！但更糟糕的是有些人试图在存储过程中调用 Web 服务 ;-)
拥有一个工具来做所有事情总是很诱人，但你需要记住，它并不是为所有目的而构建的。我宁愿使用一堆轻量级的工具，它们有一个单一的职责，并且可以正确处理它。
现在回到您的问题，我认为这是利用中间件的好方法。这样您就可以控制整个管道，并且您确切地知道您的请求已通过什么。中间件也是可测试的！摆脱所有不必要的模块肯定会让您获得更轻量级的 http 服务器。
正义的“视情况而定”的答案也是可以接受的。如果您进行一些测试并发现 gzip 压缩模块比中间件快 10 倍，请使用该模块！也不要教条！
服务器负责实现基本的 HTTP 协议、管理连接等。它也可以选择提供其他功能（例如 windows auth），但我们建议不要这样做，除非它可以提供比中间件实现明显的优势。例如，Windows auth 可以在中间件中实现，但由于某些连接管理限制，它会更加困难。压缩可以在中间件中实现，就像在服务器中一样容易。