
2006年9月4日
假设你的名字叫小不点,你住在一个大院子里,你的邻居有很多小伙伴,在门口传达室还有个看大门的李大爷,李大爷就是你的网关。当你想跟院子里的某个小伙伴玩,只要你在院子里大喊一声他的名字,他听到了就会回应你,并且跑出来跟你玩。
但是你不被允许走出大门,你想与外界发生的一切联系,都必须由门口的李大爷(网关)用电话帮助你联系。假如你想找你的同学小明聊天,小明家住在很远的另外一个院子里,他家的院子里也有一个看门的王大爷(小明的网关)。但是你不知道小明家的电话号码,不过你的班主任老师有一份你们班全体同学的名单和电话号码对照表,你的老师就是你的DNS服务器。于是你在家里拨通了门口李大爷的电话,有了下面的对话:
小不点:李大爷,我想找班主任查一下小明的电话号码行吗?
李大爷:好,你等着。(接着李大爷给你的班主任挂了一个电话,问清楚了小明的电话)问到了,他家的号码是211.99.99.99
小不点:太好了!李大爷,我想找小明,你再帮我联系一下小明吧。
李大爷:没问题。(接着李大爷向电话局发出了请求接通小明家电话的请求,最后一关当然是被转接到了小明家那个院子的王大爷那里,然后王大爷把电话给转到小明家)
就这样你和小明取得了联系。
至于DHCP服务器嘛,可以这样比喻:
你家院子里的居民越来越多了,传达室李大爷那里的电话交换机已经不能满足这么多居民的需求了,所以只好采用了一种新技术叫做DHCP,居民们开机的时候随机得到一个电话号码,每一次得到的号码都可能会不同。
你家门口的李大爷:就是你的网关
你的班主任:就是你的DNS服务器
传达室的电话交换机:就是你的DHCP服务器
同上,李大爷和王大爷之间的对话就叫做路由。
另:如果还有个小朋友叫做小暗,他住的院子看门的是孙大爷,因为小暗的院子刚盖好,孙大爷刚来不久,他没有李大爷和王大爷办公室的电话(李大爷和王大爷当然也没有他的电话),这时会有两种情况:
1、居委会的赵大妈告诉了孙大爷关于李、王两位大爷的电话(同时赵大妈也告诉了李、王关于孙的电话),这就叫静态设定路由
2、赵大妈病了,孙大爷自己到处打电话,见人就说:“我是小暗他们院子管电话的”,结果被李、王二位听到了,就记在了他们的通讯录上,然后李、王就给孙大爷回了个电话说:“我是小明(小不点)他们院子管电话的”,这就叫动态设定路由
然后有一天小不点要找小暗,结果自然是小不点给李大爷打电话说:“大爷,我找小暗”(这里省略了李大爷去查小暗电话的过程,假设他知道小暗的电话),李大爷一找通讯录:“哦,小暗的院子的电话是孙大爷管着的,要找小暗自然先要通知孙大爷,我可以通知王大爷让他去找孙大爷,也可以自己直接找孙,那当然是自己直接找孙方便了”,于是李大爷给孙大爷打了电话,然后孙大爷又把电话转到了小暗家。
这里李大爷的通讯录叫做路由表。
李大爷选择是自己直接找孙大爷还是让王大爷帮忙转接叫做路由选择。
李大爷之所以选择直接找孙大爷是有依据的,因为他直接找孙大爷就能一步到位,如果要王大爷转接就需要两步才能完成,这里的“步”叫做“跳数”,李大爷的选择遵循的是最少步骤(跳数)原则(如果他不遵守这个原则,小不点可能就会多等些时间才能找到小暗,最终结果可能导致李大爷因工作不力被炒鱿鱼,这叫做“延时太长,选路原则不合理,换了一个路由器”)
当然,事情总是变化的,小不点和小明吵架了,这些天小不点老是给小暗打电话,小明心里想:“操,他是不是在说我坏话啊?”于是小明决定偷听小不点和小暗的通话,但是他又不能出院子,怎么办呢?小明做了这样一个决定:
首先他告诉自己院里管电话的王大爷说:“你给李大爷打个电话说小暗搬到咱们院子了,以后凡是打给他的电话我来接”,王大爷没反映过来(毕竟年纪大了啊!)就给李大爷打了电话,说:“现在我来管理小暗的电话了,孙已经不管了”,结果李大爷就把他的通讯录改了,这叫做路由欺骗。
以后小不点再找小暗,李大爷就转给王大爷了(其实应该转给孙大爷的),王大爷收到了这个电话就转给了小明(因为他之前已经和小明说好了),小明收到这个电话就假装小暗和小不点通信。因为小明作贼心虚,害怕明天小不点和小暗见面后当面问他,于是通信断了之后,又自己以小不点的名义给小暗通了个电话复述了一遍刚才的话,有这就叫数据窃听。
再后来,小不点还是不断的和小暗联系,而零落了小明,小明心里嘀咕啊:“我不能总是这样以小暗的身份和小不点通话啊,外一有一天露馅了怎么办!”于是他想了一个更阴险的招数:“干脆我也不偷听你们的电话了,你小不点不是不给我打电话吗!那我让你也给小暗打不了,哼哼!”,他怎么做的呢?我们来看:
他联系了一批狐朋狗友,和他们串通好,每天固定一个时间大家一起给小暗院子传达室打电话,内容什么都有,只要传达室的孙爷爷接电话,就会听到“打雷啦,下雨收衣服啊!”、“人是人他妈生的,妖是妖他妈生的”、“你妈贵姓”等等,听的脑袋都大了,不听又不行,电话不停的响啊!终于有一天,孙爷爷忍不住了,大喊一声:“我受不了拉!!!!”,于是上吊自杀了!
这就是最简单的DDOS攻击,孙爷爷心理承受能力弱的现象叫做“数据报处理模块有BUG”,孙爷爷的自杀叫做“路由器瘫痪”。如果是我,就会微笑着和他们拉家常,例如告诉他们“我早就听了天气预报,衣服10分钟前已经收好了”或者“那你妈是人还是妖”或者“和你奶奶一个姓”等等,我这种健全的心理叫做“健壮的数据报处理,能够抵御任何攻击”
孙爷爷瘫了之后,小不点终于不再给小暗打电话了,因为无论他怎么打对方都是忙音,这种现象叫做“拒绝服务”,所以小明的做法还有一个名字叫做“拒绝服务攻击”。
小明终于安静了几天,...
几天后,小明的院子来了一个美丽的女孩,名字叫做小丽,小明很喜欢她(小小年纪玩什么早恋!)可是小丽有个很帅的男朋友,小明干瞪眼没办法。当然这里还是要遵循上面的原则:小丽是不能出院子的。那个男的想泡小丽自然只能打电话,于是小明又蠢蠢欲动了:
还记得王爷爷是院子的电话总管吗?他之所以能管理电话是因为他有一个通讯录,因为同一个院子可能有2个孩子都叫小明,靠名字无法区分,所以通讯录上每一行只有两项:
门牌 电话
一号门 1234567 (这个是小明的)
二号门 7654321 (这个是小丽的)
......
王爷爷记性不好,但这总不会错了吧(同一个院子不会有2个“二号门”吧)?每次打电话人家都要说出要找的电话号码,然后通过通讯录去院子里面敲门,比如人家说我找“1234567”,于是王爷爷一比较,哦,是一号门的,他就去敲一号门“听电话”,如果是找“7654321”,那他就找二号门“听电话”。
这里的电话号码就是传说中的“IP地址”
这里的门牌号就是传说中的网卡的’MAC‘地址(每一块网卡的MAC地址都是不一样的,这是网卡的制造商写死在网卡的芯片中的)
小明心里想“奶奶的,老子泡不到你也别想泡”,于是他打起了王爷爷通讯录的主意,经过细心的观察,周密的准备,他终于发现王爷爷有尿频的毛病(毕竟是老人啊...),终于在一个月黑风高的白天,王爷爷去上厕所了,小明偷偷的摸进传达室,小心翼翼的改了王爷爷的通讯录......
过了几天,小丽的男朋友又给小丽打来了电话,对方报的电话是“7654321”,王爷爷一看通讯录,靠:
门牌 电话
一号门 1234567 (这个是小明的)
一号门 7654321 (注意:这个原来是小丽的,但是被小明改了)
......
王爷爷不知道改了啊,于是就去找一号门的小明了,小明心里这个美啊,他以小丽父亲的口吻严厉的教训了那个男的和小丽之间不正当的男女关系,结果那个男的恭恭敬敬的挂了电话。当然小丽并不知道整个事情的发生...
这里小明的行为叫做“ARP欺骗”(因为在实际的网络上是通过发送ARP数据包来实现的,所以叫做“ARP欺骗”),王爷爷的通讯录叫做“ARP表”
这里要注意:王爷爷现在有两个通讯录了,一个是记录每个院子传达室电话的本本,叫做“路由表”,一个是现在说的记录院子里面详细信息的本本,叫做“ARP表”。
有句命言是“人们总是在追求完美的,尽管永远也做不到”(请记住这句话,因为这是一个大名人--也就是我,说的)
王爷爷的制度中有一条是这么写的“每个月要重新检查一下门牌号和电话的对应本(也就是ARP表)”,这个动作叫做“刷新ARP表”,每个月的时间限制叫做“刷新ARP表的周期”。这样小明为了让那个男的永远不能找到小丽,之后每个月都要偷偷改一次那个通讯录,不过这样也是不得不做的事啊!
补充一点,小明是很聪明的,如果通讯录(ARP表)被改成了这样:
门牌(MAC) 电话(IP)
一号门 1234567 (这个是小明的)
二号门 1234567 (注意:这个被小明改了,但是他一时头晕改错了)
......
就会是计算机就会弹出一个对话框提示“出现重复的IP地址”,最终会导致王爷爷不知所措,于是通知一号门和二号门,你们的电话重复了。这样小丽就知道有人在破坏她的好事,这个现象叫做“骗局被揭穿了”
小不点知道了小明偷听他和小暗的电话,于是就和小暗约定好了密码。小不点在家里把要说的加密了之后告诉小暗。土豆-〉星期三,地瓜-〉请客,笨蛋-〉小不点家。于是小不点告诉小暗:土豆笨蛋地瓜。小明听了???不懂。。。。郁闷了。。。这是加密。
除此之外,小丽也知道了小明改他家的电话号码了。于是王爷爷就登门一个一个把电话和门牌号记下来。并且藏起来不允许外人修改,只能自己有钥匙(密码)。这是ip地址和MAC地址绑定。当有人改了电话号码的时候,就得找王爷爷改。麻烦是麻烦了,但是安全了。不过小明偷偷的把王爷爷的钥匙偷配了一把(盗窃密码成功),于是他还可以修改。这样么,就这样了。
posted @
2006-09-04 20:16 阿成 阅读(67) |
评论 (0) |
编辑 收藏
版权所有,转载请声明出处
zhyiwww@163.com
在读我自己的认识之前
,
我们先来看一下
servet
的结构图
:
以下是我自己的一点浅见:
①
Servlet
在初始化的时候
,
是通过
init(ServletConfig config)
或
init()
来执行的。
ServletConfig
是一个接口,它怎样传递给他一格对象来进行初始化呢?其实,是这个对象是由
servlet
容器来实例化的,由容器产生一格
ServletConfig
的实现类的对象,然后传递给
Servlet
结论:
ServletConfig
由容器实例化
②
我们有些时候可能在
Servlet
初始化时给它一些固定的配置参数,那么这些参数是怎样传递到
Servlet
呢?
其实,我们在
web.xml
中给
servlet
配置启动参数,在容器对
servlet
进行初始化的时候,会收集你所配置的参数,记录在
ServletConfig
的实现类中,所以你才可以通过
ServletConfig
对象的
public String getInitParameter(String name);
或
public Enumeration getInitParameterNames();
方法来取得你已经配置好的参数,也就是说,你对
servlet
的配置都已经记录在
ServletConfig
对象中了。
结论:你对
Servlet
的配置,在
Servlet
的初始化时都由容器来收集并且记录到
ServletConfig
的实现类中。
③
我们来看一个
Servlet
的配置
<servlet>
<servlet-name>index</servlet-name>
<servlet-class>org.zy.pro.sw.servlet.IndexServlet</servlet-class>
<init-param>
<param-name>dbconfig</param-name>
<param-value>/WEB-INF/dbconfig.xml</param-value>
</init-param>
</servlet>
在此,我们实现对数据库的配置文件的加载。
当
Servlet
初始化完成后,我们可以通过
String dbconf=this.getServletConfig().getInitParameter("dbconfig")
来取得我们的配置的参数的值。
但是,我们仅能得到一个配置的字符串。之后我们可以通过配置文件取得我们的数据库的配置参数,然后对数据库进行初始化。
其实我们也可以通过传递一个类的名字串,然后再实例化。
<init-param>
<param-name>dbconfig</param-name>
<param-value>org.zy.util.db.DBUtil</param-value>
</init-param>
我们先取得配置参数:
String dbconf=this.getServletConfig().getInitParameter("dbconfig")
;
然后通过
Class.forName(dbconf).getInstance();
来实例化对象,就可以实现对数据库的调用了。
结论:在
web.xml
中对
Servlet
的初始化,只能传递字符串类型的数据
④
ServletContext
ServletContext
是负责和
Servlet
的上文和下文交互,上面和
Servlet
容器交互,下面和
Servlet
中的请求和相应进行交互。
在
ServletConfig
中,
public ServletContext getServletContext();
方法实现取得当前
ServletContext
的对象。
你可能要问,
ServletContext
是一个接口,那么你如何取得他的对象呢?
其实这个问题和
ServletConfig
相同,都是在
Servlet
进行初始化的时候产生的对象,是由容器来初始化的。
posted @
2006-09-04 17:25 阿成 阅读(134) |
评论 (0) |
编辑 收藏
Spring本身有ApplicationEvent和ApplicationListener,ApplicationContext可以发布ApplicationEvent,然后ApplicationListener监听event并做出相应动作。但是这里的ApplicationEvent有个陷阱,它的传播范围和当前的ApplicationContext的级别有关,并不是系统中所有的ApplicationListener都可以收到所有的Event。
假设当前系统为一个典型的Struts+Spring+Hibernate系统,那么系统中至少会有两个ApplicationContext存在,一个时root ApplicationContext,一个是Servlet的ApplicationContext。root ApplicationContext中包含你所有在webApplicationContext.xml中定义的bean,Servlet的ApplicationContext则包含有所有在action-servlet.xml中定义的bean,
需要注意的是root context中的bean是无法看到servlet context中的bean的。
而在servlet context中的ApplicationListener也无法收到root context发布的ApplicationEvent。
http://sweetriver.spaces.live.com/blog/cns!367370EB9A9B2807!129.entry
posted @
2006-09-04 09:10 阿成 阅读(248) |
评论 (0) |
编辑 收藏