IIS basics to understand SharePoint better
INTRODUCTION
Internet Information Server (IIS) being the first topic in my blog I thought I will make it simple. IIS is basically a web server. IIS is an integral part of the windows Operating System and it is turned on by default when Windows is installed. The different components in IIS has responsibilities, such as listening for requests made to the server, managing processes, and reading configuration files. And they are:
· HTTP Protocol Stack: It mainly includes Protocol listener that receive protocol-specific requests, send them to IIS for processing, and then return responses to requestors. For example, when a client browser requests a Web page from the Internet, the HTTP listener, HTTP.sys, picks up the request and sends it to IIS for processing. Once IIS processes the request, HTTP.sys returns a response to the client browser. We have technologies like WCF (windows Communication Foundation). This is also referred to as HTTP.sys and resides in the kernel mode which is where Operating system code runs.
Before we talk about the next component we need to know what is Worker Process: This is basically a user mode code which process the requests such as returning a static page or invoking an Internet Server API (ISAPI)
· Service Host: Also known as SVCHost.EXE which is used as a host by Windows Process Activation Service (WAS) which is used to host our services in IIS and World Wide Web Service (W3SVC) for managing the lifetime of the worker process. These two services run as LocalSystem in the same Svchost.exe process, and share the same binaries.
MODULES IN IIS
Modules are individual features that the server uses to process requests. For example, IIS uses authentication modules to authenticate client credentials, and cache modules to manage cache activity. The advantage of this architecture is that you can control which modules you want on the server similarly you can customize a server to a specific role in your environment and you can use custom modules to replace existing modules or to introduce new features. We will be talking about the two important modules in the following paragraphs:
Native Module:
These are the modules that are available with a full installation of IIS 7 and above. Each of these modules performs a specific task. It includes the following modules:
· HTTP Modules: HTTP modules include modules to respond to information and inquiries sent in client headers, to return HTTP errors, to redirect requests, and more.
· Security Modules: IIS perform tasks related to security hence there are separate modules for each of the authentication schemes, which enable you to select modules for the types of authentication you want on your server.
· Content Modules: These modules process requests for static files, to return a default page when a client doesn't specify a resource in a request, to list the contents of a directory, and more. For example,
· Compression Modules: These modules perform compression in the request-processing pipeline.
· Caching Modules: It is these modules that improve the performance of our websites and web applications by storing processed information in memory on the server, and then reusing that information in subsequent requests for the same resource.
· Logging and Diagnostics Modules: The logging modules support loading of custom modules and passing information to HTTP.sys. The diagnostics modules follow and report events during request processing.
· Managed Support Module: A couple of modules in IIS support managed integration in the IIS request-processing pipeline.
Managed Module:
These modules are used to extend the IIS functionality. And they generally follow ASP.NET request pipelines.
REQUEST PROCESSING IN IIS
In IIS, the IIS and ASP.NET request pipelines combine to process requests with an integrated approach. The new request-processing architecture consists of an ordered list of native and managed modules that perform specific tasks in response to requests. The benefit of this approach is as follows:
· All file types can use features that were originally available only to managed code.
· Eliminates the duplication of several features in IIS and ASP.NET. For example, when a client requests a managed file, the server calls the appropriate authentication module in the integrated pipeline to authenticate the client. In previous versions of IIS, this same request would go through an authentication process in both the IIS pipeline and in the ASP.NET pipeline.
· You can manage all of the modules in one location, instead of managing some features in IIS and some in the ASP.NET configuration. This simplifies the administration of sites and applications on the server.
APPLICATION POOLS IN IIS
Application pools separate applications by process boundaries to prevent an application from affecting another application on the server. In IIS 7 and above, application pools continue to use IIS 6.0 worker process isolation mode.[Same as before] In addition, you can now specify a setting that determines how to process requests that involve managed resources: Integrated mode or Classic mode.
Now let’s see what is Integrated mode and Classic mode.
Integrated mode: When an application pool is in integrated mode, you can take advantage of the integrated request-processing architecture of IIS and ASP.NET. When a worker process in an application pool receives a request, the request passes through an ordered list of events. Each event calls the necessary native and managed modules to process portions of the request and to generate the response.
Classic mode: When an application pool is in Classic mode, IIS 7 and above handles requests in the same way as in IIS 6.0 worker process isolation mode. ASP.NET requests first go through native processing steps in IIS and are then routed to Aspnet_isapi.dll for processing of managed code in the managed runtime. Finally, the request is routed back through IIS to send the response. This creates duplication of certain steps.
HTTP REQUEST PROCESSING IN IIS
The following list describes the request-processing flow that is shown in Figure 1:
1. When a client browser initiates an HTTP request for a resource on the Web server, HTTP.sys intercepts the request.
2. HTTP.sys contact’s WAS to obtain information from the configuration store.
3. WAS requests configuration information from the configuration store, applicationHost.config.
4. The WWW Service receives configuration information, such as application pool and site configuration.
5. The WWW Service uses the configuration information to configure HTTP.sys.
6. WAS start’s a worker process for the application pool to which the request was made.
7. The worker process processes the request and returns a response to HTTP.sys.
8. The client receives a response.
