本文共 1764 字，大约阅读时间需要 5 分钟。
IIS 和 ASP.NET 的处理过程经历了从 IIS 5 到 IIS 7 的多次演变。本文将从底层机制入手，分析不同版本的 IIS 如何处理 ASP.NET 请求。
IIS 5 的 ASP.NET 请求处理过程
IIS 5.x 的一个显著特点是将 Web Server 和 ASP.NET Application 完全分离。IIS 运行在 InetInfo.exe 这个 Native Executive 进程中，而 ASP.NET Application 则运行在 aspnet_wp 这个 Worker Process 上。InetInfo.exe 负责监听和分发请求，而 aspnet_wp 则负责处理实际的业务逻辑。
IIS 5 模式的特点主要包括：
单进程模型：同一台主机上只能运行一个 aspnet_wp 进程，但多个 ASP.NET Application 可以共享这个进程，每个 Application运行在独立的 Application Domain 中。 进程监控机制：ASP.NET ISAPI 负责监控 aspnet_wp 的性能，如果检测到性能下降到一定阈值，会自动终止该进程，并在后续请求中重新创建新的 Worker Process。 进程间通信：IIS 和 Worker Process 之间采用 Named pipe 的通信机制，既保证了性能，也确保了不同进程之间的安全性。通信双方分别使用异步和同步方式处理请求。 IIS 6 的 ASP.NET 请求处理过程
IIS 6 引入了重大变化，将之前在 User Mode 中运行的监听和请求分发功能改迁至 Kernel Mode，通过 http.sys 来完成。这种设计不仅提高了性能，还为后续版本的扩展奠定了基础。
IIS 6 的主要特点包括：
Kernel Mode监听：http.sys 负责监听和分发请求，运行在 Kernel Mode，这意味着它能够直接访问操作系统内核层的资源，显著提升了性能。 Application Pool 统一管理：每个 Application Pool 对应一个 Worker Process (w3wp.exe)，WAS 根据 Application Pool 的配置信息决定如何分发请求。 进程间通信优化：虽然仍然采用 Named pipe 的通信方式，但通过优化协议栈和处理流程，通信效率得到了显著提升。 IIS 7 的 ASP.NET 请求处理过程
IIS 7 对 ASP.NET 的处理机制进行了全面优化，特别是在应用程序池的托管管道模式上实现了更大的灵活性。IIS 7 提供了两种托管管道模式：经典模式和集成模式。
IIS 7 的主要特点包括：
架构简化：通过将 ASP.NET 集成到 IIS 核心，减少了中间层的依赖，提升了性能和可扩展性。 两种托管管道模式： - 经典模式：与 IIS 6 一样，通过 ISAPI extension 处理请求，兼容性更好。
- 集成模式：将 ASP.NET 模块直接嵌入到 IIS 核心，提升了对 ASP.NET 功能的整合性和控制能力。
IIS 6 和 IIS 7 的托管管道架构
IIS 7 引入了更为灵活的托管管道模式，主要体现在对 ASP.NET 的深度整合上。与 IIS 6 相比，IIS 7 的架构更为高效，处理流程也更加简化。
IIS 7 的托管管道架构主要包括以下几个方面：
经典模式：与 IIS 6 一样，通过 ISAPI extension 处理请求，适合需要与 IIS 6 兼容的场景。 集成模式：将 ASP.NET 模块直接嵌入到 IIS 核心，提升了对 ASP.NET 功能的整合度和控制能力。 总结
从 IIS 5 到 IIS 7，ASP.NET 的处理过程经历了从分离式到集成式的演变。IIS 5 的单进程模型和简单的进程监控机制为初步的商业应用提供了支持，而 IIS 6 的 Kernel Mode监听和统一的 Application Pool 管理则显著提升了性能和可扩展性。IIS 7 的集成式托管管道模式则进一步优化了架构，提升了对 ASP.NET 功能的整合能力，为现代 Web 应用开发奠定了坚实的基础。
转载自：原文链接