HTTP.sys 请求队列和 IIS 应用程序池之间的关系
我从<< IIS 7.0资源工具包>>
HTTP.sys 为每个工作进程维护一个请求队列。它将 HTTP 请求发送到工作进程的请求队列，该工作进程为所请求的应用程序所在的应用程序池提供服务。 对于每个应用程序，HTTP.sys 维护具有一个条目的 URI 命名空间路由表。路由表数据用于确定哪个应用程序池响应来自命名空间哪些部分的请求。每个请求队列对应一个应用程序池。 应用程序池对应HTTP.sys中的一个请求队列和一个或多个工作进程。
粗体部分让我感到困惑。 我的理解是：HTTP.sys为每个工作进程维护一个请求队列。一个应用程序池可以有一个或多个工作进程。所以一个应用程序池也应该对应一个或多个请求队列。为什么粗体句子中只有一个？
顺便说一句，谁能对 URI 命名空间路由表给出更清晰的解释？一些例子会更好。
谢谢。
I read this from < IIS 7.0 resource kit >
HTTP.sys maintains a request queue for each worker process. It sends the HTTP requests to the request queue for the worker process that serves the application pool where the requested application is located.
For each application, HTTP.sys maintains the URI namespace routing table with one entry. The routing table data is used to determine which application pool responds to requests from what parts of the namespace. Each request queue corresponds to one application pool. And application pool corresponds to one request queues within HTTP.sys and one or more worker processes.
The bold parts confused me.
My understanding is: HTTP.sys matain a request queue for each worker process. An application pool can have one or more worker processes. So an application pool should also corresponds to one or more request queues. Why only one in the bold sentence?
And btw, could anyone give a more clear explanation about the URI namespace routing table? Some examples would be better.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
监听者需要接收消息。为此，它需要打开一个套接字（或管道句柄，或启动 MSMQ 读取，等等）。然而，为了接收正确的消息，它需要从WAS获取必要的寻址信息。这是在侦听器启动期间完成的。该协议的侦听器适配器调用 WAS 侦听器适配器接口上的函数，实质上是说：“我现在正在侦听 net.tcp 协议；请使用我交给您的这组回调函数来告诉我需要知道的内容。 ”作为响应，WAS 将回调其为设置为通过相关协议接受消息的应用程序所拥有的任何配置。例如，TCP 侦听器将被告知有两个应用程序（*:7777/Foo 和 *:7777/Bar）配置为使用 TCP。 WAS 还为每个应用程序分配一个唯一的侦听器通道 ID，用于将请求与其目标应用程序相关联。
侦听器进程使用 WAS 提供的配置信息来构建路由表，该路由表将在传入请求到达时将其映射到侦听器通道 ID。
A listener needs to receive messages. For this, it needs to open a socket (or a pipe handle, or start an MSMQ read, and so on). However, in order to receive the proper messages, it needs to obtain the necessary addressing information from WAS. This is accomplished during listener startup. The protocol's listener adapter calls a function on the WAS listener adapter interface and essentially says, "I am now listening on the net.tcp protocol; please use this set of callback functions I'm handing you to tell me what I need to know." In response, WAS will call back with any configuration it has for applications that are set up to accept messages over the protocol in question. For example, a TCP listener would be informed that there were two applications (*:7777/Foo and *:7777/Bar) configured to use TCP. WAS also assigns to each application a unique listener channel ID used for associating requests with their destination applications.
The listener process uses the configuration information provided by WAS to build up a routing table, which it will use to map incoming requests to listener channel IDs as they arrive.
这是不正确的 1 个应用程序池 = 1 个工作进程
This is not correct 1 App Pool = 1 Worker Process
要讨论书中的某个段落，您应该提供更多信息。
本段来自“IIS 7.0核心组件”部分，Safari Books Online上的版本与您粘贴的不同，
所以最后一句应该理解为，
因此，您对“HTTP.sys 为每个工作进程维护一个请求队列”的理解是不正确的。正确的应该是“HTTP.sys 为每个应用程序池维护一个请求队列”。因此，无论单个应用程序池有多少个工作进程，它们都只为来自 http.sys 中单个请求队列的请求提供服务。
我认为应该是“对于每个应用程序池，HTTP.sys 维护具有一个条目的 URI 命名空间路由表”。这个路由表使分派请求变得更容易（其 URL 是与池非常相似，
该表可以通过组合站点、它们的绑定、应用程序及其应用程序池关联，从 applicationHost.config 中的
To discuss a paragraph in a book, you should give more info.
This paragraph comes from "IIS 7.0 Core Components" section, and the version at Safari Books Online is different from what you pasted,
So the last sentence should be understood as,
Thus, your understanding of "HTTP.sys maintains a request queue for each worker process" is not correct. The correct one should be "HTTP.sys maintains a request queue for each application pool". So no matter how many worker processes are there for a single application pool, they only serve requests from a single request queue in http.sys.
I think it should be "for each application pool, HTTP.sys maintains the URI namespace routing table with one entry". This routing table makes it easier to dispatch requests (whose URL is clear) to the pools. Very similar to a hash table.
The table can be constructed from
<sites>tag in applicationHost.config, by combining sites, their bindings, applications, and their application pool association. There is no further information from Microsoft on the exact table structure.我正在努力解决同样的问题...但我认为过程如下：
=>如果工作进程可用，则请求现在转发到正确的工作池。
如果没有工作进程可用，则请求将存储在应用程序队列中。 HTTP.sys 现在将通知 WAS（通过 WWW 服务）新请求已添加到队列中。 WWW 服务将向 WAS 请求工作进程。 WAS 将生成一个应用程序池并让 WWW 知道应用程序池已创建。现在WWW可以将请求传递给相应的工作进程（通过将其添加到其队列队列中）。然后 WWW 会让 HTTP.sys 知道生成了一个工作进程，因此下一个请求，HTTP.sys 可以立即转发该请求...
我不完全确定这在技术上是否完全正确，所以如果有人可以纠正/确认这一点，那就太好了！
I am struggling with the same question... but I think the process is as follows:
=> if a worker process is available, the request is now forwarded to the correct worker pool
If no worker process is available, the request is stored in the application queue. HTTP.sys will now notify WAS (via the WWW service) that a new request has been added to the queue. The WWW service will ask WAS for a worker process. WAS will spawn one and let WWW know that an app pool has been created. Now WWW can pass the request to the corresponding worker process(by adding it to its queue queue). Then WWW will let HTTP.sys know that a worker process is spawned, so the next request, HTTP.sys can forward the request immmediatly...
I am not completely sure if this is technically all correct, so if anyone could correct/confirm this, that would be great!