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_isapidetects工作进程已经死亡时，它会自动中止请求并释放任何相关的IIS资源。

所以，我认为我的第一个问题的答案是否，而上面的第二点意味着工作进程不直接访问IIS但是通过aspnet_isapi.dll