因为搜索引擎的流行，网络爬虫已经成了很普及网络技术，除了专门做搜索的Google，Yahoo，微软，百度以外，几乎每个大型门户网站都有自己的搜索引擎，大大小小叫得出来名字得就几十种，还有各种不知名的几千几万种，对于一个内容型驱动的网站来说，受到网络爬虫的光顾是不可避免的。

一些智能的搜索引擎爬虫的爬取频率比较合理，对网站资源消耗比较少，但是很多糟糕的网络爬虫，对网页爬取能力很差，经常并发几十上百个请求循环重复抓取，这种爬虫对中小型网站往往是毁灭性打击，特别是一些缺乏爬虫编写经验的程序员写出来的爬虫破坏力极强。曾经有一次我在JavaEye的日志里面发现一个User-Agent是Java的爬虫一天之内爬取了将近100万次动态请求。这是一个用JDK标准类库编写的简单爬取网页程序，由于JavaEye网站内部链接构成了回环导致程序陷入了死循环。对于JavaEye这种百万PV级别的网站来说，这种爬虫造成的访问压力会非常大，会导致网站访问速度缓慢，甚至无法访问。

此外，相当数量的的网页爬虫目的是盗取目标网站的内容。比方说JavaEye网站就曾经被两个竞争对手网站爬取论坛帖子，然后在自己的论坛里面用机器人发帖，因此这种爬虫不仅仅影响网站访问速度，而且侵犯了网站的版权。

对于一个原创内容丰富，URL结构合理易于爬取的网站来说，简直就是各种爬虫的盘中大餐，很多网站的访问流量构成当中，爬虫带来的流量要远远超过真实用户访问流量，甚至爬虫流量要高出真实流量一个数量级。像JavaEye网站虽然设置了相当严格的反爬虫策略，但是网站处理的动态请求数量仍然是真实用户访问流量的2倍。可以肯定的说，当今互联网的网络流量至少有2/3的流量爬虫带来的。因此反爬虫是一个值得网站长期探索和解决的问题。

一、手工识别和拒绝爬虫的访问

有相当多的爬虫对网站会造成非常高的负载，因此识别爬虫的来源IP是很容易的事情。最简单的办法就是用netstat检查80端口的连接：

netstat -nt | grep youhostip:80 | awk '{print $5}' | awk -F":" '{print $1}'| sort | uniq -c | sort -r -n 

这行shell可以按照80端口连接数量对来源IP进行排序，这样可以直观的判断出来网页爬虫。一般来说爬虫的并发连接非常高。

如果使用lighttpd做Web Server，那么就更简单了。lighttpd的mod_status提供了非常直观的并发连接的信息，包括每个连接的来源IP，访问的URL，连接状态和连接时间等信息，只要检查那些处于handle-request状态的高并发IP就可以很快确定爬虫的来源IP了。

拒绝爬虫请求既可以通过内核防火墙来拒绝，也可以在web server拒绝，比方说用iptables拒绝：

iptables -A INPUT -i eth0 -j DROP -p tcp --dport 80 -s 84.80.46.0/24  

直接封锁爬虫所在的C网段地址。这是因为一般爬虫都是运行在托管机房里面，可能在一个C段里面的多台服务器上面都有爬虫，而这个C段不可能是用户宽带上网，封锁C段可以很大程度上解决问题。

有些人提出一种脑残的观点，说我要惩罚这些爬虫。我专门在网页里面设计动态循环链接页面，让爬虫掉进陷阱，死循环爬不出来，其实根本用不着设置陷阱，弱智爬虫对正常网页自己就爬不出来，这样做多此一举不说，而且会让真正的搜索引擎降低你的网页排名。而且运行一个爬虫根本不消耗什么机器资源，相反，真正宝贵的是你的服务器CPU资源和服务器带宽，简单的拒绝掉爬虫的请求是反爬虫最有效的策略。


二、通过识别爬虫的User-Agent信息来拒绝爬虫

有很多爬虫并不会以很高的并发连接爬取，一般不容易暴露自己；有些爬虫的来源IP分布很广，很难简单的通过封锁IP段地址来解决问题；另外还有很多各种各样的小爬虫，它们在尝试Google以外创新的搜索方式，每个爬虫每天爬取几万的网页，几十个爬虫加起来每天就能消耗掉上百万动态请求的资源，由于每个小爬虫单独的爬取量都很低，所以你很难把它从每天海量的访问IP地址当中把它准确的挖出来。

这种情况下我们可以通过爬虫的User-Agent信息来识别。每个爬虫在爬取网页的时候，会声明自己的User-Agent信息，因此我们就可以通过记录和分析User-Agent信息来挖掘和封锁爬虫。我们需要记录每个请求的User-Agent信息，对于Rails来说我们可以简单的在app/controllers/application.rb里面添加一个全局的before_filter，来记录每个请求的User-Agent信息：

logger.info "HTTP_USER_AGENT #{request.env["HTTP_USER_AGENT"]}"  

然后统计每天的production.log，抽取User-Agent信息，找出访问量最大的那些User-Agent。要注意的是我们只关注那些爬虫的User-Agent信息，而不是真正浏览器User-Agent，所以还要排除掉浏览器User-Agent，要做到这一点仅仅需要一行shell：

grep HTTP_USER_AGENT production.log | grep -v -E 'MSIE|Firefox|Chrome|Opera|Safari|Gecko' | sort | uniq -c | sort -r -n | head -n 100 > bot.log  

统计结果类似这样：

  57335 HTTP_USER_AGENT Baiduspider+(+http://www.baidu.com/search/spider.htm)
  56639 HTTP_USER_AGENT Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
  42610 HTTP_USER_AGENT Mediapartners-Google
  19131 HTTP_USER_AGENT msnbot/2.0b (+http://search.msn.com/msnbot.htm)

从日志就可以直观的看出每个爬虫的请求次数。要根据User-Agent信息来封锁爬虫是件很容易的事情，lighttpd配置如下：

$HTTP["useragent"] =~ "qihoobot|^Java|Commons-HttpClient|Wget|^PHP|Ruby|Python" {
  url.rewrite = ( "^/(.*)" => "/crawler.html" )
}

使用这种方式来封锁爬虫虽然简单但是非常有效，除了封锁特定的爬虫，还可以封锁常用的编程语言和HTTP类库的User-Agent信息，这样就可以避免很多无谓的程序员用来练手的爬虫程序对网站的骚扰。

还有一种比较常见的情况，就是某个搜索引擎的爬虫对网站爬取频率过高，但是搜索引擎给网站带来了很多流量，我们并不希望简单的封锁爬虫，仅仅是希望降低爬虫的请求频率，减轻爬虫对网站造成的负载，那么我们可以这样做：

$HTTP["user-agent"] =~ "Baiduspider+" {
    connection.delay-seconds = 10
}

对百度的爬虫请求延迟10秒钟再进行处理，这样就可以有效降低爬虫对网站的负载了。


三、通过网站流量统计系统和日志分析来识别爬虫

有些爬虫喜欢修改User-Agent信息来伪装自己，把自己伪装成一个真实浏览器的User-Agent信息，让你无法有效的识别。这种情况下我们可以通过网站流量系统记录的真实用户访问IP来进行识别。

主流的网站流量统计系统不外乎两种实现策略：一种策略是在网页里面嵌入一段js，这段js会向特定的统计服务器发送请求的方式记录访问量；另一种策略是直接分析服务器日志，来统计网站访问量。在理想的情况下，嵌入js的方式统计的网站流量应该高于分析服务器日志，这是因为用户浏览器会有缓存，不一定每次真实用户访问都会触发服务器的处理。但实际情况是，分析服务器日志得到的网站访问量远远高于嵌入js方式，极端情况下，甚至要高出10倍以上。

现在很多网站喜欢采用awstats来分析服务器日志，来计算网站的访问量，但是当他们一旦采用Google Analytics来统计网站流量的时候，却发现GA统计的流量远远低于awstats，为什么GA和awstats统计会有这么大差异呢？罪魁祸首就是把自己伪装成浏览器的网络爬虫。这种情况下awstats无法有效的识别了，所以awstats的统计数据会虚高。

其实作为一个网站来说，如果希望了解自己的网站真实访问量，希望精确了解网站每个频道的访问量和访问用户，应该用页面里面嵌入js的方式来开发自己的网站流量统计系统。自己做一个网站流量统计系统是件很简单的事情，写段服务器程序响应客户段js的请求，分析和识别请求然后写日志的同时做后台的异步统计就搞定了。

通过流量统计系统得到的用户IP基本是真实的用户访问，因为一般情况下爬虫是无法执行网页里面的js代码片段的。所以我们可以拿流量统计系统记录的IP和服务器程序日志记录的IP地址进行比较，如果服务器日志里面某个IP发起了大量的请求，在流量统计系统里面却根本找不到，或者即使找得到，可访问量却只有寥寥几个，那么无疑就是一个网络爬虫。

分析服务器日志统计访问最多的IP地址段一行shell就可以了：

grep Processing production.log | awk '{print $4}' | awk -F'.' '{print $1"."$2"."$3".0"}' | sort | uniq -c | sort -r -n | head -n 200 > stat_ip.log  

然后把统计结果和流量统计系统记录的IP地址进行对比，排除真实用户访问IP，再排除我们希望放行的网页爬虫，比方Google，百度，微软msn爬虫等等。最后的分析结果就就得到了爬虫的IP地址了。以下代码段是个简单的实现示意：

whitelist = []
IO.foreach("#{RAILS_ROOT}/lib/whitelist.txt") { |line| whitelist << line.split[0].strip if line }

realiplist = []
IO.foreach("#{RAILS_ROOT}/log/visit_ip.log") { |line|  realiplist << line.strip if line }

iplist = []
IO.foreach("#{RAILS_ROOT}/log/stat_ip.log") do |line|
  ip = line.split[1].strip
  iplist << ip if line.split[0].to_i > 3000 && !whitelist.include?(ip) && !realiplist.include?(ip)
end 

Report.deliver_crawler(iplist)

分析服务器日志里面请求次数超过3000次的IP地址段，排除白名单地址和真实访问IP地址，最后得到的就是爬虫IP了，然后可以发送邮件通知管理员进行相应的处理。


四、网站的实时反爬虫防火墙实现策略

通过分析日志的方式来识别网页爬虫不是一个实时的反爬虫策略。如果一个爬虫非要针对你的网站进行处心积虑的爬取，那么他可能会采用分布式爬取策略，比方说寻找几百上千个国外的代理服务器疯狂的爬取你的网站，从而导致网站无法访问，那么你再分析日志是不可能及时解决问题的。所以必须采取实时反爬虫策略，要能够动态的实时识别和封锁爬虫的访问。

要自己编写一个这样的实时反爬虫系统其实也很简单。比方说我们可以用memcached来做访问计数器，记录每个IP的访问频度，在单位时间之内，如果访问频率超过一个阀值，我们就认为这个IP很可能有问题，那么我们就可以返回一个验证码页面，要求用户填写验证码。如果是爬虫的话，当然不可能填写验证码，所以就被拒掉了，这样很简单就解决了爬虫问题。

用memcache记录每个IP访问计数，单位时间内超过阀值就让用户填写验证码，用Rails编写的示例代码如下：

ip_counter = Rails.cache.increment(request.remote_ip)
if !ip_counter
  Rails.cache.write(request.remote_ip, 1, :expires_in => 30.minutes)
elsif ip_counter > 2000
  render :template => 'test', :status => 401 and return false
end

这段程序只是最简单的示例，实际的代码实现我们还会添加很多判断，比方说我们可能要排除白名单IP地址段，要允许特定的User-Agent通过，要针对登录用户和非登录用户，针对有无referer地址采取不同的阀值和计数加速器等等。

此外如果分布式爬虫爬取频率过高的话，过期就允许爬虫再次访问还是会对服务器造成很大的压力，因此我们可以添加一条策略：针对要求用户填写验证码的IP地址，如果该IP地址短时间内继续不停的请求，则判断为爬虫，加入黑名单，后续请求全部拒绝掉。为此，示例代码可以改进一下：

before_filter :ip_firewall, :except => :test
def ip_firewall
  render :file => "#{RAILS_ROOT}/public/403.html", :status => 403 if BlackList.include?(ip_sec)
end

我们可以定义一个全局的过滤器，对所有请求进行过滤，出现在黑名单的IP地址一律拒绝。对非黑名单的IP地址再进行计数和统计：

ip_counter = Rails.cache.increment(request.remote_ip)
if !ip_counter
  Rails.cache.write(request.remote_ip, 1, :expires_in => 30.minutes)
elsif ip_counter > 2000
  crawler_counter = Rails.cache.increment("crawler/#{request.remote_ip}")
  if !crawler_counter
    Rails.cache.write("crawler/#{request.remote_ip}", 1, :expires_in => 10.minutes)
  elsif crawler_counter > 50
    BlackList.add(ip_sec)
    render :file => "#{RAILS_ROOT}/public/403.html", :status => 403 and return false
  end
  render :template => 'test', :status => 401 and return false
end

如果某个IP地址单位时间内访问频率超过阀值，再增加一个计数器，跟踪他会不会立刻填写验证码，如果他不填写验证码，在短时间内还是高频率访问，就把这个IP地址段加入黑名单，除非用户填写验证码激活，否则所有请求全部拒绝。这样我们就可以通过在程序里面维护黑名单的方式来动态的跟踪爬虫的情况，甚至我们可以自己写个后台来手工管理黑名单列表，了解网站爬虫的情况。

这个策略已经比较智能了，但是还不够好！我们还可以继续改进：

1、用网站流量统计系统来改进实时反爬虫系统

还记得吗？网站流量统计系统记录的IP地址是真实用户访问IP，所以我们在网站流量统计系统里面也去操作memcached，但是这次不是增加计数值，而是减少计数值。在网站流量统计系统里面每接收到一个IP请求，就相应的cache.decrement(key)。所以对于真实用户的IP来说，它的计数值总是加1然后就减1，不可能很高。这样我们就可以大大降低判断爬虫的阀值，可以更加快速准确的识别和拒绝掉爬虫。

2、用时间窗口来改进实时反爬虫系统

爬虫爬取网页的频率都是比较固定的，不像人去访问网页，中间的间隔时间比较无规则，所以我们可以给每个IP地址建立一个时间窗口，记录IP地址最近12次访问时间，每记录一次就滑动一次窗口，比较最近访问时间和当前时间，如果间隔时间很长判断不是爬虫，清除时间窗口，如果间隔不长，就回溯计算指定时间段的访问频率，如果访问频率超过阀值，就转向验证码页面让用户填写验证码。

最终这个实时反爬虫系统就相当完善了，它可以很快的识别并且自动封锁爬虫的访问，保护网站的正常访问。不过有些爬虫可能相当狡猾，它也许会通过大量的爬虫测试来试探出来你的访问阀值，以低于阀值的爬取速度抓取你的网页，因此我们还需要辅助第3种办法，用日志来做后期的分析和识别，就算爬虫爬的再慢，它累计一天的爬取量也会超过你的阀值被你日志分析程序识别出来。

总之我们综合运用上面的四种反爬虫策略，可以很大程度上缓解爬虫对网站造成的负面影响，保证网站的正常访问。

前提：

第一章：软件介绍
ISAPI_Rewrite 是一款适用于IIS的功能强大的基于正则表达式的URL处理模块。它兼容Apache的mod_rewrite的语法，从而使仅仅复制.htaccess文件就把配置从appach移植到IIS中或者从IIS移值到appach中变成可能。请参阅3.2兼容性图表这一节。
ISAPI_Rewrite最重要的功能：
? ISAPI_Rewrite提供了和Apach mod_rewrite相同的句法和行为，使仅仅拷贝.htaccess文件就完成配置移植成为功能。(要想阅读更多关于与mod_rewrite的兼容性，请参阅3.2兼容性图表这一节。)
? 正则表达式支持灵活而强大的配置。
? 极速而且容易升级的纯C++代码。
? 真正的分布式配置：实时监控服务器全局级别、虚拟主机（网站）级别、目录级别的.htaccess文件。
? 隔离性：用户级配置只影响本地用户环境，从而使ISAPI_Rewrite成为Web主机提供商的理想解决方案。
重要的应用示例：
? 搜索引擎优化。
? 一台Web服务器的代理内容经过另一台web服务器。
? 防止内容被吸血（盗链）。
? 阻断特定主机、反向链接或者烦人的搜索机器人。
? 内容商议：向不同的语言用户或者不同的浏览器用户提供不同的文件。示例
? 为群集式服务器架构模拟负载均衡。
定价资料
? 45天的试用期
? 单机版99美元
? ISAPI_Rewrite精简版是免费的。在这里可以看到受限的细节说明。
? 大宗采购可议折扣。

2.1系统要求
ISAPI_Rewrite可以被安装在下列操作系统中：
? Windows 2000 with IIS 5
? Windows XP with IIS 5.1
? Windows Server 2003 with IIS 6.0
? Windows Vista with IIS 7.0
? Windows Server 2008 with IIS 7.0
在安装ISAPI_Rewrite之前，操作系统中必须先安装IIS。
32位和64位的Windows版本都是支持的，但是你必须下载32位版和64位版两种不同的安装包。Windows Installer 2.0必须运行安装程序。你可以从微软的网站上下载到最新版本的Windows Installer。
在Windows Vista和Windows Server 2008上安装ISAPI_Rewrite，还必须先安装下面两个模块(默认情况下这两个模块是不安装的)
? ISAPI过滤器
? ISAPI 扩展

2.2安装程序
在运行安装包之前请先阅读系统要求部分。下载并安装某个版本的ISAPI_Rewrite.msi，依照安装向导的说明操作。安装过程是自动的，并有自我描述。ISAPI_Rewrite在自动安装过程中必须重启IIS。下列服务必须被重启：IISADMIN、W3SVC。不需要手工把任何ISAPI筛选器或者扩展加入到网站或者全局列表中。它能够在安装和配置过程中自动完成。
命令行安装
ISAPI_Rewrite也能够通过命令行进行后台安装。请使用以下命令行语法来安装：

msiexec /i ISAPI_Rewrite3.msi /qn AcceptEULA=Yes REGISTRATIONCODE=Code 
REGISTRATIONNAME=Name

用命令行来后台反安装ISAPI_Rewrite请使用下面的语法：

msiexec /x ISAPI_Rewrite3.msi /qn KEEPUSERFILES=Yes

2.3手工安装
要手工安装ISAPI_Rewrite的话，你必须下载不同的手工安装包包含所有必须的文件。ISAPI_Rewrite精简版不支持手工安装。你可以安装全部功能或者仅仅安装它们中的一部分。
手工安装包包含下列文件：
? ISAPI_Rewrite.dll - 这是ISAPI筛选器本身。
? ISAPI_RewriteProxy.dll - 这是为代理操作的ISAPI扩展模块必不可少的。
? license.rtf - EULA的产品许可证。
? ISAPI_Rewrite.chm - .文档文件。
? httpd.conf - 全局配置文件示例。
安装ISAPI_Rewrite，首先你必须在你在IIS系统中注册ISAPI_Rewrite.dll作为ISAPI筛选器。按默认ISAPI_Rewrite.dll文件是用来作为全局ISAPI筛选器的。而且它还能够被安装到某个特定的网站里，你需要记住在同一时间段里只有一个ISAPI_Rewrite.dll实例能够加载到一个IIS工作进程里，这意味着如果你决定把ISAPI_Rewrite的ISAPI筛选器单独地安装到每个站点里的话，你必须把这些站点切换高隔离模式，从而为这些网站产生独立的工作进程。如果你需要在每个站点上分别安装ISAPI_Rewrite，我们通常会建议改为在整个IIS上全局地安装它。
在Window 2000,Window XP 和Windows Server 2003中注册ISAPI 筛选器，无论是整个IIS服务器要用它还是个别WEB网站要用它，都要用IIS 的MMC管理单元来把ISAPI_Rewrite.dll添到ISAPI筛选器列表。在Windows Vista和Windows Server 2008中首先你需要安装可选IIS组件：万维网服务、应用程序开发功能、ISAPI筛选器。
如果你需要代理服务器功能，你还需要将ISAPI_RewriteProxy.dll注册为ISAPI扩展来侍服文件扩展名“*. rwhlp”。在不同的IIS版本中要求不同的操作。请参阅你管理的IIS版本的文档来了解如何注册一个新的ISAPI扩展并把它映射到IIS系统的文件扩展名上。在Windows Vista和windows server 2008首先必须安装可选的IIS组件：万组网服务、应用程序开发功能、ISAPI筛选器。使用短路径名（8.3模式）作为ISAPI_RewriteProxy.dll的模块路径，如果路径里有一个空格字符，IIS载入这个模块时将失败。
把httpd.conf文件放在ISAPI_Rewrite.dll文件的同一目录下并编辑它。
把下列两行内容放到httpd.conf文件中以注册ISAPI_Rewrite 产品：

RegistrationName=Your registration name
RegistrationCode=REG-CODE-PROVIDED-FROM-HELICON

依照“运行ISAPI_Rewrite的权限需求”这一部分的说明来检查文件系统权限。

2.4反安装
反安装程序会删除所有安装程序所生成的文件、从管理元库中注销筛选器，并删除所有由安装程序所添加的其它管理元库变化。如果用户决定在反安装过程中保留用户文件的话，下列用户数据文件在反安装后会被留下来。

“删除用户创建的文件”的选项在将反安装过程中提供给用户。如果启用这个选项则卸载程序也将删除位于Program Files文件夹里用户创建的文件。 .htaccess文件不会被删除。
要用命令行后台卸载ISAPI_Rewrite，请使用下面的语法：

msiexec /x ISAPI_Rewrite3.msi /qn KEEPUSERFILES=Yes

2.5运行ISAPI_Rewrite所需的权限
在一个干净的默认Windows系统上自动安装ISAPI_Rewrite不要求任何权限调整。但是一些其它产品比如说Plesk、IIS锁定工具的安装，等等，可能收紧服务器的安全性，并妨碍ISAPI_Rewrite的正常运行。下面是ISAPI_Rewrite的权限需求的列表单子：
在Windows 2000、Windows XP和Windows 2003的IIS5兼容模式下，筛选器运行在System帐户下的inetinfo.exe进程中。那个system帐户至少得被授予放置ISAPI_Rewrite安装文件的那个文件夹的“读取”和“目录浏览”的权限。我们还建议给予system帐号对这个文件夹的一般修改权。这将允许生成一些包含解析或者其它错误的文件。system帐号还必须在任何包含了.htaccess文件的网站文件夹里同样被授予这些权限，否则ISAPI_Rewrite将不能加载并监视它。
请稍留意ISAPI_Rewrite安装目录上的任何一点拒绝权限设置，因为在Windows 操作系统中，拒绝权限优先于任何允许权限记录。
在Windows 2003的天然IIS模式(WPI模式)以及Windows Server 2008中，无论是筛选器还是代理服务都运行在每个网站相应的运行程序池的w3p.exe工作进程中，每个应用程序池都可以使用它自己的定制来配置，这可能使权限设置成了一种复杂的工作。然而，在一个正确的IIS配置中，每个使用中的定制必须是IIS_WPG组的一个成员。因此，IIS_WPG组可以被用来代替System帐号去分配前面所写的权限需求。
在Windows Vista 中权限配置是和Windows 2003的配置差不多的，只是它没有IIW_WPG组。所以，所有的WPI帐号（一般Network Service是它的惟一帐号）都必须授予上述必需权限。
此外，为了让代理服务功能能工作，你必须在网站属性或者运行代理服务的web应用程序的属性中给予一个“纯脚本”的执行权限。

2.6MSI的自定义行为自定义行为
 

3.1基本概念

	if (isset($_SERVER['HTTP_X_REWRITE_URL']))
{
$_SERVER['REQUEST_URI'] = $_SERVER['HTTP_X_REWRITE_URL'];
}

单个字符转义序列
下面的转义序列是单个字符的别名：

杂项转义序列
以下提供perl的大部分兼容性，但是在\l、\L、\u和\U上有一些区别

怎样得到匹配
正则表达式将匹配第一个可匹配字符串。如果从给定的起始处可以匹配到不止一个字符串，则它会匹配那个能匹配得最长的字符串。如果从同一个起始处有多个合适的匹配，而且每个匹配的长度都一样，则将选择那个第一子表达式匹配得最长的匹配。如果有两个以上的匹配字符串它们的第一子表达式匹配得一样长，则比较第二子表达式匹配的长度，如此类推。注意：ISAPI_Rewrite使用比封演算法。只有表达式匹配了整个顺序串才能得到匹配结果。例如：
• RewriteCond URL ^/somedir/.* #将匹配任何导向somedir目录以及它的子目录的请求，与此同时，
• RewriteCond URL ^/somedir/ #只匹配somedir根目录的请求。
对“病态”正则表达式的特别提示：
ISAPI_Rewrite 使用了一个非常强大的来自Boost库的正则表达式引擎。但是它依然有一些局限性：有着一些“病态”的表达式，它可能会指数级地消耗匹配时间。这些都涉及到嵌套重复运算符，例如试图对N个连续字母a匹配表达式“(a*a)*b”，消耗的时间将与N²成正比。这些表达式常常能改成另一种写法来避免这种问题。例如，“(a*a)*b”可以被改写成“a*b”，解析它消耗的时间与N成正比。在多数情况下，非嵌套重复表达式消耗的时间与N²成正比，但是，如果条款是相互排斥的，则它们会在线性时间里完成匹配。在“a*b”这种情况下，每个字符将要么匹配a要么匹配b或者不匹配。相较之下，“a*a”匹配器不能告知哪个分支被采取（第一个 a还是第二个a）因此必须尝试两种。
Regex可以检测出这种“病态”的正则表达式并终止和它们的匹配。这将使ISAPI_Rewrite的规则失效。当一个规则失效时，ISAPI_Rewrite将给客户端发送一个"Internal Server error - Rule Failed"的状态，以表示配置错误。

4.1AccessFileName指令

指定一个ISAPI_ReWrite寻求分布式配置的文件名列表。默认文件名是.htaccess。ISAPI_ReWrite只能载入它能在这个列表中找到的第一个文件。默认情况下ISAPI_ReWrite管理者会以hidden属性标记配置文件-它将防止文件被远程用户直接访问到。
如果配置文件进行了任何修改，它将在下次请求服务器时自动加载。

4.2AllowOverride指令

这个指令声明了在分布式.htaccess文件里的指令是否可以覆盖父级别的httpd.conf中的指令。在ISAPI_Rewrite的使用环境中，这个指令实际上控制了特定虚拟主机或者目录的.htaccess文件的可用或者不可用。目前只支持三个值：All、None和FileInfo。
All和FileInfo使.htaccess文件以及它里面的整个ISAPI_Rewrite目录可用，None使所有的.htaccess文件以及目录不可用。这些目录具有继承性。这意味着如果你为一些目录或者虚拟主机指定AllowOverride none，.htaccess文件将对整个子目录树不可用。

4.4RewriteRule指令

这个指令定义了单个URL重写操作。它可能在一个配置文件中出现多次，每个实例定义一个重写URL的规则。RewriteRule指令包含URL匹配模式、替换字符串以及可选的标志设置。
Pattern（模式）是一个用来匹配当前URL的Perl兼容正则表达式。当前的URL可以是原来请求的URL或者已经由优先级高的规则替改过的URL。网址从不包含协议或者主机名，从第一个斜杠字符开始（只对httpd.conf文件适用）。而且当前网址还因不同的应用配置级别而异。对于目录级配置（.htaccess文件），结尾的斜线和配置文件的目录名，会在匹配时被从URL中忽略掉。在创建正则表达式时，请阅读这个文档的正则表达式语法部分来得到更多的信息。
"!"字符打头的模式将否定整个表达式。否定模式不能产生子匹配，所以你不能使用$N的替代引用。
Substitution(替换)字符串指定了模式是匹配时生成URL的格式字符串。除了纯文本，它可以包括这些特殊字符。
• 对Rewrite模式的回溯引用 $N
• 对Rewrite模式的回溯引用 %N
• 服务器变量 %{VARNAME}
• 条件格式模式 ?Ntrue_string:false_string
• 分组括号“(”和“)”
替换字符串将所有的字符视为字面值，除了$'、'\'、'('、')'，'?'，':'和'\'。为了字面化地读出特殊字符，它定义了用"\"引导的转义字符。下面的特殊字符是允许的。

RewriteRule从父配置文件开始按照在配置文件中出现的次序应用。每个规则只有在它的Pattern匹配了一个URL而且所有连接条件（RewriteCond）都匹配时才会被应用。在该URL用Substitution完成替换之后，重写过程还在继续，一直到配置文件结束或者遇到一个用了任何停止标志的规则。在Substitution中的特殊字符串"-"(短横)意味着没有替换，而且当你需要应用该规则并留下的原始的未被染指过的URL时它是很有用的。
此外，这里有一个支持的flag(标志)列表。这些标识可以改变规则的表现。与Apache完全兼容的标志被标记为绿色，不支持的标志被标记为绿色，只在 ISAPI_Rewrite中被支持的标识被标记成黄色。
CU (Case Upper)
把替换字符串改成大写.
CL (Case Lower)
把替换字符串改成小写.
chain|C
将当前规则与后一条规则链接起来，后一条规则只有在当前规则被匹配的情况下才能被执行。链接可以再后续链接。
cookie|CO=NAME:VAL:domain[:lifetime[:path]]
设置一个有指定字段的cookies头，并把它和当前请求的响应一起发送到客户端。
env|E=VAR:VAL
不支持，在UNIX环境中设置一个环境变量，在Windows系统中无意义。
forbidden|F
发送即时403 FORBIDDEN响应到客户端，停止这个请求的规则处理以及所有其他的替换处理。
gone|G
发送一个即时401Gone响应到客户端，停止这个请求的规则处理以及所有其他的替换过程。
handler|H=Content-handler
不支持，为请求明确指定了处理处理。在IIS的世界中这是可以通过重写请求的文件扩展名来实现。但是没有从Apache处理到IIS文件扩展名的直接转换方法。
last|L
停止这里的重写处理，不再应用当前配置文件中的其它规则。在这种情况下，后代的.htaccess文件依然能被用到。
loop|LP
在一个循环中重复运行当前单个规则直到它的模式以及条件不再被匹配了。循环次数被限定为200免得陷入无限循环。
next|N
从当前配置文件开始处重复运行重写处理。循环次数被限定为200免得陷入无限循环。
nocase|NC
这个标记使Pattern大小写不敏感。
noescape|NE
不转义输出。在ISAPI_Rewrite默认情况下，在输出中会把所有的非ANSI字符编码为十六进制数%xx。
nosubreq|NS
这个标识在ISAPI_Rewrite中与在Apache中含义不同。精确的转换是不可能的，但这个标志可能仍然是有用的。每当配置文件处理完成之后，URL被重写了，ISAPI_Rewrite将启动这个新的URL处理过程（与Apache相同）使它可以应用到另一个配置文件中。此标识意思是该规则只针对初始用户的请求执行，不针对已被重写过的请求执行，以防可能出现的循环。ISAPI_Rewrite限定循环重复次数为10。
nounicode|NU
如果设置了NU标记，从Unicode转换为UTF - 8将不会发生。所有Unicode字符会保持它的%xx格式不变。
O (nOrmalize)
留着用于与ISAPI_Rewrite 2.x兼容。如果使用了RewriteCompatibility2，这个指令在处理之前将URL规范化。规范化包括移除一个URL编码、错误字符，等等。同时URL的规范化将完全移除它的查询字符串。如果RewriteCompatibility2 没有被使用，URL按照默认被规范化（就如同它在mod_rewrite中所做的），此标志的含义将反转。
proxy|P
将结果URL强制内部处理为另一台服务器上的目标，并即时传到远程服务器上，并且，规则处理在这里中断了。远程服务器的响应将被传递回客户端。proxy需要您指定完整的URL，由协议、主机名称等开头。ISAPI_Rewrite使用ISAPI扩展来处理代理请求。你可以在代理配置章节中阅读到更多有关于此的内 容。
passthrough|PT
不支持或者始终支持。在IIS中结果始终传递到下一个处理
qsappend|QSA
追加当前查找串的数据到替换串而不是由一个替换字符串取代它。当你需要在保留原来的参数再添加更多的查询字符串参数时，可以使用它。
redirect|R [=code]
强制服务器用重定向指令给客户端发送一个即时响应，提供一个新的接替位置。可以选加前缀http://thishost[:thissport]/从而把URL带到一个可用的绝对形式。如果没有给出代码，将使用一个302响应(暂时性移动)。你可以选择在3XX系列范围内指定任何代码。
skip|S=num
如果当前的规则匹配，强制rewrite引擎跳过后面num个规则。
type|T=MIME-type
强制目标文件的MIME类型转换成被设定的MIME类型。这能够被用来根据一些条件设置内容类型。
U (Unmangle log)
无损记录。记录它原来请求的网址，而不是被重写的URL。

4.5RewriteCond指令

该指令为后面的RewriteRule，RewriteHeader或RewriteProxy指令规定了一个条件。一个规则指令前可以有一个或多个条件，规则只有在所有条件得到满足的情况下才被应用。
TestString附加到纯文本可以包含下列结构。
• 用语法$N回溯引用RewriteRule模式
• 用语法%N回溯引用前面的RewriteCond模式
• 用语法${mapname:key|default}扩展RewriteMap
• 用语法%{HTTP:header}指代HTTP头值
• 用语法%{NAME_OF_VARIABLE}指代服务器变量
以下是可用的服务器变量列表：

CondPattern指定一个应用于TestString实例的正则表达式，以下特殊值也支持：
1.在正则表达式前头加“!”符号指明否定模式。
2.'<CondPattern'将CondPattern作为一个纯字符串按字典顺序比较，结果比较大
3.'>CondPattern'按字典顺序比较，结果比较小
4.'=CondPattern'按字典顺序比较，结果相等
5.'-d' 检测字符串是否存在目录。
6.'-f' 检测字符串是否存在文件。
7.'-s' 检测字符串是不是一个非零大小的文件。
8.'-l' (链接) 不支持的，始终为false。
9.'-x' (拥有可执行权限) 不支持的，始终为true。
10.'-F' (存在的文件，通过子请求) 不支持，和'–f'一样。
11.'-U' (存在的URL，通过子请求) 不支持的，始终为false。
下面的标记也是支持的：
'nocase|NC'
这个标记使模式大小写不敏感。
'ornext|OR'
这个标记用逻辑或而不是隐含的逻辑与结合子请求RewriteCond指令。
O
留用于ISAPI_Rewrite 2.x的兼容性。在处理前规范化字符串。规范化包括移除一个URL编码、错误字符，等等。同时URL的规范化将完全移除它的查询字符串。

4.6RewriteBase指令

当RewriteRule指令用于每个目录的配置文件(.htaccess)时，它将自动从路径中剥去本地目录前缀，只对剩下的部分应用规则。RewriteBase指令允许你为这些规则精确指定一个基准。比如，哪部分要被剥离。
和Apache的mod_rewrite不同，ISAPI_Rewrite的访问不仅仅针对于物理路径，同时还针对于虚拟路径，而且可以自动地选择正确的基准。所以这个指令只是为了兼容性原因而被保留的。
URL-path可以是相对于根的路径也可以是空，空的URL-path意味着规则的基准等同于网站的根目录。

4.7RewriteProxy指令

使结果URL被内部处理为另一台服务器上的目标，并即时传递到远程服务器，从此中断了规则处理。远程服务器的响应将被传递回客户端。代理要求您指定完整的URL，由协议，主机名称等开头。ISAPI_Rewrite使用ISAPI扩展来处理代理请求。你可以在配置代理的章节里阅读到更多。
语法和操作符与RewriteRule指令是相同的。但是RewroteProxy指令支持一些额外的标记。
H (preserve Host)
代理模块在连接远程服务器时将使用随着源请求一起发送过来的主机头，如果没有这个标志代理服务器则将用主机名和远程服务器的端口号组成主机头。
A (Add authentication headers)
允许从代理服务器将一个认证信息传递到局域网服务器上，当客户端认证和代理服务器冲突时它很有用。服务模块将对一个请求的服务器变量

AUTH_TYPE,
AUTH_USER,
LOGON_USER,
REMOTE_USER

追加相应的头

X-ISRW-Proxy-AUTH-TYPE,
X-ISRW-Proxy-AUTH-USER,
X-ISRW-Proxy-LOGON-USER,
X-ISRW-Proxy-REMOTE-USER

到被代理的服务器。
CR (use Credentials)
代理模块将尝试用在URL中指定的证书身份验证登录远程服务器，或者用基本身份验证头登录远程服务器。用了这个标志，你可以在一个替换字符串中使用http://user:password@host.com/page语法作为一个URL。

4.8RewriteHeader指令

这个RewriteHeader指令是RewriteRule指令中的一个很常用的变量。而且它被设计用来重写客户端的URL部分以及HTTP头的部分。技术上的RewriteRule指令，相当于RewriteHeader的URL Pattern Substitution [flag]。这个指令可用于在IIS里更多应用程序的处理之前重写、创建或者删除任何客户端请求的HTTP头。
HeaderName：指定将被重写的HTTP头的名字。
pattern、Substitution和flag与RewriteRule指令中都是相同的。

4.9RewriteMap指令

RewriteMap指令被用来定义一个键到值的查找功能。当你需要映射大量的值时，它会很有用的，而且它的速度远远快过用规则匹配来做到它。映射功能的性能受映射文件的大小影响微乎其微。有三种类型的映射：
• txt：用一个文本文件映射
• rnd：从多个可选项中产生随机值
• int：内部函数
MapName是这个映射功能的名字，在RewriteRule命令中被用来指定这个映射。请确保每个映射用唯一的名称定义。你可以使用以下语法在RewriteRule指令的Substitution参数中调用映射功能

${ MapName : LookupKey | DefaultValue } 

如果这个结构是在Substitution中出现，ISAPI_Rewrite将在映射中查找这个键，万一找到了一个，就用它的值替换这个结构。如果什么值也没有被找到，将用可选的DefaultValue。如果没有指定DefaultValue，它将用一个空串替换。
下面的标志也是支持的：
‘nocase|NC’
这个标志使该查找键大小写不敏感。
下面是一个大小写不敏感映射文件指令的示例

RewriteMap examplemap txt:C:/path/to/file/map.txt [NC]

到MapSource文件的路径，既可以是绝对地址也可以是相对地址。相对地址将被从当前配置的文件夹开始推算，换言之，就是从这个定义映射的配置文件的路径开始推算。
然后你可以在RewriteRule中如下使用这个映射：

RewriteRule ^/ex/(.*) ${examplemap:$1}

下列MapType和MapSource的组合是可用的：
txt：纯文本映射，它的source是到一个可用的文本文档的windows文件系统路径。文本文档必须是如下格式的：

#This is a comment
key1 value1 #Another comment
key2 value2
keyN valueN

rnd：随机查找多个值。Source是一个文本文档的路径，文本文档必须是以下格式：

#This is a comment
key1 value1|value2|value3
key2 value4|value5|value6|valueN

int: 调用内部函数。 Source必须是下列预定义的内部函数之一：
• toupper: 转换关键词为大写形式。
• tolower:转换关键词为小写形式。
• escape:把特定字符编码为十六进制。
• unescape:把十六进制值编译为特定字符。

4.10RewriteLog指令

这个指令用来设定记录ISAPI_Rewrite动作的日志文件的文件名。示例：

Rewritelog "C:\local\path\rewrite.log"

4.11RewriteLogLevel指令

这个指令设置日志的输出长度。默认值0表示不记日志，而最大的级别9则表示所有的动作都要记录。
使用使用较高的级别值可能会降低ISAPI_Rewrite的操作速度。我们建议你当你完成规则调试之后，通过设置日志级别为零来禁用日志。

4.12RewriteOptions指令

这个指令可以为ISAPI_Rewrite设置特定选项。当前只有惟一一个选项可用：inherit。
inherit：强迫当前配置从父级继承所有的选项和规则。这意味着来自父级配置的所有的规则将被再次执行，除非当前环境另有相应重写规则。

4.13RewriteCompatibility2指令

这一指令将激活与ISAPI_Rewrite 2.x版的兼容性，将一些2.X的规则正确地翻译为3.0版本的语法。这并不意味着ISAPI_Rewrite 3将开始懂得不经修改旧的语法。如果您有针对ISAPI_Rewrite 2.X的旧设计请使用ISAPI_Rewrite提供的翻译工具将这些旧规则转化为新的语法规则。
现在通过设置指令RewriteCompatibility2唯一改变的是，它将关闭网址常规前缀并删除查询字符串。 Apache的mod_rewrite将删除匹配的URL的查询字符串的这部分，相较之下ISAPI_Rewrite 2.X将匹配整个网址（包括查询字符串在内），而且[O]标记的意思将由该指令倒置。

4.14ErrorLog指令

这个指令设置存放ISAPI_Rewrite整体错误和消息的日志文件的名称。例如httpd.conf file load, .htaccess file load,等等
例：ErrorLog "C:local\path\error.log"

4.15LogLevel指令

这个指令设置一般日志的输出长度，跟它的重写过程无关。这里有一个level的可用值列表：emerg、alert、crit、error、warm、notice、info、debug。当前的ISAPI_Rewrite日志只记录错误信息。
设置LogLevel调试来解决配置文件中加载的问题。

4.16<VirtualHost>指令

<VirtualHost> ... </VirtualHost>标签用来对应用到特定虚拟主机里的指令进行分组。
addr的可用值为：
• 特定的IP地址
• 完整的域名
• 字符'*'可以匹配任何主机或者特定服务器的任何端口号。
例如：

RewriteEngine off
AllowOverride none
<VirtualHost onesite.com www.onesite.com>
RewriteEngine on
AllowOverride all
</VirtualHost> 

不要忘了在每个<VirtualHost>标签中包含RewriteEngine on指令，也不要将不能应用的规则封装进去。

4.17<Directory>指令

<Directory> ... </Directory>标签被用来对应用到特定文件系统目录以及子目录的指令进行分组。通配符?和*是可用的。正则表达式也是可用的，需要以~字符打头。
对目录路径参数必须小心：它们必须字面匹配用来访问文件的文件系统路径，用于某一特定<Directory>的指令并不适用于来自同一目录下通过不同的路径的文件访问，例如通过不同的符号链接。只有完整的文件路径是被允许使用的。
示例：

<Directory C:/inetpub/>
  AllowOverride None
</Directory>
<Directory C:/inetpub/home/>
  AllowOverride FileInfo
</Directory>
<Directory ~ "C:/inetpub/wwwroot/.*/[0-9]{3}">
  # ... directives here ...
</Directory>

不要忘了在每个<Directory>标签中包含RewriteEngine on指令，也不要将不能应用的规则封装进去。

4.18<DirectoryMatch>指令

<DirectoryMatch> ... </DirectoryMatch> 被用来封装一个只适用于指定的文件系统的目录和子目录的指令组。这个指令和<Directory ~> 语法相同。
示例：

<DirectoryMatch "^/www/(.+/)?[0-9]{3}">
   # ... directives here ... 
</DirectoryMatch> 

不要忘了在每个< DirectoryMatch>标签中包含 RewriteEngine on指令，也不要将不能应用的规则封装进去。

4.19<Files> 指令

<File>指令以文件名限定了封装的指令的作用域。filename参数必须包含一个文件名，支持?和*以及以~字符打头的正则表达式。
示例：

<Files index.*>
   # ... directives here ... 
</Files>
<Files ~ "\.(gif|jpe?g|png)$">
   # ... directives here ... 
</Files>

不要忘了在每个<Files>标签中包含RewriteEngine on指令，也不要将不能应用的规则封装进去。

4.20<FilesMatch>指令

<FilesMatch>指令的语法和_指令"><Files ~>语法完全一样。

<FilesMatch "\.(gif|jpe?g|png)$"> 

不要忘了在每个<FilesMatch>标签中包含RewriteEngine on指令，也不要将不能应用的规则封装进去。

4.21<Location>指令

<Location> ... </Location>标签用来将应用到特定URL或者虚拟路径的指令分组。<Location>将运算符完全从文件系统中分划出来，因此那些指令将不会用来控制对文件文件系统位置的访问。因为有几个不同的URL可能映射到相同的文件系统位置。
该URL-path是一个形式为“/path/”的虚拟路径。没有协议、主机名、端口号、查询请求字符串被包含在内。URL-path可以包含通配符?和*或者以~字符打头的正则表达式。
示例：

<Location /directory>
  # ... rules go here
</Location>
<Location />
   # ... more rules go here
</Location>

不要忘了在每个<Location>标签中包含RewriteEngine on指令，也不要将不需要用到的规则封套进去。

4.22<LocationMatch>指令

这个指令的语法和指令"><Location ~>正则表达式语法完全一样。
示例：

<LocationMatch "/(home|section)/bin">
   # ... rules go here
</LocationMatch> 

不要忘了在每个<LocationMatch>标签中包含RewriteEngine on指令，也不要将不能应用的规则封装进去。

示例

	RewriteEngine on
RewriteRule ^(.*?\.asp)/([^/]*)/([^/]*)(/.+)? $1$4?$2=$3 [NC,LP,QSA]

	RewriteEngine on
RewriteRule ^(.*?\.asp)~([^~]*)~([^~]*)(.*) $1$4?$2=$3 [NC,LP,QSA]

	RewriteEngine on
RewriteBase /
RewriteRule ^products/[^?/]*_(\d+)\.asp /productpage.asp?productID=$1 [QSA]

另一个更复杂的解决方案是创建一对一的映射文件，并用它来映射“our_super_tool”到127。该解决方案对一些有很多参数的长URL来说很有用，并允许你隐藏数字标识符。这URL看起来像是http://www.mysite.com/products/our_super_tool.asp。请注意“our_supper_tool”部分必须是产品的唯一标识，是它的标识符。下面是这种解决方案的一个示例：

RewriteEngine on
RewriteBase /
RewriteMap mapfile txt:mapfile.txt
RewriteRule ^products/([^?/]+)\.asp /productpage.asp?productID=${mapfile:$1}

而且你必需创建包含以下内容的mapfile.txt映射文件：

one_product       1
another_product   2
our_super_tool    127
more_products     335

这种方法的优点是：你可以使用它来组合十分复杂的URL转换，但是这是一个小例子，是这个指南中的题外之话。
使用IIS作为反向代理 假设你有运行IIS的互联网服务器以及几台后台服务器或者应用程序运行在其它平台或者机器上。这些服务器不能直接在互联网上阅览，但是你必须为他人提供访问这些服务器的渠道。这里有一个演示如何简单地将某个网站的完整内容映射到另一个运行了ISAPI_Rewrite的站点的文件夹的示例：

RewriteEngine on
RewriteBase / 
RewriteRule mappoint(.+) http://sitedomain$1 [NC,P]

藏匿文件扩展名： 虽然不可能将一个站点的所有的文件的扩展名都藏匿起来，但是我们可以使用ISAPI_Rewrite的文件检查功能来隐藏某些已知扩展名。这里有一个藏匿网站上.asp文件扩展名的规则示例：

RewriteEngine on
#Redirect extension requests to avoid duplicate content
RewriteRule ^([^?]+)\.asp$ $1 [NC,R=301,L]
#Internally add extensions to request
RewriteCond %{REQUEST_FILENAME}.asp -f 
RewriteRule (.*) $1.asp

仿真基于主机头的虚拟网站 例如你已经注册了两个域名www.site1.com和www.site2.com。现在你可以使用同一个物理站创建两个不同的站点了。这里是一个规则示例：

RewriteEngine on
#Fix missing trailing slash char on folders
RewriteRule ^([^.?]+[^.?/])$ $1/ [R,L]
#Emulate site1
RewriteCond %{HTTP:Host} ^(?:www\.)?site1\.com$
RewriteRule (.*) /site1$1 [NC,L,NS]
#Emulate site2
RewriteCond %{HTTP:Host} ^(?:www\.)?site2\.com$
RewriteRule (.*) /site2$1 [NC,L,NS] 

现在只要把你的站点分别放到/site1和/site2目录下就可以了。注意www.site1.com和www.site2.com这两个域名必须在IIS中被映射到这个网站里，从而使ISAPI_Rewrite能拦截到请求。
或者，你可以使用更多通用的规则，从而把任何请求都映射到与请求主机名同名的文件夹里。

RewriteEngine on
#Fix missing trailing slash char on folders
RewriteRule ^([^.?]+[^.?/])$ $1/ [R,L]
#Map requests to the folders
RewriteCond %{HTTP:Host} ^(www\.)?(.+)
RewriteRule (.*) /%2$1 [NS]

网站的目录名应该是这样子的：/somesite1.com，/somesite2.info，等等。
阻断内联图像（阻止盗链） 假如你有一些页面插入了http://www.mysite.com/下的gif图片。一些其它站点将通过网页超链接插入这些图片。这会给你的网站增加很多无用的通讯量，而且你希望阻止这种做法。
虽然用ISAPI_Rewrite不能100%地保护图片不被盗链（只有专门的反盗链产品才能做到它），你至少可以在浏览器发来HTTP引用头的时候限制这种情况。下面的规则可以让你只允许来自同一主机的引用页或者空地址访问到这些图片。

RewriteEngine on
RewriteCond %{HTTP:Host}#%{HTTP:Referer} ^([^#]+)#(?!http://\1).+
RewriteRule .*\.(?:gif|jpg|png) /block.gif [NC]

重定向非www的版本到www
如果你的网站同时可以通过两种形式的URL比如说http://helicontech.com和http://www.helicontech.com来访问到，那么最好将一种地址重定向到另一种地址里，来避免搜索引擎对重复内容做出的处罚。下面是一个能将所有的非www地址重定向到相应的www地址上去的301重定向规则。

RewriteEngine on
RewriteCond %{HTTPS} (on)?
RewriteCond %{HTTP:Host} ^(?!www\.)(.+)$ [NC]
RewriteCond %{REQUEST_URI} (.+)
RewriteRule .? http(?%1s)://www.%2%3 [R=301,L]

强制SSL或者非SSL到一个指定的位置
这里是一个演示如何将SSL强制转到指定的文件夹的示例。只要简单地把下面的规则放到该文件夹下的.htaccess文件里就可以了。

RewriteEngine on
#Fix missing trailing slash char on folders
RewriteRule ^([^.?]+[^.?/])$ $1/ [R,L]
#Redirect non-HTTPS to HTTPS
RewriteCond %{HTTP:Host} (.*)
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} (.*)
RewriteRule .? https://%1%2 [R,L]

而这个示例作用正好相反：将非SSL强制转到指定文件夹。

RewriteEngine on
#Fix missing trailing slash char on folders
RewriteRule ^([^.?]+[^.?/])$ $1/ [R,L]
#Redirect HTTPS to non-HTTPS
RewriteCond %{HTTP:Host} (.*)
RewriteCond %{HTTPS} on
RewriteCond %{REQUEST_URI} (.*)
RewriteRule .? http://%1%2 [R,L]

转移站点位置
当你把网站从一个域名移到另一个域名，或者从一个文件夹移动另一个文件夹里的时候，这是经常会遇到的问题。你希望将一个网站的所有请求重定向到另一个网站里，而且不丢失请求资源名以及参数。当你希望保留现有的网页的排名和外链接的时候，它是非常有用的。这个解决方案是在旧的网站服务器上使用ISAPI_Rewrite：

RewriteEngine on
#Permanent redirect to update old links
RewriteRule (.+) http://newserver.com$1 [R=301,L]

平衡负荷仿真
这个示例模拟某种DNS轮换负荷平衡技术。假设你有主站www.mysite.com和数台web服务器分别注册为www[1-9].mysite.com。如果你在主服务器上安装了ISAPI_Rewrite，你可以将初始的客户端请求重定向到几台特定服务器，从而在几台服务器之间随机摊开通讯量。一旦已重定向，客户端将一直使用这一台服务器。虽然这种解决方案并不非常理想，但是它确实能分摊你的通讯量并避免在维护会话状态方面发生的问题。
使用下面的规则来重定向客户端：

RewriteEngine on
RewriteMap hosts rnd:hosts.txt
RewriteCond %{HTTP:Host} (www)\.mysite.com [NC]
RewriteRule (.*) http://${hosts:%1}.mysite.com$1 [R,L]

下面是hosts.txt文件的内容

www www1|www2|www3|www4|www5|www6|www7|www8|www9

你还可以在Apeche文档里找到很多其它有用的例子。它们多数不需要修改就可以在ISAPI_Rewrite3里使用。

故障处理

	RewriteLogLevel 9
LogLevel debug

ISAPI_Rewrite 发布历史
发布 3.1.0.67
================
[筛选器功能] 增强映射文件的动态加载
[代理帮助文件错误]如果后端不设置内容长度头的话，并不会返回所有的响应。
发布 3.1.0.66
================

精简版的限制
ISAPI_Rewrite的精简版拥有相同的引擎和重写功能。但是也有下面这些限制：
? 不支持分布式.htaccess配置、目录以及网站级配置，只有一个精简版安装目录中的全局的httpd.conf配置能被载入。
? 不支持<VirtualHost>、<Directory>、<DirectoryMatch>、<Files>、<FilesMatch>、<Location> 以及<LocationMatch>这几个标签。
? 精简版中没有代理服务模块，因而所有的和代理服务功能相关的比如说RewriteProxy指令以及[P]标记都会被忽略。
? 精简版没有针对于虚拟主机环境的手工安装包
ISAPI_Rewrite精简版完全免费，它对开发或者测试目的以及只有几个网站而且不需要分布式配置或者代理功能的小型服务器来说是一个很好的解决方案

技术信息 ISAPI_Rewrite由四个部分组成：ISAPI筛选器、ISAPI扩展帮助、GUI管理器以及MMC嵌入式管理单元扩展。ISAPI_Rewrite筛选器和扩展都是用纯C++语言写的快速DLL模块。当安装ISAPI_Rwrite的时候， MMC嵌入式管理单元会被自动注册。ISAPI筛选器将安装在一个全局级别上，你不需要手工注册它。ISAPI扩展也会被安装并注册。
ISAPI_Rewrite管理器实用工具可以在没有安装MMC的系统中运行ISAPI_Rewrite MMC嵌入式管理单元。
Windows Vista以及Windows Server 2008系统中的ISAPI_Rewrite管理器实用工具(Helicon Manager.exe)要求管理员权限来执行，因为较小权限的用户没有权力读取IIS管理元库，而它对显示网站配置来说是必需的。如果用受限的帐号运行ISAPI_Rewrite管理器，你会得到登录管理员帐号的自动提示。
ISAPI_Rewrite筛选器已经有足够地快，因此不用担心它的性能。除非你的服务器运行在最大负荷之下。用户在响应时间或者CPU负荷方面几乎不能发现什么区别，但是如果用了很多的规则的话，服务器最大带宽可能掉下一点来。所以请注意你用的配置决定了性能。建议每个网站使用的规则不要超过100条。在多数情况下，可以利用RewriteMap来避免使用大量的规则。
该程序使用了Regex++ 库。
Regex++ (Version Boost 1.31)
Copyright ?1998-2004, Dr John Maddock

使用和传播许可
该使用许可覆盖了所有的现有版本的ISAPI_Rewite，包括ISAPI_Rewrite、ISAPI_Rewrite完全版、ISAPI_Rewrite精简版、ISAPI_Rewrite测试版，后面统称为ISAPI_Rewrite除非另有指明。
1.所有未明确授予的权利均由Helicon Tech保留。
2.所有的关于ISAPI_Rewrite的版权都由它的作者Helicon Tech独家保留。
3. Helicon Tech准予免费使用ISAPI_Rewrite精简版产品。
4. Helicon Tech准予免费试用ISAPI_Rewrite产品30天，当试用期结束时，请要么购买ISAPI_Rewrite，要么删除ISAPI_Rewrite产品。
5.未注册过的ISAPI_Rewrite试用版，可以在不被改动的前提下自由传播，除非有下例情况。任何个人或者公司都不用为在未得版权持有人书面许可的情况下传播ISAPI_Rewrite而付费。未经版权持有者的书面许可，未注册的试用版ISAPI_Rewrite不允许捆绑其它安装包。
6. ISAPI_Rewrite必须被原样传播，不提供任何形式的保证明示或暗示。你可以在你自己的磁盘上使用ISAPI_Rewrite。作者不为因为滥用本软件导致的数据丢失、损坏，或任何其他类型的损失承担责任。
7.你不得使用、复制、模仿、克隆、出租、出售、修改、反编译、反汇编以及其它任何反向工程，或者转让许可程序，或者任何许可程序的一个子集，除非本协议有提供。任何未经授权的使用将导致本许可自动终止。并可能导致刑事或民事起诉。
8.本许可协议的条款是在未来版本的ISAPI_Rewrite将会有所变化。
9.当你购买ISAPI_Rewrite时，将发给你“注册码”。这种“注册码”可以个人或者公司购买，并只在一台计算机上使用。如果您购买一个以上的ISAPI_Rewrite副本，发给你们的“注册码”只能在等于你购买的许可证数的计算机上使用。
10.您只能使用来自Helicom Tech以及与Helicom Tech有业务合作或者技术合作的公司的注册码。
11. 安装和使用ISAPI_Rewrite意味着接受这些条款及许可条件。
12. 如果您不同意本许可证的条款或违反本许可与您当地的法律规定，您必须从您的存储设备中删除ISAPI_Rewrite文件，并停止使用该产品。
13.我们坚持严格的隐私的准则，不会收集个人识别信息，除非是自愿提供的。
如果您有进一步的问题或意见，请访问我们的http://www.helicontech.com。
感谢你使用ISAPI_Rewrite。
Helicon Tech Corporation.

转自：asprain

一、页面和服务器控件处理

1、ASP.NET代码优化避免到服务器的不必要的往返行程

在某些情况下不必使用 ASP.NET 服务器控件和执行回发事件处理。例如，在 ASP.NET 网页中验证用户输入经常可在数据提交到服务器之前在客户端进行。通常，如果不需要将信息传递到服务器以进行验证或将其写入数据存储区，请避免使用导致到服务器的往返行程的代码，这样可以提高页的性能并改善用户体验。您也可以不执行整个往返行程，而是使用客户端回调从服务器中读取数据。

页面类实现ICallbackEventHandler接口，注册GetCallbackEventReference方法，也就是ajax的回调实现。

针对一次需要载入很多控件的页面(载入比较耗时的页面)，我们可以使用ajax技术来达到一定的页面访问性能提升。

2、ASP.NET代码优化使用 Page 对象的 IsPostBack 属性来避免对往返行程执行不必要的处理

如果您编写处理服务器控件回发处理的代码，有时可能需要代码仅在首次请求页时执行，而不是每次回发时都执行。根据该页是否是响应服务器控件事件生成的，使用 IsPostBack 属性有条件地执行代码。

将仅需要首次请求页面时执行的代码放在IsPostBack条件中运行。

3、ASP.NET代码优化只在必要时保存服务器控件视图状态

自动视图状态管理使服务器控件可以在往返行程中重新填充它们的属性值，而您不需要编写任何代码。但是，因为服务器控件的视图状态在隐藏的窗体字段中往返于服务器，所以该功能影响性能。了解在哪些情况下视图状态会有所帮助，在哪些情况下它影响页的性能，这样是有帮助的。例如，如果您将服务器控件绑定到每个往返行程上的数据，因为控件的值会在数据绑定期间用新值替换，所以保存的视图状态没有用处。在这种情况下，禁用视图状态可以节省处理时间并减少页的大小。

默认情况下，为所有服务器控件启用视图状态。若要禁用它，请将控件的 EnableViewState 属性设置为 false。

还可以使用 @ Page 指令禁用整个页的视图状态。当您不从页回发到服务器时，这将十分有用。

@ Control 指令中还支持 EnableViewState 属性以指定是否为用户控件启用视图状态。

查看视图状态的方法：

若要分析服务器控件在页中使用的视图状态的大小，请通过将 trace="true" 属性包含在 @ Page 指令中启用对该页的跟踪。然后在跟踪输出中，查看“控件层次结构”表的“Viewstate”列。

下面情况基本上可以禁用viewstate：

（1）页面控件 （.ascx）

（2）页面不回传给自身。

（3）无需对控件的事件处理。

（4）控件没有动态的或数据绑定的属性值（或对于每个postpack都在代码中处理）

4、ASP.NET代码优化除非有特殊的原因要关闭缓冲，否则使其保持打开状态

禁用 ASP.NET 网页的缓冲会导致大量的性能开销。

5、ASP.NET代码优化Server.Transfer和Response.Redirect的选择

Response.Redirect 简单地告诉浏览器访问另一个页面。Server.Transfer 有利于减少服务器请求，保持地址栏 URL 不变，允许你将 query string 和 form 变量传递到另一个页面，可以隐藏url中传递的参数。

Response.Redirect可以跨站点跳转，Server.Transfer只能同站点跳转。

微软ASP.NET代码优化建议：

使用 Transfer Server 对象或跨页发送的方法在同一个应用程序中的不同 ASP.NET 页之间重定向

如无特殊要求，应优先选择Server.Transfer进行页面跳转

ASP.NET代码优化二、数据访问

1、ASP.NET代码优化将 SQL Server 和存储过程用于数据访问

在 .NET Framework 提供的所有数据访问方法中，使用 SQL Server 进行数据访问是生成高性能、可缩放 Web 应用程序的推荐选择。使用托管 SQL Server 提供程序时，可通过尽可能使用编译的存储过程而不是 SQL 命令获得额外的性能提高。

（仅针对数据库选择SQL Server，数据库为其他的可以忽略此选项）

2、ASP.NET代码优化将 SqlDataReader 类用于快速只进数据游标

SqlDataReader 类提供了从 SQL Server 数据库检索的只进数据流。如果您可以在 ASP.NET 应用程序中使用只读流，则 SqlDataReader 类提供比 DataSet 类更高的性能。SqlDataReader 类使用 SQL Server 的本机网络数据传输格式从数据库连接直接读取数据。例如，当绑定到 SqlDataSource 控件时，通过将 DataSourceMode 属性设置为 DataReader，您将获得更好的性能。（使用数据读取器会导致某些功能的丢失。）另外，SqlDataReader 类实现 IEnumerable 接口，该接口也使您可以将数据绑定到服务器控件。

(仅针对数据库选择SQL Server，数据库为其他的可以忽略此选项)   MySql中对应MySqlDataReader，根据需要选择。

3、ASP.NET代码优化尽可能缓存数据和页输出

ASP.NET 提供了一些机制，它们会在不需要为每个页请求动态计算页输出或数据时缓存这些页输出或数据。另外，通过设计要进行缓存的页和数据请求（特别是在站点中预期将有较大通讯量的区域），可以优化这些页的性能。与使用 .NET Framework 的任何其他功能相比，适当地使用缓存可以更好地提高站点的性能。

在使用 ASP.NET 缓存时，应注意以下事项。首先，不要缓存太多项。缓存每个项都有内存开销。不要缓存容易重新计算和很少使用的项。其次，给缓存项分配的有效期不要太短。很快到期的项会导致缓存中不必要的周转，并且会导致额外的代码清除和垃圾回收工作。使用与“ASP.NET Applications”性能对象关联的“Cache Total Turnover Rate”（缓存总流通率）性能计数器，您可以监视缓存中由于项到期而导致的周转。高周转率可能说明存在问题，特别是当项在到期前被移除时。（这种情况有时称作内存压力。）

可以考虑把静态的、变化不大的或者不经常变化需要动态加载的内容放入控件中，使用缓存技术。

﹤%@ OutputCache Duration="100" VaryByParam="none" %﹥

4、ASP.NET代码优化适当地使用 SQL 缓存依赖项

ASP.NET 同时支持基于表的轮询和查询通知，具体取决于所使用的 SQL Server 的版本。所有 SQL Server 版本都支持基于表的轮询。在基于表的轮询中，如果表中的任何内容发生更改，所有侦听器都会失效。这可能导致应用程序中不必要的改动。建议不要将基于表的轮询用于具有许多频繁更改的表。例如，建议将基于表的轮询用于很少更改的目录表。建议不要将基于表的轮询用于订单表，订单表具有更频繁的更新。SQL Server 2005 支持查询通知。查询通知支持特定查询，从而减少在表更改时发送的通知数量。虽然它比基于表的轮询提供更好的性能，但是它无法扩展到适应数千个查询。

(仅针对数据库选择SQL Server，数据库为其他的可以忽略此选项)

5、ASP.NET代码优化使用数据源分页和排序而不是 UI（用户界面）分页和排序

DetailsView 和 GridView 等数据控件的 UI 分页功能可用于支持 ICollection 接口的任何数据源对象。对于每个分页操作，数据控件查询数据源的整个数据集并选择要显示的行，并放弃其余的数据。如果数据源实现 DataSourceView 并且 CanPage 属性返回 true，则数据控件将使用数据源分页而不是 UI 分页。在这种情况下，数据控件仅查询每个分页操作需要的行。因此，数据源分页比 UI 分页更高效。只有 ObjectDataSource 数据源控件才支持数据源分页。若要在其他数据源控件上启用数据源分页，必须从该数据源控件继承并修改其行为。

6、ASP.NET代码优化平衡事件验证的安全性受益和性能开销

从 System.Web.UI.WebControls 和 System.Web.UI.HtmlControls 类派生的控件可以验证事件是否源自该控件所呈现的用户界面。这样有助于防止控件响应伪造的事件通知。例如，DetailsView 控件可以防止 Delete（删除）调用（控件中本质上不支持该调用）的处理以及被操纵而删除数据。此验证会带来一定的性能开销。可以使用 EnableEventValidation 配置元素和 RegisterForEventValidation 方法控制此行为。验证的开销取决于页上的控件数量，并在几个百分点范围内。

强烈建议不要禁用事件验证。在禁用事件验证之前，应该确保不会构造任何可能对应用程序具有意外影响的回发。

7、ASP.NET代码优化，除非必要，否则避免使用视图状态加密

视图状态加密会阻止用户能够读取隐藏视图状态字段中的值。典型情况是在 DataKeyNames 属性中带有一个标识符字段的 GridView 控件。标识符字段是协调对记录的更新所必需的。由于不想要标识符对用户可见，因此可以加密视图状态。但是，加密对于初始化具有恒定的性能开销，并具有取决于被加密的视图状态大小的附加开销。加密为每次页加载而设置，因此在每次页加载时都会发生相同的性能影响。

8、ASP.NET代码优化使用 SqlDataSource 缓存、排序和筛选

如果 SqlDataSource 控件的 DataSourceMode 属性设置为 DataSet，则 SqlDataSource 能够缓存查询产生的结果集。如果以这种方式缓存数据，则控件的筛选和排序操作（使用 FilterExpression 和 SortParameterName 属性进行配置）将使用缓存的数据。在许多情况下，如果缓存整个数据集，并使用 FilterExpression 和 SortParameterName 属性进行排序和筛选，而不是使用带“WHERE”和“SORT BY”子句的 SQL 查询（对于这些查询，每个选择操作都要访问数据库），应用程序会运行得更快。
 

前段时间，由于学习网的 访问速度比较慢，所以研究了下如何优化asp.net的程序，在网上查了很多资料，最后总结了以下经验：

一、SqlDataRead和Dataset的选择

Sqldataread优点：读取数据非常快。如果对返回的数据不需做大量处理的情况下，建议使用SqlDataReader，其性能要比datset好很多。缺点：直到数据读完才可close掉于数据库的连接 (SqlDataReader 读数据是快速向 前的。SqlDataReader 类提供了一种读取从 SQL Server 数据库检索 的只进数据流的方法。它使用 SQL Server 的本机网络数据传输格式从数据库连接直接读取数据。DataReader需及时显式的close。可及时的释放对数据的连接。)

Dataset是把数据读出，缓存在内存中。缺点：对内存的占用较高。如果对返回的数据需做大量的处理用Dataset比较好些可以减少对数据库的连接操作。优点：只需连接一次就可close于数据库的连接

一般情况下，读取大量数 据,对返回数据不做大量处理用SqlDataReader.对返回 数据大量处理用datset比较合适.对SqlDataReader和Dataset的选择取决于程序功能的实现。

二、ExecuteNonQuery和ExecuteScalar

对数据的更新不需要返回 结果集，建议使用ExecuteNonQuery。由于不返回结果集可省掉网络数据传输。它仅仅返回受影响的行数。如果只需更新数据用ExecuteNonQuery性能的开销比较小。

ExecuteScalar它只返回结果集中第一行的第一列。使用 ExecuteScalar 方法从数据库中检索单个值（例如id号）。与使用 ExecuteReader 方法， 返回的数据 执行生成单个值所需的操作相比，此操作需要的代码较少。

只需更新数据用ExecuteNonQuery，单个值的查询使用ExecuteScalar

三、数据的绑定DataBinder

一般的绑定方法<%# DataBinder.Eval(Container.DataItem, "字段名") %>

用DataBinder.eval 绑定不必关心数据来源(Dataread或dataset)。不必关心数据的类型eval会把这个数据对象转换为一个 字符串。在底层绑定做了很多工作，使用了反射性能。正因为使用方便了，但却影响了数据性能。

对数据的绑定建议使用<%# ctype(Container.DataItem,DataRowView).Row["字段名"] %>。数据量大的时候可提高几倍的速 度。使用时注意两方面：

1.需在页面添加<%@ Import namespace="System.Data"%>.

2.注意字段名的大小写（要特别注意）。如果和查询的不一致，在某些情况下会导致比<%# DataBinder.Eval(Container.DataItem, "字段名") %>还要慢。如果想进一步提高速度，可采用<%# ctype(Container.DataItem,DataRowView).Row(0) %>的方法。不过其可读性不高。

四、使用存储过程

性能方面：存储过程提供 了许多标准sql语言中所没有的高级特性。其传递参数和执行逻辑表达式的功能，有助于应用程序设计者处理复杂任务。另 外，存储过程存储在本地服务器上，减少了执行该过程所需的网络传输宽带和执行时间。（存储过程已经对sql语句进行了预编译，所以其执行速度比在程序里执行sql语句快很多）

程序结构方面：从程序的 可扩展性看，使用存储过程会对程序以后的修改带来方便。比如数据库的结构改变了，只需修改相对应的存储结构，和程序中的调用部分即可。

五、大量查询时使用分页 查询

如果我们有大量的数据要 查询，但是显示的时候是一页一页的显示，这是我们可以用分页查询的功能，就是需要多少数据就查询多少数据，这样至少可以从两个方面优化速度：

1.        传输的数据少，可以 减少带宽的压力。

2.        由于查询的数据少， 可以减少数据库的查时间。

    六、EnableViewState(页面的视图状态)。如果无特殊要求设置为false。

他主要是用于维护页面的 UI 状态，Web 是没有状态的，ASP.NET 页面也没有状态，它们在到服务器的每个往返过程中被实例化、执行、呈现和处理，因此他的存在是要消耗 服务器的性能的，当然他的存在也可以减少我能很多的代码，因为很多控件的状态他帮我们维护了，在不需要维护状态的情况下完全可以禁用viewstate。

如下所示：

单个页面：<%@ Page EnableViewState="False" %>

所有的页面：在 web.config 中 <Pages EnableViewState="false" />

七、Html控件和服务器控件的选择

服务器控件带来的方便和 功能上的实现是html控件所不能比拟的。但是是以牺牲服务器端的资源来取得的。我个人建议：如果html控件达不到所要实现的功能，而且和一些脚本语言（如javascrpt/vbscript）结合也不能实现的话，才会选择服务器控件。

主要针对几个常用数据控件说明一下：

DataGrid：自带最强大的数据显示控件，内置了对数据的修改、删除、添加、分页等很多实用功能。如果你只需对 数据显示的话，尽量不要选择DataGrid（它把数据都存储在viewstate中），也不要使用自带 的分页功能，microsoft在自动分页的底层做了很多工作，虽然使用方便了，但性能开销大了。

DataList：比DataGrid功能少了很多。但自定义性强了很 多。特有的多行数据显示，给我们带来了很多方便。DataGrid能实现的功能，它基本能实现，所以建议使用它。

Repeater：功能最少，但自定义性非常强。如果只需对数据显示，建议使用。由于减少了很多功能，对服务器的性 能带来消耗最小。因此，如果是对数据显示的话，我基本上都是选择 Repeater然后DataList最后DataGrid 尽量选择html控件，能在客户端实现的功能就在客户端实现(熟练掌握javascript)，减少服务器的压力。数据控件选择顺序：Repeater、DataList、DataGrid 。

八、String和StringBuilder的比较

String类对象是不可改变的，对于String对象的重新赋值在本质上 是重新创建了一个String对象并将新值赋予该对象，其方法ToString对性能的提高并非很显著。

在处理字符串时，最好使 用StringBuilder类，其.NET 命名空间是System.Text。该类并非创建新的对象，而是通过Append，Remove，Insert等方法直接对字符串进行操作，通过ToString方法返回操作结果。

以上几点只是个人总结和 从网上摘抄的，其实asp.net的优化远不止这些，如果要做好他需要对.net的运行机制和对象的使用非常熟悉。当然还有一点是非常重要的，就是程序的性能，本来是几句代码可以完 成的结果写了一大段，结果是影响了整个页面的性能，这方面的优化得靠自己的基本功和经验来提高了。