IIS handles Asp.net requests and Asp.net page lifecycle instructions

First of all, let's clear up two very important concepts:
1, worker process(w3wp.exe). worker process manages all requests from clients and gives responses. It is the core of the asp.net application under IIS.
2, application pool. It is the container of worker process. IIS5 and previous IIS versions do not have the concept of application pool. Each application pool corresponds to one worker process, and Application Pool and Mapping worker process are maintained in IIS Metabase. This avoids the crash of worker process (aspnet_wp.exe) in IIS5 (IIS5) and the total crash of application.
After the client made a resource request to IIS, the following happened:
1, server accepts the request
IIS6 distributes individual Request to application pool via HTTP.SYS in kernel mode (Kernel mode). This is not a random process. application pool was registered with HTTP.SYS when it was created, so when the request arrives, HTTP.SYS will be sent directly to application pool. Next, in IIS's user mode (User mode), Web Admin Services (WAS) does the work of getting Request from HTTP.SYS and distributing it to application pool. application pool passes request directly to worker process.
2. After the request is passed to worker process, worker process initializes ASP.NET ISAPI(Internet Server Application Program Program Interface), ASP.NET ISAPI and then loads CLR CLR to create the hosting environment.
(note: ISAPI is only an interface and ACTS as an agent, and its main capability is to find the handler for the suffix Request URL according to its suffix)
ASP.NET ISAPI is defined in aspnet_isapi.dll, which itself runs in an unmanaged environment. ASP.NET ISAPI starts with an HttpRuntime, and HttpRuntime calls the ProcessRequest method to start processing the request. ProcessRequest creates different HttpWorkerRequest based on the iWRType passed in from ISAPI, thereby masking the differences between different IIS. Next, the ProcessRequest method creates HttpContext, which we access using HTTPContext.Current. After HttpRuntime creates the HttpApplication object (IHttpHandler) using HttpApplicationFactory, all requests are processed by finding the corresponding Httphandler after passing httpmodule. Before HttpApplicationFactory creates HttpApplication, all HttpModule registered in config (web.config and Machine.config) files are searched, Assembly is loaded according to the configuration information, HttpModule is created via Reflection, and these Module are added to HttpApplication's _moduleCollection Filed. Our request for 1 Application ends up on 1 HttpApplication object. When a request arrives, ASP.NET looks for the unused HttpApplication object in Httplication Pool.
3. After the request passes through the HTTP pipeline, each request is sent to the relevant httphandler, and the IIS request processing process is completed.
HttpHandler is the end of the HTTP pipe, which generates output for each request. System. Web. UI. Page is such a typical Httphandler, when we request a aspx page, the HttpHandler generates html sent back to the client. Look at the Page class signature:
public class Page : TemplateControl, IHttpHandler
{
}
As you can see, the Page class is an HttpHandler.
To sum up, the whole process is as follows: when a client sends a resource request to the server, the request first reaches HTTP.SYS of IIS. HTTP. SYS then sends the request trace corresponding to Application Pool. Application Pool then sends the request to Worker Process (W3WP.exe) to load ISAPI Extension, and ISAPI creates an HttpRuntime object to process the request through HttpModule and HttpHandler. Then the page lifecycle begins.
4, the page lifecycle begins
The main phases of the page lifecycle include:
Page initialization (Init) : the server creates an instance of the server control
Load (load): the control instance is loaded into the page object it defines
Pre-output :(PreRender) changes to the control are updated and ready for output.
Save (SaveViewState): the control's state information is saved.
Output page (Render): the server creates an html tag for the control.
Processing (Dispose): the main work is dispose, closing the database connection, releasing file resources, etc.
Uninstall (Unload) : destroys an instance of the server control
Key events in the page lifecycle:
PreInit:
1. Check the IsPostBack property
2. Dynamically set Master Page
3. Set Theme dynamically
4. Set the default value of the control (UniqueId, etc.)
5. Recreate the dynamic control (initialization control) and initialize the value of the control
Init: this event occurs after all controls have been initialized and all skin Settings have been applied. It is used to read or initialize controller properties. It can be used to register events for controls not specified on the aspx page.
InitComplete: Use this event for processing tasks that require all initialization to be complete.
PreLoad: loads the ViewState of the page with all the controls, and then processes all the postback data contained in the Request instance.
Load: this is probably the most familiar. Note that the Page object recursively calls the onload event of the child control until the page and all child controls are loaded. This event is primarily used to set the value of control properties and establish a database connection (which is not usually done).
Control events: I won't say much more about this, but it deals with control events, such as click. This also makes us understand that every time we click an Button, we actually need to execute the load event before we execute the click event. IsPostBack to judge 1 to avoid performing unnecessary load logic.
LoadComplete: all the controls on the page are loaded and executed.
PreRender: this is the last event before HTML is generated. Each control on a page has an PreRender procedure. Here is the last change to the HTML result to be output.
SaveStateComplete: all controls and pages have been saved before this time, and any changes to page or controls will not be left or right. I haven't thought of anything to do with it yet.
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 on the page. In the control, use this event to do cleanup, such as closing a database connection, and so on. Do cleanup work with the page itself, such as closing open files and database connections, or closing logs or other specified work.
It should be noted that each time Request creates a new instance of the Page class, so the self-defined fields in the page cannot be passed twice in request, but need to be stored using viewstate.
5, HttpHandler sends the results back to IIS based on the processing of the events in the page lifecycle, and IIS sends the results back to the client browser.
It is worth noting that during this process the request will again go through HttpModule(register an EndRequest event).
At this point, the whole Request is over.