Shulou(Shulou.com)06/02 Report--

This article introduces how to understand the HTTP protocol / IIS principle and ASP.NET operation mechanism, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Preface

When I was sorting my email, I found an email I had communicated with Mr. CDD a few years ago. Here is a brief summary:

"from a technical point of view, no matter which camp, with the new technology is inevitable, but also very tiring, of course, as a programmer, is also necessary. If you want to reduce the impact of technological updates on yourself, you must lay a solid foundation. So, the things at the bottom and the things at the abstract layer need to be done. Because in the final analysis, no matter what technology is nothing more than architecture and final implementation, the technology framework is only a platform for application development, a technology, if you know the specific things, technology update will have no impact on you, or in other words, you have to learn a new technology, speed and efficiency will be very high. "

The above paragraph has a great impact on yourself, and there may be some confusion and hesitation when we step into the "procedural life". Although I am one of those people who love Proramming very much, I have hesitated in the face of a kaleidoscope of technology branches. What we need to do in our spare time is to lay a solid foundation and find our own interests and directions. In the iteration of technology, constant response to change is the king.

Because of this, there will be no silver bullet. If there is a silver bullet, then what I believe in is: program = data structure + algorithm

I choose the direction is Web, but also believe that Web will eventually be the future of the Internet. This article briefly talks about my own basic understanding of Web under. Net platform. As my level is limited, please forgive me for my shortcomings.

HTTP protocol

HTTP protocol is a specification followed by both the browser and the server. It is an application layer protocol based on TCP/IP (transport layer protocol, corresponding to UDP).

PS:TCP/UDP is a widely used network communication protocol, and UDP protocol is unreliable and insecure.

Relatively speaking, the TCP protocol is based on connection and three-way handshake (relatively reliable and secure). However, for the website with BPX S architecture, because there will be a large number of people online at the same time, if all of them remain connected to the server. The bearer of the server is quite large.

Therefore, the HTTP protocol is derived. To put it simply: the server closes the connection and releases resources immediately after the request is initiated. Because of this, HTTP protocols are usually understood as stateless.

Of course, there are many ways to maintain the state; for example, Session/Cookie and so on will not be discussed here.

First, let's take a look at the diagram of the typical seven-tier OSI model.

HTTP's most popular understanding of request / response.

The figure shows:

HTTP message information

HTTP Request Header

HTTP Response Header

Of course, you can also change the browser's options by setting. No details are given here. What is not clear can be Google.

An example of adding P3P header information under ASP.NET is given.

HttpContext.Current.Response.AddHeader ("P3P", "CP=\" IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\ "")

If you are interested in learning more, please refer to the article on deploying P3P in MSDN.

The following is a clich é (familiar friends, skip by themselves, right to review:)

The request header (message header) contains (server hostname requested by the client, environment information of the client, etc.):

Accept: used to tell the server about the data types supported by the client (e.g. Accept:text/html,image/*)

Accept-Charset: used to tell the server about the encoding format used by the client

Accept-Encoding: used to tell the server the data compression format supported by the client

Accept-Language: client language environment

Host: the hostname that the client wants to access through this server

If-Modified-Since: the client uses this header to tell the server the cache time of the resource

Referer: the client uses this header to tell the server from which resource it (the client) accesses the server (hotlink protection)

User-Agent: the client uses this header to tell the server the client's software environment (operating system, browser version, etc.)

Cookie: the client uses this header to bring Coockie information to the server

Connection: tells the server whether to keep the connection after the request is completed

Date: tells the server the time of the current request

An http response represents the data that the server sends back to the client, which includes:

One status line, several response headers, and physical content

Status line: for example: HTTP/1.1 200 OK (version number of the protocol is 1.1 response status code is 200 response result is OK)

The response header (message header) contains:

Location: does this header match the 302 status, which is used to tell the client who to look for?

Server: the server tells the browser the type of server through this header

Content-Encoding: tells the browser the data compression format of the server

Content-Length: tells the browser the length of the data sent back

Content-Type: tells the browser the type of data to be sent back

Last-Modified: tells the browser the current resource cache time

Refresh: tell the browser how often to refresh

Content- Disposition: tells the browser to open the data as a download. For example: context.Response.AddHeader ("Content-Disposition", "attachment:filename=icon.jpg"); context.Response.WriteFile ("icon.jpg")

Transfer-Encoding: tells the browser the encoding format in which the data is transmitted

ETag: cache-related headers (can be updated in real time)

Expries: tells the browser how long the returned resource is cached. If it is-1 or 0, it means no cache

Cache-Control: controls browsers not to cache data no-cache

Pragma: controls browsers not to cache data no-cache

Connection: whether to disconnect after the response is complete. Close/Keep-Alive

Date: tell the browser the server response time

IIS running process

With the knowledge review of the HTTP protocol above, let's take a look at how IIS works.

IIS 5.X is far away from us. Well, XP seems to be by default. A moment of silence for the evil IE6.

Here let's take a look at the diagram of IIS 6.

According to the figure above, the running process of IIS6 is simply analyzed.

Under User Mode, the http.sys receives the http request, and then it looks at the Metabase in the IIS to see which Application Pool the Application based on that Request belongs to, and if the Application Pool does not exist, create it. Otherwise, send the request directly to the Queue of the corresponding Application Pool.

Each Application Pool corresponds to a Worker Process-w3wp.exe (running under User Mode). Mapping for Application Pool and Worker Process is maintained in IIS Metabase. WAS (Web Administrative Service) based on such a mapping, pass the request that exists in an Application Pool Queue to the corresponding Worker Process (if not, create such a process). When the Worker Process is initialized, load the ASP.NET ISAPI,ASP.NET ISAPI and then load the CLR. Finally, create an Application Domain; for Application through AppManagerAppDomainFactory's Create method to process Request through ISAPIRuntime's ProcessRequest, and then enter the process into ASP.NET Http Runtime Pipeline.

Several knowledge points of PS:

HTTP.SYS: a component of (Kernel) that Listen external HTTP requests and forwards them to the appropriate application pool (Application Pool) based on the URL of the request. When the HTTP request is processed, it is responsible for sending the processing result. To provide better performance, a buffer has been set up within HTTP.SYS to store the results of the most recent HTTP request processing.

Application Pool: IIS always maintains a separate worker process: the application pool. All processing takes place in this process, including the execution of ISAPI dll. Application pools are a major improvement for IIS6 because they allow you to control the execution of a given process at a smaller granularity. You can configure application pools for each virtual directory or the entire Web site, which makes it easy to isolate each application into its own process, thus completely isolating it from other programs running on the same machine. From the perspective of Web processing, if one process dies, at least it will not affect other processes.

When the application pool receives the HTTP request, it is left to the worker process Worker Process: w3wp.exe running in the application pool to process the HTTP request.

Worker Process: when the worker process receives the request, it first finds and loads the corresponding ISAPI extension according to the suffix (for example, the mapping corresponding to aspx is aspnet_isapi.dll). After the worker process loads the aspnet_isapi.dll, aspnet_isapi.dll is responsible for loading the running environment of the ASP.NET application, that is, CLR (.NET Runtime).

Worker Process runs in an unmanaged environment, while objects in .NET run on top of a managed environment (CLR), and the bridge between them is the ISAPI extension.

WAS (Web Admin Service): this is a monitor program that, on the one hand, accesses all kinds of information placed in the InetInfo Metabase (Metabase), and on the other hand is responsible for monitoring the work status of worker processes in the application pool (Application Pool). If necessary, it shuts down an old worker process and creates a new one to replace it.

Let's take a look at the diagrams of IIS7 classic mode on the Internet.

The managed pipeline mode "classic" mode of the IIS 7 application pool works the same way. This mode is compatible with IIS 6 to reduce the cost of upgrades.

Interlude

The scenario assumes:

Intercept the client's request and rewrite the request. In IIS6, the interception of a request can only be limited to the IIS after loading the aspnet _ isapi.dll, that is, if the request is not a request for asp.net resources explicitly (for example, the request is only a request for a static file, such as www.cnblogs.com/index.html, then we cannot write the logic to intercept the request in the code, because IIS6 maps and loads the corresponding isapi according to the suffix of URL. If the url of a request is: www.cnblogs.com/index.aspx, according to the suffix ".aspx", IIS6 can know that the request is for asp.net resources, and the code that aspnet_isapi.dll creates the .net runtime and runs the asp.net page should be loaded, but it is obvious that requests such as "www.cnblogs.com/index.html" are not considered by IIS6 to be requests for asp.net resources. Therefore, aspnet_isapi.dll will not be loaded to run asp.net, and even if we write code in the asp.net page to intercept the request, it will not be executed. Of course, I say there's usually a reason, because we can add wildcard program mapping in IIS6, or manually add handlers to a request in web.config, to force IIS6 to load aspnet_isapi.dll for requests of non-asp.net resource types. The process of executing the request in IIS6 is as above.

Why, is there anyone who thinks of URL Routing and URL Rewriting as I do?

Without explanation here, Uncle's Notebook 16 Portal: http://www.cnblogs.com/TomXu/archive/2011/12/27/2303486.html

Let's put this question aside for a moment. Maybe we can have some ideas about the integration mode of II7.

Let's take a look at the diagram of IIS7 on IIS's official website.

Portal: http://www.iis.net/learn/get-started/introduction-to-iis/introduction-to-iis-architecture

1. When the client browser starts HTTP to request the resources of a WEB server, HTTP.sys intercepts the request.

2. HTTP.sys contacts WAS for configuration information.

3. WAS requests configuration information from the configuration Storage Center (applicationHost.config).

4. The WWW service receives configuration information, which refers to similar application pool configuration information, site configuration information, and so on.

5. The WWW service uses configuration information to configure the HTTP.sys processing policy.

6. WAS creates a process for the request (if it does not exist)

The worker process processes the request and responds to the HTTP.sys.

8. The client receives the processing result information.

A gorgeous transformation of the managed pipeline mode (integrated mode) of the IIS 7 application pool

The request for asp.net in IIS7 is no longer divided into two processing channels, but integrates asp.net and IIS, which has the advantage of unifying the request verification work, strengthening the asp.net 's control over the request, and so on. In IIS7, asp.net is no longer limited to aspnet_isapi.dll like IIS6, but is liberated. From the moment IIS receives the HTTP request, that is, it enters the control range of asp.net. Asp.net can exist in all stages of processing a request in IIS. It is even possible to provide asp.net-based authentication authentication for PHP applications deployed in IIS7 (portal: http://msdn.microsoft.com/zh-cn/magazine/cc135973.aspx).

All right, stop abruptly, space is limited: the IIS section comes to an end and leaves some room for reverie.

Then analyze the operation mechanism of ASP.NET

ASP.NET operation mechanism

In the IIS6 diagram, we analyze that "AppManagerAppDomainFactory's Create method creates an Application Domain; for Application to process Request through ISAPIRuntime's ProcessRequest, which in turn enters the process into ASP.NET Http Runtime Pipeline."

Let's take a look at the diagram of the running process of AppDomain.

I believe we all know the role of AppDomain very well. Here are a few points to the point:

Objects created by code in one AppDomain cannot be directly accessed by code in another AppDomain (only marshaled by reference or by value, which provides good isolation).

AppDomain can uninstall CLR's ability to uninstall an assembly from AppDomain, but you can tell CLR to uninstall an AppDomain, thus uninstalling all assemblies currently contained in that AppDomain.

From the above, we can see that AppDomain ensures the robustness of the Windows system and the applications running in it. AppDomain provides the isolation required to protect, configure, and terminate each of these applications.

Let's take a look at the process of ProcessRequest.

A brief analysis of the above picture

In ProcessRequest (HttpWorkerRequest wr), determine whether the wr is null, then determine whether the pipeline is complete, and then call the ProcessRequestNoDemand (wr) method.

And determine whether the current RequestQueue is null, then calculate the waiting time and update the number of pipelines CalculateWaitTimeAndUpdatePerfCounter (wr)

Reset the wr start time wr.ResetStartTime (); call the ProcessRequestNow (wr) method and call the ProcessRequestInternal (wr) method

Continue the legend

The ProcessRequestInternal method is as follows:

Private void ProcessRequestInternal (HttpWorkerRequest wr) {HttpContext context; try {context = new HttpContext (wr, false); / / HttpContext} catch {/ / the common 400th error generated by HttpWorkerRequest is where wr.SendStatus (400, "Bad Request") is caught; wr.SendKnownResponseHeader (12, "text/html") Charset=utf-8 "); byte [] bytes = Encoding.ASCII.GetBytes (" Bad Request "); wr.SendResponseFromMemory (bytes, bytes.Length); wr.FlushResponse (true); wr.EndOfRequest (); return;} wr.SetEndOfSendNotification (this._asyncEndOfSendCallback, context); Interlocked.Increment (ref this._activeRequestCount); HostingEnvironment.IncrementBusyCount () Try {try {this.EnsureFirstRequestInit (context);} catch {if (! context.Request.IsDebuggingRequest) {throw;}} context.Response.InitResponseWriter () IHttpHandler applicationInstance = HttpApplicationFactory.GetApplicationInstance (context); / / get HttpApplication if (applicationInstance = = null) {throw new HttpException (System.Web.SR.GetString ("Unable_create_app_object")) } if (EtwTrace.IsTraceEnabled (5,1)) {EtwTrace.Trace (EtwTraceType.ETW_TYPE_START_HANDLER, context.WorkerRequest, applicationInstance.GetType (). FullName, "Start");} if (applicationInstance is IHttpAsyncHandler) {IHttpAsyncHandler handler2 = (IHttpAsyncHandler) applicationInstance; context.AsyncAppHandler = handler2 Handler2.BeginProcessRequest (context, this._handlerCompletionCallback, context); / / then HttpApplication processes requests} else {applicationInstance.ProcessRequest (context); this.FinishRequest (context.WorkerRequest, context, null);}} catch (Exception exception) {context.Response.InitResponseWriter () This.FinishRequest (wr, context, exception);}}

Let's take a look at the method of instantiating Application by GetApplicationInstance (context).

View Code internal static IHttpHandler GetApplicationInstance (HttpContext context) {if (_ customApplication! = null) {return _ customApplication;} if (context.Request.IsDebuggingRequest) {return new HttpDebugHandler ();} _ theApplicationFactory.EnsureInited (); _ theApplicationFactory.EnsureAppStartCalled (context); return _ theApplicationFactory.GetNormalApplicationInstance (context);}

The last call to the GetNormalApplicationInstance method determines the number of application currently idle and calls the

Application.InitInternal (context, this._state, this._eventHandlerMethods) method

This.InitModules () initializes all Modules, including user-defined HttpModules

This._stepManager.BuildSteps (this._resumeStepsWaitCallback); / / Pipeline event sequence

Post the source code:

Internal override void BuildSteps (WaitCallback stepCallback) {ArrayList steps = new ArrayList (); HttpApplication app = base._application; bool flag = false; UrlMappingsSection urlMappings = RuntimeConfig.GetConfig (). UrlMappings; flag = urlMappings.IsEnabled & & (urlMappings.UrlMappings.Count > 0); steps.Add (new HttpApplication.ValidatePathExecutionStep (app)); if (flag) {steps.Add (new HttpApplication.UrlMappingsExecutionStep (app)) } app.CreateEventExecutionSteps (HttpApplication.EventBeginRequest, steps); app.CreateEventExecutionSteps (HttpApplication.EventAuthenticateRequest, steps); app.CreateEventExecutionSteps (HttpApplication.EventDefaultAuthentication, steps); app.CreateEventExecutionSteps (HttpApplication.EventPostAuthenticateRequest, steps); app.CreateEventExecutionSteps (HttpApplication.EventAuthorizeRequest, steps); app.CreateEventExecutionSteps (HttpApplication.EventPostAuthorizeRequest, steps); app.CreateEventExecutionSteps (HttpApplication.EventResolveRequestCache, steps); app.CreateEventExecutionSteps (HttpApplication.EventPostResolveRequestCache, steps) Steps.Add (new HttpApplication.MapHandlerExecutionStep (app)); app.CreateEventExecutionSteps (HttpApplication.EventPostMapRequestHandler, steps); app.CreateEventExecutionSteps (HttpApplication.EventAcquireRequestState, steps); app.CreateEventExecutionSteps (HttpApplication.EventPostAcquireRequestState, steps); app.CreateEventExecutionSteps (HttpApplication.EventPreRequestHandlerExecute, steps); steps.Add (new HttpApplication.CallHandlerExecutionStep (app)); app.CreateEventExecutionSteps (HttpApplication.EventPostRequestHandlerExecute, steps); app.CreateEventExecutionSteps (HttpApplication.EventReleaseRequestState, steps) App.CreateEventExecutionSteps (HttpApplication.EventPostReleaseRequestState, steps); steps.Add (new HttpApplication.CallFilterExecutionStep (app)); app.CreateEventExecutionSteps (HttpApplication.EventUpdateRequestCache, steps); app.CreateEventExecutionSteps (HttpApplication.EventPostUpdateRequestCache, steps); this._endRequestStepIndex = steps.Count; app.CreateEventExecutionSteps (HttpApplication.EventEndRequest, steps); steps.Add (new HttpApplication.NoopExecutionStep ()); this._execSteps = new HttpApplication.IExecutionStep [steps.Count] Steps.CopyTo (this._execSteps); this._resumeStepsWaitCallback = stepCallback;}

This must enable you to have a brief review of the ASP.NET pipeline mechanism. Of course, there are still many places that have not been analyzed in detail.

Let's summarize the running process of IIS and the mechanism of ASP.NET pipeline:

Request → (Internet) HTTP.sys snooping → WAS (IIS6 web Admin Service / IIS7 (Windows Activation Service) receive request

→ (incoming) Application Pool's → w3wp.exe (check URL suffix)

→ (load) ISAPI extension [aspnet_isapi.dll] → Registration Map

Constructing → ProcessRequest methods of HttpRuntime class

HttpContext instance generation (Request,Response,Session and so on …)

HttpRuntime calls HttpApplicationFactory to load HttpApplication object

Cross HttpModule to HttpHandler

Simply use 140characters (that is, the number of words in a Weibo

) Summary:

Request → (Internet) HTTP.sys → (WAS) → Application Pool's → w3wp.exe → ISAPI → Map → (Pipeline) HttpWorkerRequest → AppDomain → HttpRuntime → ProcessRequest () → HttpContext (Request,Response) → HttpRuntime → HttpApplicationFactory → HttpApplication → HttpModule → HttpModule →

The above is a personal learning summary, if there are any mistakes, welcome to correct!

Supplement

1: just saw a flash memory sent by dudu, which mentioned that the difference between Application pool and AppDomain comes from stackoverflow. I hope it will be helpful to you.

The 2:WAS abbreviation refers to (Web Admin Service) in IIS6 and (Windows Activation Service) in IIS7. I noticed this when I was writing the article, but I didn't think about it in depth. The understanding is not very good. Don't jump to conclusions for the time being. Welcome to axe!: -)

On how to understand the HTTP protocol / IIS principle and ASP.NET operating mechanism to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.