Http请求处理流程

标签：

本文结构：

一、HTTP请求处理流程的基础

1．网络分层

因特网TCP/IP分层模型共有五层：应用层、传输层、网络层、网络接口层和物理层。这种分层模型不同于OSI七层参考模型，但是，是实际使用中采用的分层方式。

ISO提出的OSI（Open System Interconnection）模型将网络分为七层，即物理层( Physical )、数据链路层(Data Link)、网络层(Network)、传输层(Transport)、会话层(Session)、表示层(Presentation)和应用层(Application)。

TCP/IP分层模型（TCP/IP Layering Model）被称作因特网分层模型（Internet Layering Model）、因特网参考模型（Internet Reference Model）。

TCP/IP是事实的标准，所以自然取其前三层协议【应用层、传输层、网络层（网间层）】作为网络分层。而又， TCP/IP标准并不定义与OSI七层参考模型中的数据链路层和物理层相对应的功能。为了衔接这两层，它定义了像地址解析协议(Address Resolution Protocol，ARP)这样的协议，提供TCP/IP协议的数据结构和实际物理硬件之间的接口。所以，将在网络层（网间层）之下，将由ARP、RAPR等协议组成的层，作为新的一个分层（网络接口层）。该层又恰巧位于数据链路层和物理层之上。一般的适配器（网卡）都包括了数据链路层和物理层这两层的功能。所以，在TCP/IP分层模型中，又将OSI七层参考模型中数据链路层和物理层合称为“物理层”。

所以，因特网TCP/IP分层模型共有五层：应用层、传输层、网络层、网络接口层和物理层。虽然与OSI七层参考模型在名称上相同的文字，但有的并不指相同的东西。

TCP/IP分层模型，是我们“现实所见”的各层。它是现实存在的，所以通过它，我们可以用比较简单的方式，理解现实网络是如何按网络分层的方式搭载起来的。

2．端口

在网络上，各主机间通过TCP/IP协议发送和接收数据包，各个数据包根据其目的主机的IP地址来进行互联网络中的路由选择，把数据包顺利的传送到目的主机。大多数操作系统都支持多程序（进程）同时运行，那么目的主机应该把接收到的数据包传送给众多同时运行的进程中的哪一个呢？显然这个问题有待解决，端口机制便由此被引入进来。

本地操作系统会给那些有需求的进程分配协议端口（protocol port，即我们常说的端口），每个协议端口由一个正整数标识，如：80，139，445，等等。当目的主机接收到数据包后，将根据报文首部的目的端口号，把数据发送到相应端口，而与此端口相对应的那个进程将会领取数据并等待下一组数据的到来。

端口其实就是队，操作系统为各个进程分配了不同的队，数据包按照目的端口被推入相应的队中，等待被进程取用。在极特殊的情况下，这个队也是有可能溢出的，不过操作系统允许各进程指定和调整自己的队的大小。

不光接受数据包的进程需要开启它自己的端口，发送数据包的进程也需要开启端口，这样，数据包中将会标识有源端口，以便接受方能顺利地回传数据包到这个端口。

3.网站、应用程序、虚拟路径

出处：

http://www.iis.net/learn/get-started/planning-your-iis-architecture/understanding-sites-applications-and-virtual-directories-on-iis

在IIS 6.0，虚拟路径和应用程序两个概念，很容易让人迷惑的。在技术实现上，界线不是很清晰。应用程序与虚拟路径，并没有完全切割开。同时，对诸如ASP、ISAPI、ASP.NET等扩展了服务器功能的技术来说，“应用程序”这个概念又比在IIS上更加重要。这些技术势必使应用程序更加复杂，从而导致了IIS 6一个重要的问题，同个“如此复杂的应用程序”在不同应用程序池中不能相互隔绝（原话：The important question for IIS 6.0 was isolating such applications in a way that would prevent applications in one application pool from affecting applications in another application pool on the server.）。

在IIS 7，网站、应用程序和虚拟路径，是相互独立的概念。一个网站可以包含一个或者多个应用程序；一个应用程序可以包含一个或者多个虚拟路径；一个虚拟路径对应一个物理路径。

另外，由于IIS和ASP.NET的请求处理管道的合并，促使了页面可以预先利用托管代码应用程序提供的功能。举个例子，每个托管代码应用程序都运行在一个应用程序域（AppDomain）中（注：上面提到的托管代码应用程序提供的功能）。而一个应用程序可以有多个虚拟路径，这样，就可通过相同的应用程序域（当作应用程序）访问每个虚拟路径。【原话：This is because the IIS and ASP.NET request-processing pipelines have merged in IIS 7 and above so that content can take advantage of functionality previously provided for only managed code applications. For example, each managed code application runs in an Application Domain (AppDomain). An application can have several virtual directories, and each one will be served by the same AppDomain as the application to which they belong.】

1）网站

网站包括两个重要的绑定：一个是协议绑定，一个是信息绑定。“协议绑定”所绑定的协议是客户端和服务器交流的协议（例如HTTP）。“信息绑定”是用于访问网站用的，比如IP址、端口等。如有需要，可以有多个协议绑定和信息绑定。

在早期版本的IIS中，只能支持HTTP、HTTPS的绑定，而在IIS 7 及更高版本中，可以绑定任何协议。这是由于Windows Process Activation Service (WAS)的改进。在IIS 7 及更高版本中，WAS保留了在IIS 6 相似的处理模式，比如，应用程序池、基于消息的进程激活；快速的故障保护（rapid failure protection）、监听以及回收等。同时，WAS移除了依赖于HTTP的架构。这促使了应用程序与应用程序能够通过标准协议进行交流。WCF的程序设计模型就是应用了这种技术，使得能够通过标准协议（TCP、MSMQ等）进行通信交流。这种技术，让采用了标准通信协议的应用程序（WCF）能够利用IIS的特性，如进程回收（process recycling）、快速故障保护（rapid failure protection）、以前只有基于http的应用程序的配置等。

以下配置设置也属于网站：

（1）连接超时：带宽限制、连接数、站点连接时间

（2）日志：处理和存储日志文件的配置的设置。

（3）失败请求痕迹日志：记录失败请求痕迹的配置的设置。

2）应用程序

每人网站必须有一个默认应用程序，叫做根应用程序或者默认应用程序。一个网站可以有多个应用程序。

除了属于一个网站，应用程序也属于一个应用程序池。应用程序池用于隔离其他应用程序池里的应用程序。托管应用程序与其所属的应用程序池的.net框架版本必须一致。

IIS默认支持HTTP及HTTPS，同时也支持另外的协议。每个网站有一个或者多个“绑定协议”和“绑定信息”。应用程序必须启用其所需的协议（这个协议必须是其所属网站的绑定协议），如果是非HTTP/HTTPS时，又必须保证服务器上有对应的监听适配程序，并在配置文档中配置<listenerAdapters>节点。

3）虚拟路径

虚拟路径，在IIS中指定的一个目录名，用于映射本地或者远程服务器的物理路径。这个指定的目录名将成URL一部分。每个应用程序都有一个虚拟路径，用于映射包含了“应用程序内容（the application‘s content）”的物理路径，这个虚拟路径被称为根虚拟目录。然而一个应用程序可以有多个虚拟路径。举个例子，你有一个（物理的）目录包含一些图片文件，你希望这些图片包含到应用程序中，但又不想将这些图片文件移到根虚拟目录对应的物理路径下，这时你就可以为这个应用程序再指定一个虚拟路径，映射到这些图片文件所在的物理路径。

可以为虚拟路径指定用户名、密码、登录方法。

IIS默认使用物理路径及其子路径下的Web.config配置。如果不希望使用子目录的Web.config，则需要配置：

<sites><site>…<site>…<virtualDirectoryDefaults allowSubDirConfig="false " /></sites>

4）IIS配置

（1）配置文件所在位置：%windir%\system32\inetsrv\config \

（2）<sites>节点下的集合与元素的层级关系

（3）<applicationDefaults>与<virtualDirectoryDefaults>的意义

<applicationDefaults> 的父元素不同时，其所指的意义也不同：

<virtualDirectoryDefaults>的父元素不同时，其所指的意义也不同：

二、IIS架构

1.概述

无论是怎样的HTTP请求处理流程，都必须讲究一些必要的“规则”（即遵守一些共同的机制）。

1）其中，最重要的一个“规则”就是保证同一台服务器上的各站点、各应用程序的隔离。

2）第二个比较重要的“规则”就是，将HTTP请求开放给由开发网站的程序员开发的“应用程序”，由这些“应用程序”进行HTTP请求的处理。（当然，在不同的HTTP请求处理机制或者配置下，存在将资源直接返回到客户端的情况）。

3）为实现上述两个规则，几个IIS版本，都共同采用了一些相同的方式：

（1）维护着一份脚本映射扩展表，将请求映射到应用程序池、工作者进程等。

（2）管道技术是很好的衔接程序员代码的方式。

2.监听

无论是怎样的系统，怎样的HTTP请求处理流程，第一步，永远是让某一“进程”监听80端口。

在IIS 7处理模型中，监听程序是作为Windows操作系统内核的一部分运行的，叫做HTTP.sys。它接收从网络来的HTTP请求，安全过滤及预处理后，将其传给IIS，交由IIS作更进一步的处理。最后，它又接收IIS处理后的结果，并将结果（响应）返回到客户端的浏览器。

HTTP.sys在IIS 6就已经出现。而在比IIS 6更早的版本中，监听程序是Windows Sockets API (Winsock)，它运行在操作系统的用户模式上，并非在内核模式中。

关于HTTP.sys知识点还有：

1）内核模式缓存。HTTP.sys缓存历史响应，当重新遇到相同请求时，直接返回仍然有效的响应，而无需切换到用户模式（IIS处理）。

2）维护一个内核模式的请求队列。HTTP.sys直接将请求转发到正确的工作者进程（通过WAS等协助，映射找到相应的工作者进程）。如果没有工作进程可以接受请求，内核模式的请求队列保留该请求，直到工作者进程接收走请求。

3）请求的预处理和安全过滤。

4）HTTP.sys是IIS的一部分，作为监听的默认选择。在IIS 7及更高版本上，可以不用HTTP.sys监听HTTP请求，可以通过WCF监听适配程序【WCF listener adapter】（比如NetTcpActivator）来完成或者做更多工作。

3.万维网发布服务

即：WWW service（World Wide Web Publishing Service）

1）WWW service在IIS 6 中的工作情况

（1）HTTP管理与配置

WWW service从IIS  metabase 读取配置信息，并用这些信息配置和更新HTTP监听程序，HTTP.SYS。此外，WWW service对处理HTTP请求的工作进程进行启动、停止、监控和管理。

（2）性能监控

WWW service监控性能，并为网站和IIS缓存提供性能计数器。

（3）进程管理

WWW service管理应用程序池和工作者进程，诸如启动、停止和回收工作者进程。另外，WWW service监控工作者进程的“健康”，以及在配置的时间内调用“快速失败监测”以阻止新工作者进程的启动。

2）在IIS 7 中的工作情况

在IIS 7 及以上版本，WWW service被分成两部分，其中一部分仍然叫WWW service，而另一部分叫做Windows Process Activation Service (WAS)。这两部分运行在同一个进程中（svchost.exe）。

（1）新WWW service作为HTTP监听程序（HTTP.SYS）的监听适配器，主要负责两个工作：一、在配置改变时，配置和更新HTTP.SYS；二、在请求加入到请求队列时，通知WAS。

（2）WAS管理应用程序池和工作者进程，而不再是WWW service。不同的是，WAS做到了能够同时管理“HTTP应用程序池和工作者进程”与“非HTTP的应用程序池和工作者进程”。WAS判断工作者进程是否正在运行，如果应用程序池中的工作者进程没在运行，则启动工作者进程。

WAS读取配置信息有：全局配置信息，协议配置信息（包括HTTP与非HTTP），网站配置信息（比如绑定和应用程序），应用程序配置信息（比如：应用程序启用的协议，所属的应用程序池）。

如果ApplicationHost.config改变，WAS接收到通知后，将新的配置信息更新监听适配器上。

3）一分为二

将原WWW service一分为二后，可以让你在“HTTP协议网站”与“非HTTP协议网站”上，运用相同的配置和处理模式。

另外，如果不需要处理HTTP请求的功能，可以只运行WAS而不运行WWW service。举个例子，只通过WCF监听适配器（比如：NetTcpActivator）管理运行一个不需要监听HTTP请求的Web Service。

【到这里，我们知道，IIS几个重要组成部分：协议监听程序，监听适配器，应用程序池和工作者进程的管理者，应用程序池和工作者进程。在HTTP请求处理上`，他们分别对应的是：HTTP.SYS； WWW Service；WAS；W3WP.exe。面对不同的协议请求，可以根据需要启用不同的协议监听程序和监听适配器。在HTTP请求处理上，工作流程可以简单地说成是这样子：配置改变时，被WAS（应用程序池和工作者进程的管理者）读到，并update到WWW Service（监听适配器），WWW Service又将新配置信息配置update到HTTP.SYS（协议监听程序），HTTP.SYS接收到请求时，将请求直接给了W3WP.exe（工作者进程）】

4.模块（Modules）

与以前版本不同，新的IIS版本中，不再在服务器上持有多数的功能（Instead of keeping the majority of functionality within the server itself），而是用一个名为“Web服务器引擎（Web server engine）”来替代。在这个Web服务器引擎上，可以根据需要，添加或者移除模块，用以实现各种功能。比如，用身份验证模块来实现鉴定客户端的证书的功能，用缓存模块管理缓存行为。（模块所在位置是工作者进程）

采用模块的方式，有以下几个优点：

（1）可以控制哪些模块在服务器上使用。

（2）可以自定义模块替代现有模块或者引用新特性。

（3）可以自定义服务器的角色（You can customize a server to a specific role in your environment.）。

（4）更加安全和便捷的管理。移除不必要的模块，可以减少服务器可能被攻击的地方，以及减少内存占用，舍去对“不必要功能”的管理。

1）本地模块（Native Modules）

在完全安装的IIS7及以上版本中，可以找到本地模块。根据需要，你可以移除它们或者用自定义模块替代它们。

（1）HTTP模块

即在请求处理管理中，针对HTTP的模块，包括重定向请求、返回HTTP错误、响应。

（2）安全模块

即在请求处理管理中，执行与安全相关的任务的模块。根据身份验证方案，选择相应的模块（各模块是独立的）。也包括URL验证模块和请求过滤模块。

（3）内容模块

即在请求处理管理中，执行与内容相关的任务的模块。包括处理静态文件请求、返回默认页面（未指定请求何资源时）、列举文件夹等模块。

（4）压缩模块

即在请求处理管理中，有两个模块实现压缩功能。

（5）缓存模块

即在请求处理管理中，执行与缓存相关的任务的模块。缓存可以改善网站和应用程序的性能。它通过在服务器的内存中保存已经处理过的信息（比如网页）来实现。如果后续的讲求是请求相同的资源，则这些信息将被重复利用。

（6）日志和诊断模块

即在请求处理管理中，执行与日志和诊断相关的任务和模块。日志模块支持加载自定义模块，和向HTTP.SYS传递信息。诊断模块在请求处理过程中，跟踪并报告事件。

（7）托管支持模块（Managed Support Modules）

即在请求处理管理中，有两个模块用于支持托管代码集成（A couple of modules in IIS support managed integration in the IIS request-processing pipeline.）。

2）托管模块（Managed Modules）

除本地模块之外，IIS允许你使用托管代码模块来扩展IIS的功能。一些托管模块（比如：UrlAuthorization）会对应一个本地模块。这个本地模块是可供替代的选择。

托管模块依赖于ManagedEngine模块。

5．应用程序池

应用程序池通过进程边界（非线程边界等）将应用程序隔离开，阻止了同一个服务器上不同的应用程序池中的应用程序之间的相互影响。在IIS 7 及更高版本中，应用程序池仍旧使用IIS 6 工作者进程相同的隔离模式。此外，在IIS 7 及更高版本中，在涉及到托管资源的请求的处理上，还可以配置请求的处理方式：集成模式或者经典模式。

在IIS 6 中工作者进程的隔离模式与在IIS 5 中的隔离模式，都是被设置在服务器级别上，所以，这让在同一服务器上同时运行这两种隔离模式成为了可能。而在IIS 7 及更高版本上，集成模式和经典模式被设置在了应用程序池的级别上，这让在同一个服务器上的不同应用程序池中的应用程序，采用不同的请求处理模式。

1）集成模式

集成处理模式，是将原IIS的请求处理模式与ASP.NET的请求处理模式集成到一个统一的处理模式中。这样做，它有几个好处：

（1）在IIS与ASP.NET之间，消除了一些重复的功能，比如身份验证；举个例子，客户端请求一个托管的文件，在集成模式下，服务器调用适当的验证模块；而在之前的IIS版本中，相同的请求，将在IIS和ASP.NET都进行身份验证。

（2）托管代码所具有的特性适用了所有的文档类型（Additionally, Integrated mode enables the availability of managed features to all content types.）。举个例子，你可以让“对ASP文件、静态文件以及在网站和应用程序中其他的文件”的请求在处理上使用托管特性ASP.NET Forms authentication 和 Uniform Resource Locator (URL) authorization。

（3）在同一个位置管理所有的模块，而不是在IIS上管理一部分功能，在ASP.NET上配置一部分功能。这简化了网站和应用程序的管理。

在集成模式下，工作者进程接收到请求后，请求将穿过一组有序的事件。每个事件将调用必要的本地模块和托管模块来处理请求的部分内容，以及产生相应的响应。

2）经典模式

在经典模式下，IIS 7 及以上版本对请求的处理模式与IIS 6 相同。ASP.NET请求（是ASP.NET请求，即可用ASP.NET进行处理的语法，而不是别的请求）首先按IIS 本地处理步骤进行处理，然后再导入到Aspnet_isapi.dll进行处理，最后，请求返回到IIS以向客户端返回响应。

分享的处理模式，导致了处理步骤的重复。

将已有的应用程序指定到集成模式，需要测试该应用程序对集成模式的兼容性。如果失败，则需将其指定到经典模式。

三、处理流程

1．流程步骤

IIS 7 及更高版本与IIS 6 有类似的请求处理流程。

（1）客户端请求一个在服务端的资源，HTTP.SYS监测到请求。

（2）HTTP.SYS联系WAS，令其获取配置信息。

（3）WAS从配置仓库（applicationHost.config）读取配置信息，并update到WWW Service。

（4）WWW Service接收到配置信息，比如应用程序池和网站配置。

（5）WWW Service将配置信息update到HTTP.SYS。

（6）WAS启动一个工作者进程，该工作者进程将处理HTTP.SYS监测到的请求。

（7）HTTP.sys根据Update到的配置信息，直接将请求丢给相应的工作者进程，工作者进程处理请求后，将响应返回到HTTP.SYS。

（8）HTTP.SYS将请求返回到客户端，客户端接收到响应。

2．工作者进程中步骤

在工作者进程中，“HTTP请求”将穿过一组有序的步骤（上文有提及），这些步骤被称为“事件”。在每个事件中，本地模块（native module）处理请求的一部分（比如验证用户和添加事件日志）。如果一个请求需要托管模块来处理，本地模块（ManagedEngine）将创建AppDomain。在该AppDomain中，托管模块才就可以继续执行请求的处理。当请求穿过所有的事件，响应将返回到HTTP.SYS。

HTTP请求在工作者进程中的执行细节：

3. 进入AppDomain以后

1)托管模块中

当Http请求进入AppDomain以后，它的管道由托管模块（Managed Modules）和处理程序（Handlers）组成，并且由管道来处理这个 Http请求:

自定义的托管模块HttpModule通过在某些事件中注册，把自己插入ASP.NET请求处理管道（因为管道合并，同时也是IIS管理）。当这些事件发生的时候，则会调用对相应的HTTP模块，这样该自定义的托管模块就能处理请求了。

<httpModules>

<add name="TestModule" type="ClassLibrary831.TestModule,ClassLibrary831"/>  </httpModules>

自定义的托管模块HTTP模块可以向System.Web.HttpApplication对象注册下面一系列事件：

AcquireRequestState 当ASP.NET运行时准备好接收当前HTTP请求的对话状态的时候引发这个事件。

AuthenticateRequest 当ASP.NET 运行时准备验证用户身份的时候引发这个事件。

AuthorizeRequest 当ASP.NET运行时准备授权用户访问资源的时候引发这个事件。

BeginRequest 当ASP.NET运行时接收到新的HTTP请求的时候引发这个事件。

Disposed 当ASP.NET完成HTTP请求的处理过程时引发这个事件。

EndRequest 把响应内容发送到客户端之前引发这个事件。

Error 在处理HTTP请求的过程中出现未处理异常的时候引发这个事件。

PostRequestHandlerExecute 在HTTP处理程序结束执行的时候引发这个事件。

PreRequestHandlerExecute 在ASP.NET开始执行HTTP请求的处理程序之前引发这个事件。在这个事件之后，ASP.NET 把该请求转发给适当的HTTP处理程序。

PreSendRequestContent 在ASP.NET把响应内容发送到客户端之前引发这个事件。这个事件允许我们在内容到达客户端之前改变响应内容。我们可以使用这个事件给页面输出添加用于所有页面的内容。例如通用菜单、头信息或脚信息。

PreSendRequestHeaders 在ASP.NET把HTTP响应头信息发送给客户端之前引发这个事件。在头信息到达客户端之前，这个事件允许我们改变它的内容。我们可以使用这个事件在头信息中添加cookie和自定义数据。

ReleaseRequestState 当ASP.NET结束所搜有的请求处理程序执行的时候引发这个事件。

ResolveRequestCache 我们引发这个事件来决定是否可以使用从输出缓冲返回的内容来结束请求。这依赖于Web应用程序的输出缓冲时怎样设置的。

UpdateRequestCache 当ASP.NET完成了当前的HTTP请求的处理，并且输出内容已经准备好添加给输出缓冲的时候，引发这个事件。这依赖于Web应用程序的输出缓冲是如何设置的。

2）Handler中

Http请求经过所有的Module之后，它会被HttpHandler处理。一个请求对应一个HttpHandler。

在http请求的处理过程中，只能调用一个HttpHandler，但可以调用多个HttpModule。所以，一旦定义了自己的HttpHandler类，那么它对系统的HttpHandler的关系将是“覆盖”关系。

Web.Config配置文件：

<httpHandlers>

<add verb="*" path="*" type="ClassLibrary831.TestHandler,ClassLibrary831"/>

</httpHandlers> 

Http请求处理流程

标签：

原文地址：http://www.cnblogs.com/jmllc/p/4966077.html