How HTTP.sys forward request to worker process

Question

I wanted to get an overview of the way HTTP.sys forwards request to work process in IIS 7.0 and above. For that purpose I read the post at http://www.iis.net/learn/get-started/introduction-to-iis/introduction-to-iis-architecture. However, there are two points in this post that seem to be contradicting and is confusing me.

Point 1: 2nd bullet point mentioned under section "Hypertext Transfer Protocol Stack (HTTP.sys)" is as follows.

Kernel-mode request queuing. Requests cause less overhead in context switching because the kernel forwards requests directly to the correct worker process. If no worker process is available to accept a request, the kernel-mode request queue holds the request until a worker process picks it up.

My conclusion according to this point is as follows: HTTP.sys forwards request "directly" to worker process bypassing the WWW service. In case no worker process is available, HTTP.sys queues the request in kernel-mode request queue while WAS service starts a new worker process. This worker process then picks up requests from the kernel-mode queue on its own.

Point 2: Process Management subsection under the section "Windows Process Activation Service(WAS)" is as follows.

WAS manages application pools and worker processes for both HTTP and non-HTTP requests. When a protocol listener picks up a client request, WAS determines if a worker process is running or not. If an application pool already has a worker process that is servicing requests, the listener adapter passes the request onto the worker process for processing. If there is no worker process in the application pool, WAS will start a worker process so that the listener adapter can pass the request to it for processing.

My conclusion according to this point is as follows: HTTP.sys forwards request to the worker process "through WWW service" as that is the listener adapter. In case no worker process is available, HTTP.sys queues the request in kernel-mode request queue while WAS service starts a new worker process. The request from the kernel-mode queue is then picked up by WWW service and forwarded to the worker process.

Could anyone please let me know which of my above two conclusions is correct? If both are incorrect, please let me know the right flow.

Answer 1

I dont think either is correct. I was also trying to figure out the exact workings and finally found the HTTP Server API, https://learn.microsoft.com/en-us/windows/desktop/http/http-version-2-0-architecture.

"HTTP.sys forwards request to the worker process "through WWW service" as that is the listener adapter." From the documentation above, and here https://learn.microsoft.com/en-us/windows/desktop/http/process-isolation, you can seen the HTTP Kernel Mode(http.sys) routes requests to queues that are associated with urls. The queue would have been configured when the app pool was created in iis mgr and the urls would have been associated with the queue when you create a website in IIS mgr and tie the website to a pool. http.sys puts stuff in queues. The app pool process processes stuff from the queues. No direct interaction between http.sys and worker process.

"In case no worker process is available,..." this is not true either from the Process Isolation documentation above:

Creator or controller process: The controller process can run with, or without, administrative privileges to monitor the health and configure the service. The controller process typically creates a single server session for the service and defines the URL groups under the server session. The URL group that a particular URL is associated with determines which request queue services the namespace denoted by the particular URL. The controller process also creates the request queue and launches the worker processes that can access the request queue. Worker Process: The worker processes, launched by the controller process, perform IO on the request queue that is associated with the URLs they service. The web application is granted access to the request queue by the controller process in the ACL when the request queue is created. Unless the web application is also the creator process, it does not manage the service or configure the request queue. The controller process communicates the name of the request queue to the worker process and the worker process opens the request queue by name. Worker processes can load third party web applications without introducing security vulnerabilities in other parts of the application.

So the controller process would create the workers. This is without a doubt the WAS, exactly how it detects when to create a process is not defined, but its definitely the "controller process" spoken about above.

Interesting, in asp.net core you can run your app on top of http.sys, Microsoft.AspNetCore.Server.HttpSys. Interntally it uses this api to configure things. https://github.com/aspnet/HttpSysServer/blob/master/src/Microsoft.AspNetCore.Server.HttpSys/NativeInterop/HttpApi.cs.

This documentation cleared up a lot of confusion for me. I hope it helps.