ASP.NET MVC 应用程序的性能和安全性 - 处理程序映射和模块
我刚刚读了一篇有趣的文章。基本上它说，您应该通过两种方式微调每个应用程序的 IIS 设置：
- 处理程序映射 - 删除所有未使用的应用程序
- 模块 - 删除所有未使用的应用程序
好吧，我开发 ASP.NET 一段时间了，即使是在工作中，并且据我所知，我们从未在生产环境中这样做过。我理解所提出的理论优势 - 最小化应用程序的“表面”（安全性）并提高性能。但我真的很好奇，如果你在现实生活中这样做（为你的客户提供真实的项目，而不是概念验证项目）。这有什么缺点（可能是可维护性？）。最重要的问题是——值得吗？例如，性能提升是否明显？
此外，如果您认为这是一个很好的做法，请提供一些良好且一致的方法（或向我指出教程），您到底如何执行此过程 - 您如何决定保留哪些内容以及删除哪些内容。
例如，ASP.NET MVC 3 应用程序的最小但工作集是什么，它使用自定义身份验证（基于会话，不依赖于表单身份验证、Windows 身份验证等），没有 Web 服务和类似功能？
编辑
我找到了这篇文章：http://madskristensen。 net/post/Remove-default-HTTP-modules-in-ASPNET.aspx
在其中，Scott Guthrie 说：
一般来说，使用这种方法你可以获得一些非常小的性能提升 - 尽管我可能会这样做建议不要这样做。原因是，一旦删除了 ASP.NET 所依赖的模块，ASP.NET 的某些功能（表单身份验证、角色、缓存等）当然会停止工作。试图弄清楚为什么会发生这种情况常常会令人困惑。
但仍然没有测量、实践（我并不真正相信“稍后你会感到惊讶”的论点:)
i just have read an interesting article. Basically it says, you should fine-tune IIS settings for every application in 2 ways:
- handler mappings - remove all unused by application
- modules - remove all unused by application
Well, i develop ASP.NET for some time now, even at work, and we never ever have done this on production environment afaik. I understand the theoretical advantages presented - minimizing "surface" of application (security), and improving performance. But I am really curious, if you do this in real life (real projects for your customers, not proof-of-concept projects). What are the downsides of this (maintanability maybe?). And most important question - is it worth it ? Is, for example, the performance gain even visible ?
In addition, if you consider this a good practice, please present some good and consistent way (or point me to tutorial), how exactly you do this process - how you decide what stay and what to remove.
For example, what is minimal but working set for ASP.NET MVC 3 application, which uses custom authentication (session based, not relying on Forms auth, Windows auth etc.), no webservices and similar features ?
EDIT
I have found this article : http://madskristensen.net/post/Remove-default-HTTP-modules-in-ASPNET.aspx
In it, Scott Guthrie says:
In general you can get some very small performance wins using this approach - although I'd probably recommend not doing it. The reason is that some features of ASP.NET (forms auth, roles, caching, etc) will of course stop working once you remove the modules they depend on. Trying to figure out why this has happened can often be confusing.
But still no measurments, practices (i am not really convinced by "you can be surprised later" argument :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这并不直接回答您的问题，而是回答 关于 SO 的另一个问题，我刚刚发现 URL 重写模块已打开。
因此，即使您不使用模块，它也会对您的应用程序产生影响。
但是，我认为除非您对特定模块或处理程序有安全问题（我必须同意 Scott Gu 的观点），否则您可能不会注意到（除非您每天处理约 100 万个请求或其他）并且会更好用于花这段时间调整您的缓存（数据库和内容）配置文件。
哦，所以我在某种程度上回答了你的问题，不，我们不这样做。
This doesn't directly answer your question, but in answering another question on SO, I just found out about the performance impacts to MVC of having the URL Rewrite module turned on.
So here is a case of even if you are not using a module, it can have impacts on your application.
However, I would think that unless you have security concerns with specific modules or handlers that I would have to agree with Scott Gu, you probably are not going to notice (unless you are handling ~1million request per day or something) and would be better served to spend this time tuning your cache (database and content) profiles.
Oh, and so I somewhat answer your question, no we do not do this.
从性能的角度来看，这是一个很好的最佳实践。但通常还有其他因素需要考虑。
生产环境通常不在开发人员手中。
a.那些人可能有足够的心思去应用微不足道的性能调整。
b.发布手册越短越好。添加不必要的（在本例中是微不足道的）性能调整步骤可能会导致步骤被检查。
同样，从性能的角度来看，这是一个很好的最佳实践。根据我的经验，大多数应用程序不需要此类性能调整。因此，缺点大于优点。但是，就像 Tommy 所说，如果您的应用程序每天处理数百万个请求，那么每一点都会有所帮助。
From a performance point of view, that is a great best practice. Often though, there are other factors to be considered.
Production environments are often not in the hands of developers.
a. The persons who are, probably have enough on their minds to be applying trivial performance tweaks.
b. The shorter the release manual, the better. Adding unnecessary (in this case, trivial) steps for performance tweaks can lead to steps being looked over.
Again, from a performance point of view it is a great best practice. In my experience, most applications don't require these kind of performance tweaks. Thus, the disadvantages outweigh the advantages. But, like Tommy said, if your application handles millions of requests a day, then every bit helps.
首先，我要在这里说实话，并明确我没有这样做过，但只有一次（更多内容见下文）。
您必须考虑到，从安全角度来看，这是理所当然的。如果您知道自己没有使用一组功能，为什么还要继续公开它们呢？
现在让我们回到 2010 年 9 月。当时有一个严重的漏洞：asp.net padding oracle。我有几篇关于它的博客文章，一篇关于 asp.net padding oracle：对 asp.net MVC 和 PHP 的影响
请注意，即使没有积极使用 asp.net，这也会如何影响 PHP。
所以问题出在 ASP.NET MVC 中通常不使用的处理程序上。事实上，在我当时处理的一些客户端服务器/应用程序上，我们禁用了有问题的处理程序。在微软推出解决方案之前，漏洞已被关闭；应用程序没有受到影响，因为我们没有使用任何处理程序。
代价是，并非所有处理程序都那么简单。肯定很难知道某些应用程序中使用了哪些处理程序。另一方面，了解您正在使用的 ASP.NET 各个部分的情况也是有好处的。
First, I'll be honest here, and be clear that I haven't done this but in one occasion (more on it below).
You have to consider that from a security point of view it is a no brainer. If you know you are Not using a set of features, why keep exposing them?
Now let's go back in time to Sept 2010. There was a serious vulnerability: the asp.net padding oracle. I have a few blog posts on it, one on asp.net padding oracle: impact on asp.net MVC and PHP
Notice how this could affect PHP even if asp.net wasn't actively used.
So the issue was on handlers that are Not typically used in asp.net MVC. In fact, on a few clients servers/applications I was handling at the time, we disabled the offending handlers. Vulnerability closed, before MS rolled out their solution; applications were not affected as we weren't using any of the handlers.
The trade off, is that not all handlers are as simple as that. It can definitely be very hard to know which handlers are in used in some applications. On the other hand, it's good to know what's going on with the pieces of asp.net you're using.
不管怎样，IIS 8 的安全最佳实践有以下内容：
IIS 模块概述 也有 IIS 模块参考每个模块的“删除此模块时的潜在问题”部分。例如，如果删除 DefaultAuthentication 模块：
For what's it worth, Security Best Practices for IIS 8 has this:
IIS Modules Overview also has IIS modules reference with a section called 'Potential issues when removing this module' for each module. For example, if DefaultAuthentication module is removed: