i just have read an interesting article. Basically it says, you should fine-tune IIS settings for every application in 2 ways:
我刚读了一篇有趣的文章。它基本上是说，你应该用两种方法对每个应用程序的IIS设置进行微调:
- 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 ?
嗯,我开发ASP。现在，即使在工作中，我们也从来没有在生产环境中这样做过。我理解所提出的理论优势——最小化应用的“表面”(安全性)，提高性能。但我真的很好奇，如果你在现实生活中这么做(为你的客户做真实的项目，而不是概念验证项目)。这其中的缺点是什么?最重要的问题是——值得吗?例如，性能增益是否可见?
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 ?
例如，什么是最小的，但为ASP工作集。NET MVC 3应用程序，使用自定义身份验证(基于会话，不依赖于form auth、Windows auth等)、没有webservices等功能?
EDIT
编辑
I have found this article : http://madskristensen.net/post/Remove-default-HTTP-modules-in-ASPNET.aspx
我找到了这篇文章:http://madskristensen.net/post/remove - defaulthttp - modules-inaspnet.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.
一般来说，使用这种方法您可以获得一些非常小的性能优势——尽管我可能建议您不要这样做。原因是ASP的一些特点。NET(表单身份、角色、缓存等)当然会在删除它们所依赖的模块后停止工作。试图弄清楚为什么会发生这种情况通常会让人感到困惑。
But still no measurments, practices (i am not really convinced by "you can be surprised later" argument :)
但是仍然没有测量和实践(我不太相信“你以后会感到惊讶”的论点:)
5 个解决方案
#1
2
For what's it worth, Security Best Practices for IIS 8 has this:
至于它的价值，IIS 8的安全最佳实践有以下几点:
Install only the IIS modules you need.
只安装所需的IIS模块。
IIS 8 is composed of more than 40 modules, which allow you to add modules you need and remove any modules you don’t need. If you install only the modules you need, you reduce the surface area that is exposed to potential attacks.
IIS 8由40多个模块组成，可以添加需要的模块，并删除不需要的模块。如果您只安装所需的模块，那么您将减少可能受到攻击的表面区域。
Periodically remove unused or unwanted modules and handlers.
定期删除未使用或不需要的模块和处理程序。
Look for modules and handlers that you no longer use and remove them from your IIS installation. Strive to keep your IIS surface area as small as possible.
查找不再使用的模块和处理程序，并从IIS安装中删除它们。尽量保持你的IIS表面面积尽可能小。
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:
IIS模块概述也有IIS模块参考，每个模块都有一个名为“删除该模块时可能出现的问题”的章节。例如，如果删除了DefaultAuthentication模块:
Some ASP.NET features may not work for anonymous requests if ASP.NET authentication mode is Forms. Also, DefaultAuthentication.OnAuthenticate event will not be raised.
一些ASP。如果是ASP, NET特性可能不能用于匿名请求。NET认证模式是表单。同时,DefaultAuthentication。不会引发OnAuthenticate事件。
#2
5
<modules runAllManagedModulesForAllRequests="false">
<!-- disable authorization section -->
<remove name="UrlAuthorization" />
<!-- disable unused authentication schemes -->
<remove name="WindowsAuthentication" />
<remove name="PassportAuthentication" />
<!-- disable ACL file and directory check -->
<!-- <remove name="FileAuthorization" /> -->
<!-- We don't use ASP.NET Profiles -->
<remove name="Profile" />
<!-- We don't provide any WCF service -->
<remove name="ServiceModel" />
<!-- Remove modules not used by ASP.NET MVC + jQuery -->
<remove name="ScriptModule-4.0" />
</modules>
#3
0
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.
这并不能直接回答你的问题，但在回答另一个问题时，我刚刚发现了让URL重写模块打开的MVC的性能影响。
When performing URL generation (for example via a method like Html.ActionLink) in some cases MVC checks to see if the currently requested URL has been rewritten by the URL Rewrite module. If that is the case the result is processed so that it correctly matches the URL requested by the client. The act of checking if a URL has been rewritten has a non-trivial cost (because it involves checking server variables). ASP.NET MVC 3 checks to see if URL Rewrite is turned off and can cache that fact thus avoiding the need to inspect server variables for each request. If URL Rewrite is turned on MVC will have to check server variables even if no rewriting happened for a particular request so if you are not using URL Rewrite you should turn it off.
在某些情况下，当执行URL生成(例如通过Html.ActionLink等方法)时，MVC会检查当前请求的URL是否已被URL重写模块重写。如果是这样，则对结果进行处理，使其与客户端请求的URL匹配。检查URL是否已重写的行为代价不小(因为它涉及检查服务器变量)。ASP。NET MVC 3检查是否关闭了URL重写，并可以缓存这个事实，从而避免为每个请求检查服务器变量。如果URL重写被打开，MVC将不得不检查服务器变量，即使对于特定的请求没有重写，所以如果你没有使用URL重写，你应该关闭它。
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.
不过,我想,除非你有安全问题与特定的模块或处理程序,我将不得不同意斯科特•顾你可能不会注意到(除非你是处理~ 100万请求每天之类的),最好花这个时间优化缓存(数据库和内容)配置文件。
Oh, and so I somewhat answer your question, no we do not do this.
哦，所以我多少回答了你的问题，不，我们不这样做。
#4
0
From a performance point of view, that is a great best practice. Often though, there are other factors to be considered.
从性能的角度来看，这是一个很好的实践。然而，通常还有其他因素需要考虑。
- Most applications get expanded over time. If you're not using a feature now, you might in the future. When you do, I can imagine someone forgetting to reconfigure the IIS settings, causing your production environment to be down longer.
- 大多数应用程序都会随着时间的推移而扩展。如果你现在不使用某个功能，将来可能会用到。当您这样做时，我可以想象有人忘记重新配置IIS设置，导致您的生产环境关闭的时间更长。
-
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.
a.这些人可能脑子里有足够的想法去进行琐碎的性能调整。
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.
b.发布手册越短越好。为性能调整添加不必要的(在本例中是琐碎的)步骤可能导致要检查的步骤。
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.
从性能的角度来看，这是一个很好的实践。根据我的经验，大多数应用程序不需要这些性能调整。因此，弊大于利。但是，正如Tommy所说，如果您的应用程序每天处理数百万个请求，那么每一点都会有所帮助。
#5
0
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
现在让我们回到2010年9月。有一个严重的漏洞:asp.net填充oracle。我有一些关于它的博客文章，一个关于asp.net填充oracle:对asp.net MVC和PHP的影响
Notice how this could affect PHP even if asp.net wasn't actively used.
注意，即使没有积极使用asp.net，这也会影响PHP。
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.
所以问题出在asp.net MVC中通常不使用的处理器上。事实上，在我当时处理的一些客户机服务器/应用程序上，我们禁用了违规的处理程序。在MS推出他们的解决方案之前，漏洞已经关闭;应用程序没有受到影响，因为我们没有使用任何处理程序。
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.
权衡的是，并不是所有的处理程序都这么简单。要知道哪些处理程序在某些应用程序中使用是非常困难的。另一方面，了解你正在使用的asp.net代码的情况是很好的。
#1
2
For what's it worth, Security Best Practices for IIS 8 has this:
至于它的价值，IIS 8的安全最佳实践有以下几点:
Install only the IIS modules you need.
只安装所需的IIS模块。
IIS 8 is composed of more than 40 modules, which allow you to add modules you need and remove any modules you don’t need. If you install only the modules you need, you reduce the surface area that is exposed to potential attacks.
IIS 8由40多个模块组成，可以添加需要的模块，并删除不需要的模块。如果您只安装所需的模块，那么您将减少可能受到攻击的表面区域。
Periodically remove unused or unwanted modules and handlers.
定期删除未使用或不需要的模块和处理程序。
Look for modules and handlers that you no longer use and remove them from your IIS installation. Strive to keep your IIS surface area as small as possible.
查找不再使用的模块和处理程序，并从IIS安装中删除它们。尽量保持你的IIS表面面积尽可能小。
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:
IIS模块概述也有IIS模块参考，每个模块都有一个名为“删除该模块时可能出现的问题”的章节。例如，如果删除了DefaultAuthentication模块:
Some ASP.NET features may not work for anonymous requests if ASP.NET authentication mode is Forms. Also, DefaultAuthentication.OnAuthenticate event will not be raised.
一些ASP。如果是ASP, NET特性可能不能用于匿名请求。NET认证模式是表单。同时,DefaultAuthentication。不会引发OnAuthenticate事件。
#2
5
<modules runAllManagedModulesForAllRequests="false">
<!-- disable authorization section -->
<remove name="UrlAuthorization" />
<!-- disable unused authentication schemes -->
<remove name="WindowsAuthentication" />
<remove name="PassportAuthentication" />
<!-- disable ACL file and directory check -->
<!-- <remove name="FileAuthorization" /> -->
<!-- We don't use ASP.NET Profiles -->
<remove name="Profile" />
<!-- We don't provide any WCF service -->
<remove name="ServiceModel" />
<!-- Remove modules not used by ASP.NET MVC + jQuery -->
<remove name="ScriptModule-4.0" />
</modules>
#3
0
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.
这并不能直接回答你的问题，但在回答另一个问题时，我刚刚发现了让URL重写模块打开的MVC的性能影响。
When performing URL generation (for example via a method like Html.ActionLink) in some cases MVC checks to see if the currently requested URL has been rewritten by the URL Rewrite module. If that is the case the result is processed so that it correctly matches the URL requested by the client. The act of checking if a URL has been rewritten has a non-trivial cost (because it involves checking server variables). ASP.NET MVC 3 checks to see if URL Rewrite is turned off and can cache that fact thus avoiding the need to inspect server variables for each request. If URL Rewrite is turned on MVC will have to check server variables even if no rewriting happened for a particular request so if you are not using URL Rewrite you should turn it off.
在某些情况下，当执行URL生成(例如通过Html.ActionLink等方法)时，MVC会检查当前请求的URL是否已被URL重写模块重写。如果是这样，则对结果进行处理，使其与客户端请求的URL匹配。检查URL是否已重写的行为代价不小(因为它涉及检查服务器变量)。ASP。NET MVC 3检查是否关闭了URL重写，并可以缓存这个事实，从而避免为每个请求检查服务器变量。如果URL重写被打开，MVC将不得不检查服务器变量，即使对于特定的请求没有重写，所以如果你没有使用URL重写，你应该关闭它。
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.
不过,我想,除非你有安全问题与特定的模块或处理程序,我将不得不同意斯科特•顾你可能不会注意到(除非你是处理~ 100万请求每天之类的),最好花这个时间优化缓存(数据库和内容)配置文件。
Oh, and so I somewhat answer your question, no we do not do this.
哦，所以我多少回答了你的问题，不，我们不这样做。
#4
0
From a performance point of view, that is a great best practice. Often though, there are other factors to be considered.
从性能的角度来看，这是一个很好的实践。然而，通常还有其他因素需要考虑。
- Most applications get expanded over time. If you're not using a feature now, you might in the future. When you do, I can imagine someone forgetting to reconfigure the IIS settings, causing your production environment to be down longer.
- 大多数应用程序都会随着时间的推移而扩展。如果你现在不使用某个功能，将来可能会用到。当您这样做时，我可以想象有人忘记重新配置IIS设置，导致您的生产环境关闭的时间更长。
-
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.
a.这些人可能脑子里有足够的想法去进行琐碎的性能调整。
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.
b.发布手册越短越好。为性能调整添加不必要的(在本例中是琐碎的)步骤可能导致要检查的步骤。
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.
从性能的角度来看，这是一个很好的实践。根据我的经验，大多数应用程序不需要这些性能调整。因此，弊大于利。但是，正如Tommy所说，如果您的应用程序每天处理数百万个请求，那么每一点都会有所帮助。
#5
0
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
现在让我们回到2010年9月。有一个严重的漏洞:asp.net填充oracle。我有一些关于它的博客文章，一个关于asp.net填充oracle:对asp.net MVC和PHP的影响
Notice how this could affect PHP even if asp.net wasn't actively used.
注意，即使没有积极使用asp.net，这也会影响PHP。
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.
所以问题出在asp.net MVC中通常不使用的处理器上。事实上，在我当时处理的一些客户机服务器/应用程序上，我们禁用了违规的处理程序。在MS推出他们的解决方案之前，漏洞已经关闭;应用程序没有受到影响，因为我们没有使用任何处理程序。
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.
权衡的是，并不是所有的处理程序都这么简单。要知道哪些处理程序在某些应用程序中使用是非常困难的。另一方面，了解你正在使用的asp.net代码的情况是很好的。