内容摘要：Windows Server 2003 里那个 IIS 6.0，放到今天来看，像个脾气古怪但干活扎实的老伙计。2003年发布那会儿，微软在 IIS 5.0 上栽的跟头够狠——Code Red 和 Ni

Windows Server 2003 里那个 IIS 6.0，放到今天来看，像个脾气古怪但干活扎实的老伙计。2003年发布那会儿，微软在 IIS 5.0 上栽的跟头够狠——Code Red 和 Nimda 蠕虫顺着 IIS 的漏洞把半个互联网搅得鸡飞狗跳。所以 IIS 6 不是一次常规升级，是推倒重来的安全重构。

核心变化是引入了 HTTP.sys 内核驱动。IIS 5 里，每个网站请求都直接扔给用户态的 inetinfo.exe 进程处理，一个站点崩了，整个 IIS 跟着趴窝。IIS 6 把 HTTP 请求的监听和排队搬到内核层，由 HTTP.sys 统一接管，然后再分发给不同的工作进程。这就像原来所有客人直接冲进厨房点菜，现在门口先有个领班统一登记排号。稳定性提升是肉眼可见的。

另一个狠招是应用程序池。你可以把不同网站丢进不同的 w3wp.exe 进程里跑。A 站点内存泄漏把自己撑死了？没关系，B 站点在另一个池子里活得好好的。这个设计在当时算革命性的，后来 IIS 7 直接继承下来。我见过有人把所有站点全塞进默认的 DefaultAppPool，然后一个 ASP 页面死循环把整个服务器拖垮——这跟 IIS 6 的设计初衷完全背道而驰。

配置管理这块，IIS 6 用了一个叫 metabase 的 XML 文件，路径在 C:\Windows\System32\inetsrv\MetaBase.xml。跟 IIS 4/5 的二进制 metabase 比，可读性好多了。但有个坑：你直接编辑这个文件，IIS 不会自动重载，得重启 IIS 服务或者用 iisreset。更稳妥的方式是通过 adsutil.vbs 脚本操作，微软在 inetpub\adminscripts 目录下塞了一堆这种 vbs 工具。当年我改站点绑定端口，用 adsutil 敲命令行比打开图形界面快得多。

说到图形界面，IIS 6 管理器长得跟 Windows 资源管理器似的，左边树形目录，右边操作面板。功能上够用，但批量操作基本靠脚本。你要是管五十个站点，一个个点属性对话框能点到手抽筋。所以那时候稍微像样点的运维，都会写点 vbs 或者用 iiscnfg.vbs 导出配置再批量改。

ASP.NET 的支持在 IIS 6 上是分水岭。IIS 5 跑 ASP.NET 要靠一个 ISAPI 扩展通配符映射，性能一般。IIS 6 原生支持 ASP.NET 1.1，进程模型跟应用程序池配合得不错。不过 32 位和 64 位版本有差异，x64 的 Windows 2003 默认跑 64 位 IIS，但很多老组件只有 32 位版本，你得用 adsutil 把 Enable32BitAppOnWin64 打开。这操作当年坑了不少人。

安全方面，IIS 6 默认只启用静态 HTML 支持。ASP、ASP.NET、CGI 这些统统关着，要手动在 Web 服务扩展里允许。这个“默认拒绝”策略在当时挨了不少骂，说微软矫枉过正。但对比 IIS 5 那个默认全开的德行，我站 IIS 6 这边。管理员多动两下鼠标，总比服务器被挂马强。

日志格式也值得提一嘴。IIS 6 支持 W3C 扩展日志，字段可以自定义。默认只记时间、IP、方法、URI、状态码这些。你要查 User-Agent 或者 Referer，得手动勾选。日志文件按天切分，放在 C:\Windows\System32\LogFiles 下面。当年分析日志用 LogParser 配合 IIS 6 的日志，效率还行，就是 LogParser 的 SQL 语法得查文档。

这玩意儿放到现在，早就不该出现在生产环境了。微软 2015 年就停止了 Server 2003 的扩展支持。但总有些内网系统、老 ERP、工控设备还跑在上面。你如果非碰不可，记住三件事：别把站点放默认池、定期看 w3wp 的内存占用、metabase 改之前先备份。剩下的，就把它当个脾气差但还能干活的老家伙使唤吧。