IIS handles asp.net requests and asp.net page lifecycle descriptions

First, we need to make clear two very important concepts:
1, worker process (w3wp.exe). The worker process manages all requests from the client and responds. It is the core of the ASP.net application under IIS.
2, Application pool. It is the container for the worker process, and the IIS5 and previous versions of IIS do not have the concept of application pool. Each application pool corresponds to a worker process that maintains the mapping of application pool and worker process in the IIS metabase. This avoids the worker process that appears in the IIS5 (IIS5 is aspnet_wp.exe, which can only run one process at a time) crashes, application the whole crash situation.
The following things happen when a client makes a resource request to IIS:
1, server accepts the request
IIS6 distributes the request to application pool through the HTTP.sys in kernel mode (Kernel mode). This is not a random process that has been registered to the HTTP.sys when the application pool was created, so HTTP.sys will be sent directly to the corresponding application pool when the request arrives. Next, in user mode of IIS, Web Admin Services (WAS) made a request from HTTP.sys and distributed it to the application pool. Application pool directly passes the request to the worker process.
2, after the request is passed to the worker process, the worker process initializes the load asp.net ISAPI (Internet Server application program Interface), asp.net ISAPI and then loads the CLR to create a managed environment.
(Note: The ISAPI is just an interface that acts as an agent, and the primary capability is to find a handler for the suffix based on the suffix of the request URL)
The asp.net ISAPI is defined in Aspnet_isapi.dll, which itself runs in an unmanaged environment. ASP.net ISAPI begins a httpruntime, httpruntime calls the ProcessRequest method to begin processing the request. ProcessRequest the differences between IIS by creating different HttpWorkerRequest based on the iwrtype that the ISAPI passes in. Then the ProcessRequest method creates the HttpContext, and we use httpcontext.current to access it. After httpruntime created the HttpApplication object (IHttpHandler) using HttpApplicationFactory, All requests will be processed after the HttpModule is found by the corresponding HttpHandler. Before HttpApplicationFactory creates HttpApplication, Finds all the HttpModule registered in the config (Web.config and machine.config) file, loads the corresponding assembly based on the configuration information, creates the corresponding reflection by HttpModule, and adds the module to the HTTP Application in the _modulecollection filed. Our request for a application will eventually fall on a HttpApplication object. When a request arrives, the ASP. NET finds unused HttpApplication objects in the Httplication pool.
3, after the request passes through the HTTP pipeline, each request is sent to the relevant respective HTTPHANDLER,IIS request processing process.
HttpHandler is the endpoint of the HTTP pipeline, which generates output for each request. System.Web.UI.Page is such a typical httphandler, when we request an ASPX page, this httphandler generates HTML to send back to the client. Look at the signature of the page class:
public class Page:templatecontrol, IHttpHandler
{
}
As you can see, the page class is a HttpHandler.
The whole process is that when a client sends a resource request to the server, the request first arrives at the http.sys of IIS. The HTTP.sys then sends the application Pool of the request path accordingly. The application pool then sends the request into the worker Process (W3WP.exe) to load the ISAPI Extension. ISAPI creates a HttpRuntime object to process requests through HttpModule and HttpHandler. Then the page life cycle begins.
4, page life cycle begins
The main phases of the page life cycle include:
Page initialization (INIT): Server creation instance of server control
Load: The control instance is loaded into the Page object it defines
Pre-output: (PreRender) changes to the control are updated to prepare the output.
Save (SaveViewState): control's state information is saved.
Output page (Render): The server creates HTML markup for the control.
Processing (Dispose): The main job is to dispose, close the database connection, the release of file resources and so on.
Uninstalling (Unload): Destroying instances of server controls
Main events for page life cycle:
PreInit:
1. Check IsPostBack Properties
2. Dynamically set Master Page
3. Dynamic Settings Theme
4. Set the default value of the control (UniqueID, etc.)
5. Recreate the dynamic control (the initialization control), initialize the control's value
Init: This event occurs when all the controls are initialized and all skin settings are applied. It is used to read or initialize control properties. It can be used to register events for controls that are not indicated in some ASPX pages.
Initcomplete:use This event is for processing the tasks that require all initialization to be complete.
Preload: Loads the page's viewstate and all controls, and then processes all the postback data contained in the request instance.
Load: This event may be the most familiar of all. Note that the Page object recursively invokes the OnLoad event of the child control until the page and all child controls are loaded. This event is used primarily to set the value of the control's properties and to establish a database connection (usually not).
Control events: This is not much to say, mainly to handle the controls of events, such as Click. This also lets us know that every time we click a button, we actually have to execute the Load event before the Click event is performed, and we use it! IsPostBack to avoid unnecessary load logic.
LoadComplete: All the controls on the page are loaded and then executed, and for the time being ...
PreRender: This is the last event before the HTML is generated. The controls on each page have a prerender process. This is where you make the last change to the HTML results you want to output.
Savestatecomplete: All controls and pages have been saved before this time, and any changes to the page or control will not occur. I didn't think of what to do for a while.
Render: It's not an event but a method. The job is to write HTML back to the client browser.
UnLoad: This happens for every control in the page. In the control, use this event to do cleanup work, such as shutting down the database connection. Cleaning is done with the page itself, such as closing open files and database connections, or ending a log or other specified work.
It should be explained that each request creates an instance of a completely new page class, so the fields that you define on the page cannot be passed in the two request, and need to be stored using ViewState.
5, HttpHandler sends the result back to Iis,iis and sends the result back to the client browser according to the processing of the events in the page life cycle.
It is noteworthy that in this process the request will again pass HttpModule (registering a endrequest event).
At this point, the entire request ended.