构建高性能ASP.NET站点之减少不必要的请求

  前言:本篇的一些内容比较的有意思,总结了可能平时大家可以注意到的一些优化点,而且非常的实用。

  本篇的议题如下:

  识别和分析服务端的性能瓶颈(上)

  内存(前篇)

  缓存(前篇)

  CPU(后篇)

  处理请求线程(后篇)

  提高性能的一些简单改进措施(下)

  部署优化(前篇)

  减少不必要回传(前篇)

  减少不必要的请求(后篇)

  搜索引擎问题

  热链接问题

  验证码(CAPTCHA)

  网络刮刀

  服务端的要处理的请求越多,无疑服务端的压力也就越大,尤其是有些请求需要访问一些比较昂贵的资源,例如数据库,服务端的文件等。但是我们必须知道,在到达服务端的请求中,有些请求时我们希望的,例如网站的用户的请求,有些请求其实是不必要,甚至是我们不想要的,为此,我们要避免这样的请求,节省服务端的资源,从而提高性能。

  搜索引擎

  首先来看看有关搜索引擎的问题。

  然后搜索引擎爬到我们的站点是一件好的事情,很多的SEO可以进行,推广站点。同时,在站点中,有些文件或者资源比较的私密,或者我们不希望被搜索引擎请求和收录的,因为每次搜索引擎在请求这些资源的时候,就是发送请求到我们的站点服务器,势必会加重服务器的负载。

  不需要被搜索引擎请求的文件一般如下:

  1. 图片资源

  2. Js脚本,css等

  3. 一些需要身份验证或者授权才能看的页面(如果页面需要验证之后才能看,搜索引擎收录了也作用不大)

  我们可以设置一下,告诉搜索引擎的蜘蛛程序如何爬我们的站点。

  步骤如下:

  1. 在站点的根目录下面,创建一个robots.txt的文件。

  2. 写入文件。如果我们希望阻止所有的搜索引擎来爬我们的站点的页面,那么就可以在文件中写入下面的配置:

  User-agent: *

  Disallow: /

  如果希望阻止搜索引擎爬某个文件夹,可以配置如下:

  User-agent: *

  Disallow: /images/

  Disallow: /js/

  Disallow: /css/

  Disallow: /private/

  更有趣的是:对于某些搜索引擎,我们还可以改变他们的蜘蛛程序爬我们站点的频率,设置如下:

  User-agent: *

  Crawl-delay: 10

  大家可以去上网找下一些如何影响Google,百度等蜘蛛程序的设置。

  热链接问题

  就是在A网站上面显示一个来自B网站的图片链接。例如我们在自己的站点上面有一个链接如下:img src=http://www.xxx.com/yyy.gif/,那么在别人在浏览我们的站点的时候,就回去别人的那个站点(http://www.xxx.com/yyy.gif)去请求这个图片,那么势必会消耗他们的服务器的资源。发过来,如果别人在他们的站点上采用了我们的图片或者其他的链接资料,那么用户在浏览别人的站点的时候就会消耗我们站点的服务端资源和带宽。

  为一个组件就可以阻止这种情况的发生:http://www.iis.net/community/default.

aspx?tabid=34i=1288g=6.大家去看看。

  验证码(CAPTCHA)

  我们常常在站点中加入一些验证码的功能来防止网络注册机。一般是生成一张有文字的图片,然后根据验证用户输入的文字和图片中的文字是否一样来判断此时的用户是人还是注册机。

  通过验证码阻止了注册机随意的消耗站点资源(如果没有验证码,注册机可以不断的注册信息,大小服务器和数据库资源,而且产生很多的垃圾数据)。

  我们自己写生成验证码的程序,一般通过GDI+来做,同时也可以采用一些第三方的库实现,例如:reCAPTCHA: http://recaptcha.net/,大家上网找下,很多的。

  网络刮刀(Scrapers)与Dos

  这个问题必须引起重视。如果我们的站点上面有很多的有用的信息,那么别人可能就可能开发一个程序来到我们的站点抓取信息,然后把这些内容放到自己的站点上面。例如,很多的内容型的站点每天都从博客园的首页上面来抓取信息,然后放到他们的站点上,增加他们的访问量。

  本来站点被搜索引擎抓就有点消耗性能了,如果还被很多的这样的网络刮刀来抓内容,对站点的性能影响可想而知。

  如果那些网络刮刀程序的的IP地址变化不频繁,而且请求我们站点的频率比较的由规律,那么我们就可以采用一些代码的方式来防止这样的请求。例如,我们可以监测:同一个IP是否在20min之内发送了100个请求,如果是,我们就推测:可能是别人在抓我们的站点内容,我们就拒绝这个IP的请求。

  当然了,上面只是一些简单的方法,对于一些复杂的Dos攻击,上面的监测代码基本没有作用。因为Dos攻击中,攻击的IP地址是变化的。

  下面我们就写一些代码来防止简单的网络刮刀程序和简单的Dos攻击。基本的思想就是:如果在给定的时间段内,如果某个用户的请求很多,超过了一定的数量,那么我们就认为这个用户可能是网络刮刀程序,然后就拒绝下面的请求,一段时间之后,再次允许这个从这个IP发出的请求。

  下面的代码中:假设如果一个用户在5秒之内发出了100个请求,那么我们就认为这是网络刮刀程序或者是网站的攻击者。当然,我们还考虑这个发送请求的用户是否是搜索引擎的蜘蛛程序。(下面的代码只是简单作为演示,不是实际生产的代码,抛砖引玉)

1. private const int intervalSeconds = 30;

2. private const int maxRequestsInInterval = 5;

  如果认为这个用户是攻击者,那么我们就阻止用户的请求,阻止时间是20秒

1. private const int blockedPeriodSeconds = 20;

  下面,我们创建一个类来描述一个访问者的信息。如下:

1. private class VisitorInfo

2. {

3. public int nbrHits;

4. public bool blocked;

5.

6. public VisitorInfo()

7. {

8. nbrHits = 1;

9. blocked = false;

10. }

11. }

  在BotDefence类中加入一个方法IsBotAttach来判断一个请求是否是攻击性的请求。如下:

1. public static bool IsDosAttack()

2. {

3. string visitorIP = HttpContext.Current.Request.UserHostAddress;

4.

5. VisitorInfo visitorInfo = (VisitorInfo)HttpContext.Current.Cache[visitorIP];

6. if (visitorInfo == null)

7. {

8. HttpContext.Current.Cache.Insert(

9. visitorIP, new VisitorInfo(), null,

10. DateTime.Now.AddSeconds(intervalSeconds),

11. System.Web.Caching.Cache.NoSlidingExpiration);

12. }

13. else

14. {

15. if (visitorInfo.blocked)

16. {

17. return true;

18. }

19.

20. visitorInfo.nbrHits++;

21. if (visitorInfo.nbrHits   maxRequestsInInterval)

22. {

23. visitorInfo.blocked = true;

24. HttpContext.Current.Cache.Insert(

25. visitorIP, visitorInfo, null,

26. DateTime.Now.AddSeconds(blockedPeriodSeconds),

27. System.Web.Caching.Cache.NoSlidingExpiration);

28. return true;

29. }

30. }

31. return false;

32. }

  上面的代码都是自解释的,很容易看懂,就不赘述了。

时间: 2024-09-14 02:23:33

构建高性能ASP.NET站点之减少不必要的请求的相关文章

一起谈.NET技术,构建高性能ASP.NET站点之减少不必要的请求

前言:本篇的一些内容比较的有意思,总结了可能平时大家可以注意到的一些优化点,而且非常的实用. 本篇的议题如下: 识别和分析服务端的性能瓶颈(上) 内存(前篇) 缓存(前篇) CPU(后篇) 处理请求线程(后篇) 提高性能的一些简单改进措施(下) 部署优化(前篇) 减少不必要回传(前篇) 减少不必要的请求(后篇) 搜索引擎问题 热链接问题 验证码(CAPTCHA) 网络刮刀 服务端的要处理的请求越多,无疑服务端的压力也就越大,尤其是有些请求需要访问一些比较昂贵的资源,例如数据库,服务端的文件等.但

构建“.NET研究”高性能ASP.NET站点之减少不必要的请求

前言:本篇的一些内容比较的有意思,总结了可能平时大家可以注意到的一些优化点,而且非常的实用. 本篇的议题如下: 识别和分析服务端的性能瓶颈(上) 内存(前篇) 缓存(前篇) CPU(后篇) 处理请求线程(后篇) 提高性能的一些简单改进措施(下) 部署优化(前篇) 减少不必要回传(前篇) 减少不必要的请求(后篇) 搜索引擎问题 热链接问题 验证码(CAPTCHA) 网络刮刀 服务端的要处理的请求越多,无疑服务端的压力也就越大,尤其是有些请求需要访问一些比较昂贵的资源,例如数据库,服务端的文件等.但

【原创】构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(下前篇)—简单的优化措施

原文:[原创]构建高性能ASP.NET站点 第六章-性能瓶颈诊断与初步调优(下前篇)-简单的优化措施 构建高性能ASP.NET站点 第六章-性能瓶颈诊断与初步调优(下前篇)-简单的优化措施     前言:本篇给出一些在部署ASP.NET站点时采用的简单的优化措施.同时很也非常的感谢朋友对昨天发的文章的支持,本篇的内容不多,也比较的简单!         本篇议题如下:       识别和分析服务端的性能瓶颈(上)    内存(前篇)    缓存(前篇)     CPU(前篇)    处理请求线程

【原创】构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测CLR性能

原文:[原创]构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)-托管资源优化-监测CLR性能 构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)-托管资源优化-监测CLR性能     前言:在上一篇文章中讲述了一些垃圾回收的一些知识,本篇就讲述如何来监测CLR是否导致了一些性能问题.    本篇的议题如下: 内存问题概述(前篇) 托管资源优化(前篇)          对象的生命周期(前篇)          对象的"代"(前篇)          大

【原创】构建高性能ASP.NET站点 第五章—性能调优综述(中篇)

原文:[原创]构建高性能ASP.NET站点 第五章-性能调优综述(中篇) 构建高性能ASP.NET站点 第五章-性能调优综述(中篇) 前言:本篇主要讲述用一些简单的工具来分析一些与站点性能有关的数据,在上一篇文章中,我们讨论了一下性能调优的一般过程,本篇就开始介绍一些方法和工具,让大家快速的入门.      系列文章链接: 构建高性能ASP.NET站点 开篇 构建高性能ASP.NET站点之一 剖析页面的处理过程(前端) 构建高性能ASP.NET站点之二 优化HTTP请求(前端) 构建高性能ASP

【原创】构建高性能ASP.NET站点之三 细节决定成败

原文:[原创]构建高性能ASP.NET站点之三 细节决定成败 构建高性能ASP.NET站点之三 细节决定成败   前言:曾经就因为一个小小的疏忽,从而导致了服务器崩溃了,后来才发现:原来就是因为一个循环而导致的,所以,对"注意细节"这一说法是深有感触.     系列文章链接: 构建高性能ASP.NET站点 开篇 构建高性能ASP.NET站点之一 剖析页面的处理过程(前端) 构建高性能ASP.NET站点之二 优化HTTP请求(前端) 构建高性能ASP.NET站点之三 细节决定成败 构建高

【原创】构建高性能ASP.NET站点 开篇

原文:[原创]构建高性能ASP.NET站点 开篇   构建高性能ASP.NET站点 开篇   前言:有段时间没有写ASP.NET的东西了,心里总是觉得缺少了什么,毕竟自己对ASP.NET还是情有独钟的. 在本系列文章中,准备比较全面的讲述ASP.NET的性能的优化,从前台到后台,以后本列文也看作为大家的一个手册来查询!     系列文章链接: 构建高性能ASP.NET站点 开篇 构建高性能ASP.NET站点之一 剖析页面的处理过程(前端) 构建高性能ASP.NET站点之二 优化HTTP请求(前端

【原创】构建高性能ASP.NET站点之二 优化HTTP请求(前端)

原文:[原创]构建高性能ASP.NET站点之二 优化HTTP请求(前端) 构建高性能ASP.NET站点之二 优化HTTP请求(前端) 前言: 这段时间比较的忙,文章写不是很勤,希望大家谅解. 上一篇文章主要讲述了请求一个页面的过程,同时也提出了在这个过程中的一些优化点,本篇就开始细化页面的请求过程并且提出优化的方案.同时,在上篇文章中,不少朋友也提出了一些问题,在本篇中也对这些问题给出了回答!     系列文章链接: 构建高性能ASP.NET站点 开篇 构建高性能ASP.NET站点之一 剖析页面

【原创】构建高性能ASP.NET站点之一 剖析页面的处理过程(前端)

原文:[原创]构建高性能ASP.NET站点之一 剖析页面的处理过程(前端) 构建高性能ASP.NET站点之一 剖析页面的处理过程(前端) 前言:在对ASP.NET网站进行优化的时候,往往不是只是懂得ASP.NET就足够了的. 在优化的过程中,一般先是找出问题可能存在的地方,然后证明找出的问题就是要解决的问题,确认之后,在进行一些措施.系列文章在结构上的安排是这样的:先讲述前端的调优,我会在文章的标题后面标上"前端",如果是后台代码的调优,我会在标题上标上"后端",如