ASP.NET页面生命周期总结(1)

图解:1)

 

ASP.NET页面生命周期总结(1)

 

浏览器   把用户的操作封装成一个请求通过socket发送到后台服务器。

后台服务器:首先有个内核模块Http.sys 针对每个应用程序池都有一个请求队列。然后请求到达http.sys之后,就把请求放到相应请求的队列池子里面去。 完成这些步骤后通知w3svc服务,由w3svc服务负责触发‘工作进程’,告诉工作进程已经内核当中有一个请求去取一个请求进行处理。拿到请求的报文之后,工作进程开始处理,工作进程分成两种情况 :

1.静态文件(读取出来直接封装成响应的报文然后返回给客户端,PS:返回给客户端这个过程不是由工作进程直接进行交互的,而是工作进程把响应报文交给http.sys内核模块,内核模块再把响应报文发给客户端

2.如果是动态网页:比如请求的是a.aspx这时候就会启动asp.net应用程序池,这过程中不是直接启动的,而是走了一个aspnet_isapi.dll动态链接库不叫程序集了,由cc++写的,这内部实现了iis内部定义的协议接口),请求到达工作进程之后,工作进程审核一下,如果是静态文件就自己处理,如果是动态文件,把请求发到aspnet_isapi.dllasp.net扩展模块:负责启动asp.net运行时,包括clr加载都是由它进行做这个工作的)进行处理)。此时再请求.netFramework运行时。当.net Framework启动之后,它还有一个职责把请求报文传递到.net Framework运行时里面去(或者说传递到托管的环境里面去) 

此时是由ISAPIRuntime.PR(这个PR方法是用来处理当前请求的)接口来负责aspnet_isapi.dll非托管模块和托管模块进行接洽 

ISAPIRuntime.PR()  里面有一个参数 ecb→句柄,通过这个句柄可以拿到当前请求的报文,也可以通过ecb句柄通过响应报文返回给非托管模块。也就是说ecb句柄才是真正连接托管和非托管的路口。

在这个方法内部把ecb封装成了HttpWorkRequest对象。这时候HttpWorkRequest就包含了请求响应两个部分。

虽然已经帮我们封装成了两个简单的部分,但这样还是太原始。因此微软内部又对此进行了再封装,于是把HttpWorkRequest对象继续传到HttpRuntime.PR()方法,这个PR方法把HttpWorkRequest对象传递到HttpRuntiome.PR(work)方法里面,而在这个方法里面就把workRequest对象封装成了现在用的HttpContext这就是上下文的由来。所以说HttpContext就是通过ecb产生出来的。 

这个时候HttpRuntime内部就通过HttpApplication.Factory工厂创建一个HttpApplication对象(这个对象就是负责整个asp.net模型的运作的最基本的一个类,也是最重要的一个类)

 

下面由HttpApplication负责处理asp.net模型的运作:(图2)

ASP.NET页面生命周期总结(1)

Asp.net模型是一个管道模型,管道模型当中有23个步骤,19公开的事件 。这事件依次的被执行。事件也算是步骤。httpContext会随着管道依次的往下走,整个管道流动的是一个对象, 其中第7个事件和第8个事件之间根据请求地址创建一般处理程序或者是页面对象,在第11和第12事件之间执行对象的PR方法,执行PR方法之后,继续往下流动。最后全部到执行完了之后,返回响应内容,同样也是到达内核模块,再向客户端发送响应报文。

 

 

附注:

 

Page_Load是在页面的PR方法里面执行的,页面的PR方法就是页面的生命周期 

PR方法就是Process Request方法

 

托管:

  c#\vb.net等等语言通过编译器生成的程序集exedll),CLR加载程序集 然后通过JIT即使编译器转成机器码再交给操作系统内核 这一类就成为托管程序。

IL是一个统一的标准,所以也正是因为IL成就了.net平台

.net平台特点 :跨平台、跨语言   java也是跨平台跨语言,两者都是生成了IL中间语言

 

非托管:

c|c++|VB…PS:这里的c|c++|vb..是原生程序)通过编译器直接生成的exe 直接交给操作系统内核,操作系统内核可以直接解析并且执行叫做非托管程序

ASP.NET页面生命周期总结(1),布布扣,bubuko.com

ASP.NET页面生命周期总结(1)

上一篇:02_Linux实操篇


下一篇:Linux-----文件夹直接拖动到linux中丢失文件的解决方案