🌐 Internet Information Services (IIS) Overview

The Fundamental Difference: Kernel vs User Mode Architecture

Unlike Apache/nginx which are purely user-mode applications, IIS splits functionality between kernel mode (HTTP.sys) and user mode (worker processes). This is a completely different architectural approach.

What Makes This Architecture Unique:

1. Kernel-Mode HTTP Processing: HTTP.sys handles protocol processing, caching, and SSL in kernel space - much faster than user-mode alternatives
2. URL-Based Routing: Multiple applications can share port 80 because HTTP.sys routes based on URL prefixes registered by each application pool
3. Request Queuing: Each application pool has its own request queue in kernel space. Worker processes pull requests from their queues
4. Zero-Copy Caching: Static content and dynamic responses can be cached in kernel space and served without any user-mode involvement
5. Process Recycling: Worker processes can be recycled (restarted) without dropping connections - HTTP.sys maintains the connection while spinning up new processes

HTTP.sys is a kernel-mode driver that fundamentally changes how web servers work on Windows. Instead of having a user-mode process listen on port 80/443 like Apache or nginx, HTTP.sys operates at the kernel level.

How HTTP.sys Works:

• Port Binding: HTTP.sys owns the network ports (80, 443, etc.) at the kernel level. Multiple applications can register URL prefixes with HTTP.sys without port conflicts
• Request Queuing: Incoming requests are queued in kernel space before being delivered to user-mode worker processes. This eliminates context switches for basic request handling
• Response Caching: Static responses can be cached entirely in kernel space, allowing HTTP.sys to serve cached content without involving user-mode processes at all
• SSL Termination: SSL/TLS processing happens in kernel mode, reducing overhead and improving performance
• Bandwidth Throttling: Can limit bandwidth per site/application at the kernel level
• Request Filtering: Basic security filtering (like request size limits) happens before requests reach user mode

Why This Matters:

Traditional web servers like Apache create a user-mode process that binds to port 80. Every request requires kernel→user mode transitions. HTTP.sys eliminates many of these transitions and allows multiple applications to share ports through URL routing at the kernel level. This is why you can have multiple IIS sites on port 80 - HTTP.sys routes based on Host headers.

The Request Flow:

1. Network packet arrives → Kernel TCP/IP stack
2. HTTP.sys processes the request in kernel mode
3. If cached response exists → HTTP.sys serves it directly from kernel
4. If not cached → HTTP.sys queues request for appropriate application pool
5. Worker process picks up request from its queue
6. Response flows back through HTTP.sys

Application pools are NOT just "isolation boundaries" - they're a complete process management and security system.

What an Application Pool Actually Is:

• Process Container: Each application pool spawns one or more worker processes (w3wp.exe). These processes are completely isolated from each other at the OS level
• Security Context: Each pool runs under a specific Windows identity (ApplicationPoolIdentity, NetworkService, or custom account). This determines file system access, database permissions, etc.
• Resource Governor: Pools can have CPU limits, memory limits, and connection limits. When limits are exceeded, IIS can take actions like recycling the process
• Fault Isolation: If one application crashes or hangs, it only affects its own worker process - other applications in different pools continue running

Worker Process Lifecycle Management:

• Process Recycling: Worker processes are automatically recycled based on:
  • Memory consumption thresholds
  • Number of requests processed
  • Time intervals
  • Configuration file changes
  • Manual recycling
• Idle Timeout: If no requests come in, worker processes shut down after a configurable timeout (default 20 minutes) to free resources
• Process Warm-up: New worker processes can be "warmed up" by making initialization requests before accepting real traffic
• Overlapped Recycling: When recycling, IIS starts a new worker process before killing the old one, ensuring zero downtime

Application Pool Models:

• Integrated Mode: Managed (.NET) modules run in the same pipeline as native IIS modules. ASP.NET has full access to all request processing stages
• Classic Mode: Legacy mode where ASP.NET runs as an ISAPI extension, similar to IIS 6. Less efficient but needed for some legacy applications

Example Scenario:

You have three web applications: a public website, an admin portal, and an API. You create three application pools:

• PublicPool: Runs under ApplicationPoolIdentity, limited to 1GB RAM, recycles every 1000 requests
• AdminPool: Runs under a custom service account with elevated permissions, no memory limits
• APIPool: Runs under NetworkService, configured for high CPU limits and frequent recycling

If the API crashes due to a memory leak, only APIPool's worker process dies - the public site and admin portal continue running unaffected.

Worker processes are the actual execution engines where your application code runs.

What Happens Inside a Worker Process:

• Runtime Loading: .NET CLR, PHP runtime, or other execution engines are loaded into the process
• Module Pipeline: HTTP requests flow through a pipeline of modules (authentication, authorization, compression, etc.)
• Application Domains: Multiple .NET applications can run in the same worker process but in separate AppDomains for isolation
• Thread Pool: Worker processes maintain thread pools to handle multiple concurrent requests
• Session State: In-process session state, view state, and application state are maintained here

Process Management:

• Health Monitoring: IIS monitors worker processes for hangs, excessive resource usage, and crashes
• Rapid Fail Protection: If a worker process crashes repeatedly (default: 5 times in 5 minutes), the application pool is shut down
• Process Orphaning: When recycling fails, IIS can "orphan" the old process and start fresh