我从< IIS 7.0资源工具包>
HTTP.sys为每个工作进程维护一个请求队列。它将HTTP请求发送到工作进程的请求队列,该进程为请求的应用程序所在的应用程序池提供服务。 对于每个应用程序,HTTP.sys使用一个条目维护URI命名空间路由表。路由表数据用于确定哪个应用程序池响应来自命名空间的哪些部分的请求。每个请求队列对应一个应用程序池。 应用程序池对应于HTTP.sys和一个或多个工作进程中的一个请求队列。
大胆的部分让我困惑。 我的理解是:HTTP.sys为每个工作进程提供一个请求队列。应用程序池可以有一个或多个工作进程。因此,应用程序池也应该对应于一个或多个请求队列。为什么只有一个大胆的句子?
顺便说一下,有没有人可以对 URI名称空间路由表做出更明确的解释?一些例子会更好。
感谢。
答案 0 :(得分:2)
要讨论书中的段落,您应该提供更多信息。
本段来自" IIS 7.0核心组件"部分,Safari Books Online的版本与您粘贴的版本不同,
HTTP.sys为每个工作进程维护一个请求队列。它发送 它接收到的HTTP请求到工作者的请求队列 为请求的应用程序池提供服务的进程 应用程序位于。对于每个应用程序,HTTP.sys维护 URI命名空间路由表,带有一个条目。路由表数据是 用于确定哪个应用程序池响应来自的请求 命名空间的哪些部分。每个请求队列对应一个 应用程序池。 应用程序池对应一个请求队列 在HTTP.sys和一个或多个工作进程中。
所以最后一句应理解为,
因此,您对" HTTP.sys的理解为每个工作进程维护一个请求队列"是不正确的。正确的应该是#34; HTTP.sys为每个应用程序池维护一个请求队列"。因此,无论单个应用程序池有多少个工作进程,它们只提供来自http.sys中单个请求队列的请求。
"对于每个应用程序,HTTP.sys维护URI命名空间路由 有一个条目的表"
我认为它应该是#34;对于每个应用程序池,HTTP.sys维护URI名称空间路由表,其中包含一个条目"。此路由表可以更轻松地将请求(其URL清除)分派给池。非常类似于哈希表。
可以通过组合站点,绑定,应用程序及其应用程序池关联,从applicationHost.config中的<sites>
标记构建表。 Microsoft没有关于确切表结构的进一步信息。
答案 1 :(得分:1)
我正在努力解决同样的问题......但我认为这个过程如下:
=&GT;如果工作进程可用,则请求现在转发到正确的工作池
如果没有可用的工作进程,则请求将存储在应用程序队列中。 HTTP.sys现在将通知WAS(通过WWW服务)已向队列添加了新请求。 WWW服务将要求WAS提供工作进程。 WAS将产生一个,让WWW知道已经创建了一个应用程序池。现在,WWW可以将请求传递给相应的工作进程(通过将其添加到其队列队列)。然后WWW会让HTTP.sys知道一个工作进程被生成,所以下一个请求,HTTP.sys可以立即转发请求...
我不完全确定这在技术上是否都是正确的,所以如果有人能够纠正/确认这一点,那就太棒了!
答案 2 :(得分:0)
侦听器需要接收消息。为此,它需要打开一个套接字(或一个管道句柄,或启动一个MSMQ读取,依此类推)。但是,为了接收适当的消息,它需要从WAS获得必要的寻址信息。这是在监听器启动期间完成的。协议的侦听器适配器调用WAS侦听器适配器接口上的一个函数,基本上说,&#34;我现在正在监听net.tcp协议;请使用这套回调函数,我告诉我需要知道的内容。&#34;作为响应,WAS将回调它所具有的任何配置,用于设置为通过相关协议接受消息的应用程序。例如,TCP侦听器将被通知有两个应用程序(*:7777 / Foo和*:7777 / Bar)配置为使用TCP。 WAS还为每个应用程序分配一个唯一的侦听器通道ID,用于将请求与其目标应用程序相关联。 侦听器进程使用WAS提供的配置信息来构建路由表,它将用于将传入的请求映射到侦听器通道ID。
答案 3 :(得分:-2)
应用程序池可以有一个或多个工作进程
这不正确1 App Pool = 1工作进程