IIS6处理模型
IIS5 中有两个弊端，其一是ISAPI与工作进程分离，会存在性能瓶颈;其二是所有ASP.NET应用程序存在于同一个进程中，应用程序间会存在影响。
针对这两个问题，作了两个改进，引入了应用程序池以及把ISAPI放到工作进程中。
此外IIS6中在系统内核层面引入了HTTP.SYS处理监听HTTP请求。其好处是可以持续监听，更好的稳定性和内核模式下数据缓存。Inetinfo.exe单纯用于存储ISAPI的配置信息，W3SVC则寄宿于另一个进程SvcHost.exe中，其内部职能并没有发生任何变化，功能实现做了改进。
IIS7处理模型
在IIS7中引入了 Windows 进程激活服务( Windows Process Activation Service ， WAS )的引入，将原来( IIS 6.0 ) W3SVC 承载的部分功能分流给了 WAS 。实际上是对监听这一环节开放了可扩展的接口。W3SVC还是存储原有的HTTP请求的监听，但这也成为了它唯一的职责，后续的读取ISAPI信息和工作进程管理那块则移交给WAS。扩展的监听接口看介绍是在WCF方面比较有用，现在暂且不关注它。ISAPI的配置信息也不依赖于原有的Metabase，改用了applicationHost.config。
IIS7的集成模式肯定也要提到，在前面介绍httpHandlers的时候也提到IIS7有经典模式和集成模式。IIS7之前是使用双管道处理Http请求，在IIS中有一堆模块处理(例如身份认证)，同样在Http管道中有重复的处理。而在IIS7中新增了集成模式可以使得这两个管道处理变成单一管道统一处理。IIS7中同样保留了双管道的处理模式，称之为经典模式。在经典模式中对扩展的HttpModule和HttpHandler只作用于ISAPI扩展过的这些资源，但对静态资源是没有作用的，假设使用了集成模式，因为是单一管道统一处理，不管动态还是静态都会被httpModule和HttpHandler处理。
上面介绍的几个IIS处理模型都是在HttpRuntime生成前，到了.NET Runtime的范围内，HttpRuntime才开始被创建出来。关于如何被生成，如何被调用鄙人则不想再粘贴代码了。想看的话还是那个链接：舍长的《 深入理解 ASP.NET 的内部运行机制 》。
以上都是人云亦云的内容，在经峰哥教导后我觉得这样学习就不踏实了，可惜好像还没有任何有效途径去验证这些说法。至少在MSDN上也还没发现相关内容。