iis6.0，HTTP服务器状态代码定义，web园--最大工作进程数

-----------------------------

HTTP服务器状态代码定义

-----------------------------

HTTP服务器状态代码定义（Status Code Definitions）
1.1 消息1xx（Informational 1xx）
该类状态代码用于表示临时回应。临时回应由状态行（Status-Line）及可选标题组成， 由空行终止。HTTP/1.0中没有定义任何1xx的状态代码，所以它们不是对HTTP/1.0请求的 　　合法回应。实际上，它们主要用于实验用途，这已经超出本文档的范围。
1.2 成功2xx（Successful 2xx）
表示客户端请求被成功接收、理解、接受。
200 OK
请求成功。回应的信息依赖于请求所使用的方法，如下：
GET 要请求的资源已经放在回应的实体中了。
HEAD 没有实体主体，回应中只包括标题信息。
POST 实体（描述或包含操作的结果）。
201 Created
请求完成，结果是创建了新资源。新创建资源的URI可在回应的实体中得到。原始服务器应在发出该状态代码前创建该资源。如果该操作不能立即完成，服务器必须在该资源可用时在回应主体中给出提示，否则，服务器端应回应202（可被接受）。
在本文定义的方法，只有POST可以创建资源。
202 Accepted
请求被接受，但处理尚未完成。请求可能不一定会最终完成，有可能被处理过程随时中断，在这种情况下，没有办法在异步操作中重新发送状态代码。
202回应是没有义务的，这样做的目的是允许服务器不必等到用户代理和服务器间的连接结束，就可以响应其它过程的请求（象每天运行一次的，基于批处理的过程）。
在某些回应中返回的实体中包括当前请求的状态指示、状态监视器指针或用户对请求能否实现的评估信息。
204 No Content
服务器端已经实现了请求，但是没有返回新的信息。如果客户是用户代理，则勿需为此更新自身的文档视图。该回应主要是为了在不影响用户代理激活文档视图的前提下，进行script语句的输入及其它操作。该回应还可能包括新的、以实体标题形式表示的元信息，它可被当前用户代理激活视图中的文档所使用。
1.3 重定向（Redirection 3xx）
该类状态码表示用户代理要想完成请求，还需要发出进一步的操作。这些操作只有当后跟的请求是GET或HEAD时，才可由用户代理来实现，而不用与用户进行交互。用户代理永远也不要对请求进行5次以上的重定向操作，这样可能导致无限循环。
300 Multiple Choices
该状态码不被HTTP/1.0的应用程序直接使用，只是做为3xx类型回应的缺省解释。存在多个可用的被请求资源。
除非是HEAD请求，否则回应的实体中必须包括这些资源的字符列表及位置信息，由用户或用户代理来决定哪个是最适合的。
如果服务器有首选，它应将对应的URL信息存放在位置域（Location field）处，用户代理会根据此域的值来实现自动的重定向。
301 Moved Permanently
请求到的资源都会分配一个永久的URL，这样就可以在将来通过该URL来访问此资源。有编辑链接功能的客户端会尽可能地根据服务器端传回的新链接而自动更新请求URI。 新的URL必须由回应中的位置域指定。除非是HEAD请求，否则回应的实体主体 　　（Entity-Body）必须包括对新URL超链接的简要描述。
如果用POST方法发出请求，而接收到301回应状态码。在这种情况下，除非用户确认，否则用户代理不必自动重定向请求，因为这将导致改变已发出请求的环境。
注意：当在接收到301状态码后而自动重定向POST请求时，一些现存的用户代理会错误地将其改为GET请求。
302 Moved Temporarily
请求到的资源在一个不同的URL处临时保存。因为重定向有时会被更改，客户端应继续用请求URI来发出以后的请求。新的URL必须由回应中的位置域指定。除非是HEAD请求，否则回应的实体主体 （Entity-Body）必须包括对新URL超链接的简要描述。
如果用POST方法发出请求，而接收到302回应状态码。在这种情况下，除非用户确认，否则用户代理不必自动重定向请求，因为这将导致改变已发出请求的环境。
注意：当在接收到302状态码后而自动重定向POST请求时，一些现存的用户代理会错误地将其改为GET请求。
304 Not Modified
如果客户端成功执行了条件GET请求，而对应文件自If-Modified-Since域所指定的日期以来就没有更新过，服务器应当回应此状态码，而不是将实体主体发送给客户端。回应标题域中只应包括一些相关信息，比如缓存管理器、与实体最近更新（entity’s Last-Modified）日期无关的修改。相关标题域的例子有：日期、服务器、过期时间。每当304回应中给出的域值发生变化，缓存都应当对缓存的实体进行更新。
1.4 客户端错误（Client Error ）4xx
4xx类的状态码表示客户端发生错误。如果客户端在收到4xx代码时请求还没有完成，它应当立即终止向服务器发送数据。除了回应HEAD请求外，不论错误是临时的还是永久的，服务器端都必须在回应的实体中包含错误状态的解释。这些状态码适用于任何请求方法。
注意：如果客户端正在发送数据，服务器端的TCP实现应当小心，以确保客户端在关闭输入连接之前收到回应包。如果客户端在关闭后仍旧向服务器发送数据，服务器会给客户　　端发送一个复位包，清空客户端尚未处理的输入缓冲区，以终止HTTP应用程序的读取、解释活动。
400 非法请求（Bad Request）
如果请求的语法不对，服务器将无法理解。客户端在对该请求做出更改之前，不应再次向服务器重复发送该请求。
401 未授权（Unauthorized）
请求需要用户授权。回应中的WWW-Authenticate标题域（10.16节）应提示用户以授权方式请求资源。客户端应使用合适的授权标题域（10.2节）来重复该请求。如果请求中已经包括了授权信任信息，那回应的401表示此授权被拒绝。如果用户代理在多次尝试之后，回应一样还是返回401 状态代码，用户应当察看一下回应的实体，因为在实体中会包括一些相关的动态信息。HTTP访问授权会在11节中解释。
403 禁止（Forbidden）
服务器理解请求，但是拒绝实现该请求。授权对此没有帮助，客户端应当停止重复发送此请求。如果不是用HEAD请求方法，而且服务器端愿意公布请求未被实现原因的前提下，服务器会将拒绝原因写在回应实体中。该状态码一般用于服务器端不想公布请求被拒绝的细节或没有其它的回应可用。
404 没有找到（Not Found）
服务器没有找到与请求URI相符的资源。404状态码并不指明状况是临时性的还是永久性的。如果服务器不希望为客户端提供这方面的信息，还回应403（禁止）状态码。
1.5 服务器错误（Server Error ）5xx
回应代码以‘5’开头的状态码表示服务器端发现自己出现错误，不能继续执行请求。如果客户端在收到5xx状态码时，请求尚未完成，它应当立即停止向服务器发送数据。除了回应HEAD请求外，服务器应当在其回应实体中包括对错误情况的解释、并指明是临时性的还永久性的。
这类回应代码没有标题域，可适用于任何请求方法。
500 服务器内部错误（Internal Server Error）
服务器碰到了意外情况，使其无法继续回应请求。
501 未实现（Not Implemented）
服务器无法提供对请求中所要求功能的支持。如果服务器无法识别请求方法就会回应此状态代码，这意味着不能回应请求所要求的任何资源。
502 非法网关（Bad Gateway）
充当网关或代理的服务器从要发送请求的上游（upstream）服务器收到非法的回应。
503 服务不可用（Service Unavailable）
服务器当前无法处理请求。这一般是由于服务器临时性超载或维护引起的。该状态码暗示情况是暂时性的，要产生一些延迟。
注意：503状态码并没有暗示服务器在超载时一定要返回此状态码。一些服务器可能希望在超载时采用简单处理，即断掉连接。

-----------------------------

于iis6.0的web园--最大工作进程数

-----------------------------

IIS 6.0允许将应用程序池配置成一个Web园（Web Garden）。要理解Web园的概念，可以设想这样一种情形：假设有一个IIS 5.0服务器和三个Web网站，每一个Web网站运行着相同的应用程序，如果IIS 5.0能够自动按照圆形循环的模式将请求依次发送给这些功能上等价、实际上分离的Web网站，将负载分离到三个不同的进程，就可以构成一个小型的Web农场（Web Farm）——这就是Web园。

在IIS 6.0的Web园中，我们不必创建额外的Web网站，只要指定用于某个应用程序池的工作进程的数量就可以了。具体的配置步骤是：打开应用程序池的“属性”对话框，转到“性能”页，在“Web园”下面的“最大工作进程数”输入框中输入进程数量，如图八。当服务器的负载较小，不需要额外的工作进程时，IIS 6.0在一定的时间后（默认20分钟，可配置）自动缩减实际的工作进程数量；如果负载变大，需要额外的工作进程，IIS 6.0再次增加工作进程数量。这一切操作都自动进行，不需要管理员干预。



Web园：在Web园中你可以配置此应用程序池所使用的最大工作进程数，默认为1，最大可以设置为4000000； 配置使用多个工作进程可以提高该应用程序池处理请求的性能，但是在设置为使用多个工作进程之前，请考虑以下两点：

每一个工作进程都会消耗系统资源和CPU占用率；太多的工作进程会导致系统资源和CPU利用率的急剧消耗；

每一个工作进程都具有自己的状态数据，如果Web应用程序依赖于工作进程保存状态数据，那么可能不支持使用多个工作进程。


问： IIS 6.0 具有一个名为 Web 园的新功能，有了它，可以将应用程序池配置为使用多个工作进程。IIS 何时创建额外的工作进程？在我们实施 Web 园之前，我们应该了解哪些知识？

答：在您创建应用程序池时，就会通知 IIS 6 创建一个工作进程，以传送指派给该应用程序池的 Web 站点、文件和文件夹的内容。您可以将应用程序池配置为启动多个，而非一个工作进程，这样可以提高可扩展性。这个功能的名为 Web 园，是小型的“Web 农场”。您无需使用多台计算机来传送相同的内容（Web 农场），而是可以使用一台计算机中的多个进程来传送相同的内容。

在将 IIS 6 应用程序配置为 Web 园时，您只需在“应用程序池属性”的“性能”选项卡的“最大工作进程数”框中，设置一个大于 1 的工作进程数。如果这个值大于 1，每个请求都将启动一个新的工作进程实例，可启动的最多进程数为您所指定的最大工作进程数。后续的请求将以循环的方式发送至工作进程。

Web 园在您的应用程序资源有限的情况下非常有用。例如，如果您到数据库的连接很慢，那么您可以使用多个工作进程来增加用户吞吐量，从而增加到数据库的连接数。

尽管在有些情况下使用 Web 园的用处非常大，但是要注意，每个工作进程的会话信息都是唯一的。由于请求以循环的方式路由到应用程序池工作进程，因此 Web 园对于会话信息存储在进程中的应用程序作用可能不大。在少数情况下，让多个工作进程运行同一个应用程序会造成资源竞争。例如，如果所有工作进程都试图将信息记录到日志文件中，或是使用那些不是专用于多个并发访问的资源，那么可能出现资源竞争问题。

如果不存在这些问题，那么 Web 园可能正是您所需的功能之一，而且其作用会非常大。