aspnet_isapi.dll 和 aspnet_wp.exe 之间的通信

Question

MSDN article 声明：

为保证最佳性能， aspnet_isapi 使用异步命名 管道将请求转发到 工作进程并获得响应。 另一方面，工作进程 当它利用同步管道时 需要查询有关信息 IIS 环境（即服务器 变量）。

1. 工作进程是否总是使用“同步”命名管道？ （对 aspnet_isapi.dll 的响应也是异步的，对吧？）
2. 工作进程是否可以直接与 IIS 对话，还是必须向 aspnet_isapi.dll 发送同步请求以查询 IIS 环境等？

Answer 1

在同一篇文章的后面，事情变得更清楚了，:p :

处理每个 ASP.NET 请求背后的逻辑可以概括为以下步骤。

1. 当请求到达时，IIS 检查资源类型并调用 ASP.NET ISAPI 扩展。如果启用了默认进程模型，aspnet_isapi 会将请求排队并将其分配给工作进程。任何请求数据都是通过异步 I/O 发送的。如果启用 IIS 6 进程模型，请求会自动排队到处理应用程序所属的 IIS 应用程序池的工作进程 (w3wp.exe)。 IIS 6 工作进程对 ASP.NET 和托管代码一无所知。它仅限于处理 *.aspx 扩展名和加载 aspnet_isapi 模块。当 ASP.NET ISAPI 在 IIS 6 进程模型下工作时，它的行为有所不同，只是在 w3wp.exe 工作进程的上下文中加载 CLR。​​
2. 在收到请求后，ASP.NET 工作进程通知 ASP.NET ISAPI 它将为其提供服务。通知通过同步 I/O 进行。使用同步模型是因为为了保持一致性，工作进程无法开始处理在 ISAPI 的内部请求表中尚未标记为“正在执行”的请求。 由特定工作进程处理的请求不能除非原来的进程死亡，否则将被重新分配到不同的进程。
3. 请求在工作进程的上下文中执行。 可能存在工作进程需要回调 ISAPI 以完成请求（即枚举服务器变量）的情况。在这种情况下，工作进程使用同步管道，因为这将保留请求处理逻辑的顺序。
4. 完成后，响应被发送到 aspnet_isapi 打开一个异步管道。 请求的状态现在变为“完成”；稍后该请求将从表中删除。如果工作进程崩溃，它正在处理的所有请求都会在一段时间内保持“正在执行”状态。当 aspnet_isapi 检测到工作进程已死时，它会自动中止请求并释放所有关联的 IIS 资源。

所以，我认为我的第一个问题的答案是否，而上面的第二点 3 暗示 worker 进程不直接访问 IIS，而是通过 aspnet_isapi.dll .