Mit HTTP.sys können sich mehrere Applikation denselben Port teilen!
HTTP.sys is the protocol listener that listens for HTTP and HTTPS requests.
HTTP.sys was introduced in IIS 6.0 as an HTTP-specific protocol listener for HTTP requests. In IIS 7.0, HTTP.sys also includes support for Secure Sockets Layer (SSL), which Lsass.exe provided in IIS 6.0.
HTTP.sys is a kernel-mode device driver for HTTP protocol stack. It is part of the networking subsystem of the Windows operating systems. Beginning with IIS 6.0, this kernel-mode driver replaced Windows Sockets API (Winsock), which was a user-mode component that previous versions of IIS used to receive HTTP requests and send HTTP responses.
When a client browser requests a Web page from a site on the IIS 7.0 server, HTTP.sys picks up the request on the site binding on the server machine and then passes it to the worker process for processing. After the request has been processed, HTTP.sys returns a response to the client browser.
Apart from intercepting and returning HTTP requests, HTTP.sys also performs the following tasks:
Preprocessing and security filtering of the incoming HTTP requests
Queuing of HTTP requests for the application pools
Caching of the outgoing HTTP responses
HTTP.sys maintains a request queue for each worker process. It sends the HTTP requests it receives 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. An application pool corresponds to one request queue within HTTP.sys and one or more worker processes.
If a faulty application causes a worker process failure, service is not interrupted, and the failure is undetectable by an end user because the kernel queues the requests while the WAS service starts a new worker process for that application pool. When the WAS service identifies an unhealthy worker process, it starts a new worker process if outstanding requests are waiting to be serviced. Although a temporary disruption occurs in user-mode request processing, the user does not experience the failure, because TCP/IP connections are maintained, and requests continue to be queued and processed. Only those requests that are running in the worker process when it fails will result in users seeing an error status. The requests that haven’t been processed yet will be redirected to the new worker process.
Other than retrieving a stored response from its internal cache, HTTP.sys does not process the requests that it receives. Therefore, no application-specific code is ever loaded into kernel mode but is processed inside the worker process that runs in the user mode. As a result, bugs in application-specific code cannot affect the kernel or lead to system failures.