All-New Architecture
Perhaps the most important under-the-hood feature is IIS' all-new architecture. To really appreciate how improved it is, let’s quickly review how IIS 5 and prior versions were built.

In previous versions of IIS, 100 percent of IIS' code ran in user mode. Windows, as you may know, has two basic memory spaces: user and kernel. Everything in user space is protected from everything else in user space, and most applications execute there. Kernel mode is reserved for the OS itself, device drivers and other low-level components. Kernel mode is very sensitive; in fact, many blue screen crashes come from poorly-written kernel mode software. In short, kernel mode has the ability to take down the entire machine. Of course, the benefit of kernel mode is pure speed: Nothing can access memory and system services as fast as software running in kernel mode.

IIS 5 also ran under a single memory space. This meant that IIS, any IIS filters (such as the filters that make Active Server Pages work), and any user code (such as ASP pages) all share a memory space. If poorly written code is executed, or vulnerability exploited, that entire memory space can be taken down, effectively crashing IIS.

So, in IIS 5, IIS would register with the operating system to receive traffic from ports 80 (HTTP), 443 (HTTPS), 20 and 21 (FTP), and so forth. The OS would hand traffic off to IIS, passing that traffic from the kernel mode TCP/IP driver to the user mode IIS code. IIS would then put the traffic into the correct virtual server, execute ASP code, and do whatever else was necessary.

Those were the old days. With IIS 6, everything changes. To start with, there's a new piece of kernel mode software: Http.sys. This driver, written by Microsoft, is responsible for receiving all IIS-bound TCP/IP traffic from the TCP/IP stack. Running in kernel mode gives the new driver a huge speed advantage, and the fact that only Microsoft-written code is in Http.sys should ideally make it as stable as possible. Http.sys never executes any code, such as ASP code, not written by Microsoft. This means any future exploits found in ASP, ASP.NET, or some other segment of IIS can't be exploited to crash kernel mode.

Http.sys' job is to hand off traffic to the user mode portions of IIS. All user-written code -- ASP, ASP.NET, etc. -- runs in user mode. So now, a poorly-written ASP page won’t necessarily crash the entire IIS server. Because Http.sys is separate and living in kernel mode, it's protected and the server will be able to continue processing traffic.

IIS provides memory segmentation for user mode, too, through the use of application pools. Each application pool (there's one by default, but you can create more) occupies a dedicated memory space. So if one application pool crashes, the others will continue to live, and will receive traffic directly from Http.sys. Each virtual server you create can be assigned to a specific application pool.

For servers running multiple Web sites, you can segregate each Web site so that one crashes site won't affect the other sites. Http.sys will deliver incoming traffic to the proper site (passed on destination port, IP address, and host headers). It's a great idea, under IIS 6, to assign each Web site to a separate application pool, provided your server has sufficient memory to support them all. That way, a single crashed site won't affect anything else.

Scalability
Each application pool is served by a single worker process, which can be defined as a single thread of execution, which processes all ASP pages, Web page requests, and whatever else your Web site handles. You can, however, configure an application pool to support multiple worker processes. When you do so, the application pool is referred to as a Web garden.

You probably are familiar with the term Web farm: It's two or more identical Web servers that balance incoming requests across them. To users, the servers appear to be one gigantic server, but to you they're a great way to create scalable Web sites. A Web garden is a similar concept, sort of a "Web farm within a server." When you create multiple worker processes for an application pool, IIS will load balance incoming requests across the available processes. If one process hangs, IIS can kill it automatically and try to restart it, thus keeping the Web site performance as high as possible. Because a lot of user code -- like ASP pages -- can contain memory leaks, IIS can also periodically recycle a worker processes, ending it and creating a new one to ensure that resource utilization is as efficient as possible.

With Web gardens, a single poorly-performing Web page -- say, a Web page that's executing a large query -- won't necessarily hand the entire Web site, because additional worker processes are available to handle other Web requests in parallel. You can configure all of these worker process options within the application pools you create (open up the IIS 6 MMC and you'll notice a new folder for application pools).

Security
IIS 6 is also supposed to be a brand-new way of thinking about security, and it really delivers on that promise. Prior versions of IIS had the goal of being as functional as possible "out of the box." IIS 6 isn't even installed by default. When you do install IIS 6, the default installation options provide you with an absolutely stripped-down Web server capable only of serving harmless, static HTML pages. If you want to offer ASP, server-side includes, WebDAV, FrontPage, or anything else, you'll need to install each of those options individually from the Add/Remove Windows Components control panel. The theory is that each of those components comes with its own security risks, and that you as the administrator are acknowledging those risks by explicitly installing the components. That's far better than Microsoft just plunking them all down without you even being aware of what's going on!
Http.sys itself also lends some basic security beef to IIS. For example, it conducts a brief examination of all requests, and willr eject requests with obvious buffer overflows, malformed packets, and so forth. Http.sys also checks with the file system on each request, and will discard any requests for pages that don't exist. This helps defeat certain types of Denial of Service (DoS) attacks, which request random, nonexistent pages from the Web server. Http.sys can ignore these requests with relatively little effort, rather than passing the request into user mode and forcing IIS to do something about it.

Worth Your While
From both an architecture, performance, and security standpoint, IIS 6 contains a lot of new features and designs under the hood. While the MMC might not look very different from prior versions of IIS, what's running on your 2003 servers is a redesigned, rewritten version of IIS that's intended to address most of the security, stability, and performance issues of prior versions. Upgrading from IIS 5 is usually a piece of cake, and IIS 6 even offers a backwardly-compatible "IIS 5 Process Isolation Mode" that forces IIS 6 to behave more like IIS 5. This setting can help you migrate complex Web sites that rely on IIS 5's specific memory and process management techniques.

To me, IIS 6 is one of the "killer apps" that will help drive Win2003 upgrades. Any NT or 2000 Web servers you've got will benefit from a 2003 upgrade. Microsoft even offers Windows Server 2003 Web Edition, which is a stripped-down version of Windows intended primarily as a platform for Web servers. It's a lower-cost version of Windows Server 2003 (the lowest, in fact) and gives you everything that IIS 6 will become famous for.