HTTP个人总结（四）

今天主要总结的是Web服务器与代理。

先从Web服务器开始。

Web服务器是如何实现的？

Web服务器实现了HTTP和相关的TCP连接处理。负责管理Web服务器提供的资源，以及对Web服务器的配置、控制及扩展方面的管理。
Web服务器逻辑实现了HTTP协议，管理者Web资源，并负责提供Web服务器的管理功能。Web服务器逻辑和操作系统共同负责管理TCP连接。底层操作系统负责管理底层计算机的硬件细节，并提供TCP/IP网络支持，负载装载Web资源的文件系统以及控制当前计算活动的进程管理功能。

那么实际中Web服务器会做些什么呢？

1.建立连接——接受一个客户端的连接，或者如果不希望与这个客户端建立连接，就将其关闭。
2.接收请求——从网络中读取一条HTTP请求报文
3.处理请求——对请求报文进行解释，并采取行动
4.访问资源——访问报文中指定的资源
5.构建响应——创建带有正确首部的HTTP响应报文
6.发送响应——将响应回送给客户端
7.记录事务处理过程——将与已完成事务有关的内容记录在一个日志文件中。

下面进行各个步骤的详细讲解：
第一步：接收客户端连接。如果客户端已经打开了一条到服务器的持久连接，可以使用那条连接来发送它的请求。否则，客户端需要打开一条新的到服务器的连接。
如何处理新连接？
客户端请求一条到Web服务器的TCP连接时，Web服务器会建立连接，判断连接的另一端是哪个客户端，从TCP连接中将IP解析出来。一旦新连接建立起来并被接受，服务器就会将新连接添加到其现存Web服务器连接列表中，做好监视连接上数据传输的准备。
Web服务器可以随意拒绝或立即关闭任意一条连接。有些Web服务器会因为客户端IP地址或主机名是未认证的，或者因为它是已知的恶意客户端而关闭连接。
客户端主机名识别可以通过：1.反向DNS解析 2.通过ident协议确定客户端用户

第二步：接收请求报文。连接上有数据到达时，Web服务器会从网络连接中读取数据，并将请求报文中的内容解析出来。

解析请求报文时，Web服务器会：
1.解析请求行，查找请求方法，指定的资源标识符（URI）以及版本号，各项之间由一个空格分隔，并以一个回车换行（CRLF）序列作为行的结束。
2.读取以CRLF结尾的报文首部
3.检测到以CRLF结尾的、标识首部结束的空行（如果有的话）
4.如果有的话（长度由Content-Length首部指定），读取请求主体

解析请求报文时，Web服务器会不定期地从网络上接收输入数据。网络连接可能随时都会出现延迟，Web服务器需要从网络中读取数据，将部分报文数据临时存储在内存中，知道收到足以进行解析的数据并理解其意义。

高性能的Web服务器能够同时支持数千条连接。每个客户端都向服务器打开了一条或多条连接。下面列举不同的Web服务器结构：
1.单线程Web服务器：一次只处理一个请求，直到其完成为止。一个事务处理结束之后，才去处理下一条连接，这种结构易于实现，但在处理过程中，所有其他的连接都会被忽略，这样会造成严重的性能问题，只适用于低负荷的服务器。
2.多进程及多线程Web服务器：用多个进程，或更高效的线程同时对请求进行处理，但当服务器同时要处理成百上千，甚至数以万计的连接时，需要的进程或线程数量可能会消耗太多的内存或系统资源。因此很多多线程Web服务器都会对线程/进程最大数量进行限制。
3.复用I/O的服务器：为了支持大量的连接，很多Web服务器都采用了复用结构。在复用结构中，要同时监视所有连接上的活动。当连接的状态发生变化时（比如有数据可用，或出现错误时），就对那条连接进行少量的处理，处理结束之后，将连接返回到开放连接列表中，等待下一次状态变化。只有在有事情可做时才会对连接进行处理，在空闲连接上等待的时候并不会绑定线程和进程。
4.复用的多线程Web服务器：将多线程和复用功能结合在一起，以利用计算机平台上的多个CPU

第三步：处理请求。一旦服务器收到了请求，就可以根据方法、资源、首部和可选的主体部分来对请求进行处理。

第四步：对资源的映射及访问。在Web服务器将内容传送给客户端之前，要将请求报文中的URI映射为Web服务器上适当的内容或内容生成器，以识别出内容的源头。
Web服务器支持各种不同类型的资源映射，但最简单的资源映射形式就是用请求URI作为名字来访问Web服务器文件系统中的文件。Web服务器的文件系统中会有一个特殊的文件夹专门用于存放Web内容，这个文件夹被称为文档的根目录（docroot）。
当有一个/specials/saw-blade.gif的请求到达。服务器的根目录为/usr/local/httpd/files。Web服务器会返回文件/usr/local/httpd/files/specials/saw-blade.gif

服务器要注意，不能让相对URL退到docroot之外，将文件系统的其余部分暴露出来。比如查询../。
下面讲述虚拟托管的docroot。
虚拟托管的Web服务器会在同一台Web服务器上提供多个Web站点，每个站点在服务器上都有自己独有的文档根目录。虚拟托管Web服务器会根据URI或HOST首部的IP地址或主机名来识别要使用的正确文档根目录。

对常见的Apache Web服务器来说，需要为每个虚拟Web站点配置一个VirtualHost块，而且每个虚拟服务器都要包含DocumentRoot

docroot的另一种常见应用是在Web服务器上为人们提供私有的Web站点。通常会把那些以斜杠和波浪号（/~）开始，后面跟着用户名的URI映射为此用户的私有文档根目录。私有docroot通常都是用户主目录下那个名为public_html的目录，但也可以重新配置

Web服务器中的目录列表：
Web服务器可以接受对目录URL的请求，其路径可以解析为一个目录，而不是文件。我们可以对大多数Web服务器进行配置，使其在客户端请求目录URL时采取不同的动作
1.返回一个错误
2.不返回目录，返回一个特殊的默认“索引文件”
3.扫描目录，返回一个包含目录内容的HTML页面
在Apache Web服务器上，可以用配置指令DirectoryIndex会按照优先顺序列出所有可以作为目录索引文件使用的文件名，如：
DirectoryIndex index.html index.htm home.html home.htm index.cgi
如果用户请求目录URI时，没有提供默认的索引文件，而且没有禁止使用目录索引，很多Web服务器都会自动返回一个HTML文件，此文件中会列出那个目录里的文件名，以及每个文件的大小和修改日期，还包括到每个文件的URI链接。可以通过以下Apache指令禁止自动生成目录索引：
Options-Indexes
动态内容资源的映射：

Web服务器还可以将URI映射为动态资源，Web服务器要能够分辨出资源什么时候是动态，动态内容生成程序位于何处，以及如何运行那个程序。
Apache允许用户将URI路径名组件映射为可执行文件目录。服务器收到一条带有可执行路径组件的对URI的请求时，会试着执行相应服务器目录中的程序。例如，Apache配置指令就表明所有路径以/cgi-bin/开头的URI都应该执行在目录/usr/local/etc/httpd/cgi-programs/中找到相应文件：
ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-programs

Web服务器还可以为特定资源进行访问控制，有请求到达，要访问受控资源时，Web服务器可以根据客户端的IP地址进行访问控制，也可以要求输入密码来访问资源。

第五步：构建响应。一旦Web服务器识别出了资源，就执行请求方法中描述的动作，并返回响应报文。响应报文中包含有响应状态码、响应首部，如果生成了响应主体的话，还包括响应主体。
其中响应实体通常包括：
1.描述了响应主体MIME类型的Content-Type首部
2.描述了响应主体长度的Content-Length首部
3.实际报文的主体内容

Web服务器要负责确定响应主体的MIME类型，Web服务器可以用文件的扩展名来说明MIME类型。

有魔法分类:Apache Web服务器可以扫描每个资源的内容，并将其与一个已知模式表（被称为魔法文件）进行匹配，以决定每个文件的MIME类型，这样做可能比较慢，但很方便，尤其是文件没有标准扩展名的时候
显示分类：可以对Web服务器进行配置，使其不考虑问价你的扩展名或内容，强制特定文件或目录内容拥有某个MIME类型。
类型协商：有些Web服务器经过配置，可以以多种文档格式来存储资源。可以配置Web服务器，使其可以通过与用户的协商来决定使用哪种格式。

Web服务器也可能返回重定向响应。重定向用于下列情况：
1.永久删除的资源
2.临时删除的资源
3.URL增强
4.负载均衡
5.服务器关联
6.规范目录名称

第六步：发送响应。Web服务器通过发送数据时也会面临与接收数据一样的问题。服务器可能有很多条到各个客户端的连接。服务器要记录连接的状态，还要特别注意对持久连接的处理，连接可能仍保持打开状态，要正确地计算Content-Length首部，不然客户端就无法知道响应什么时候结束了

第七部：记录日志。当事务结束时，Web服务器会在日志文件中添加一个条目，来描述已执行的事务。

下面来介绍代理！

代理与网关的对比？

严格来说，代理连接的是两个或多个使用相同协议的应用程序，而网关连接的则是两个或多个使用不同协议的端点。

但实际上，代理和网关之间的区别很模糊。由于浏览器和服务器实现的是不同版本的HTTP，代理也经常要做一些协议转换工作。而商业化的代理服务器也会实现网关的功能来支持SSL安全协议，SOCKS防火墙，FTP访问，以及基于Web的应用程序。

那么为什么使用代理？

代理服务器可以改善安全性，提高性能，节省费用。代理服务器可以看到并接触到所有流过的HTTP流量，所以代理可以监视流量并对其进行修改，以实现很多增值Web服务。如：
1.儿童过滤器：可以利用过滤器来阻止学生访问成人内容

2.文档访问控制：可以用代理服务器在大量Web服务器和Web资源之间实现统一的访问控制策略，创建审核跟踪机制。如：

集中式访问控制代理：

（1）.允许客户端1无限制地访问服务器A的新闻页面
（2）.客户端2可以无限制地访问因特网
（3）.在允许客户端3访问服务器B之前，要求其输入口令

3.安全防火墙：网络安全工程师通常会使用代理服务器来提高安全性。代理服务器会在网络中的单一安全节点上限制哪些应用层协议的数据可以流入或流出一个组织。还可以提供用来消除病毒的挂钩程序。

4.Web缓存：代理缓存维护了常用文档的本地副本，并将它们按需提供，以减少缓慢且昂贵的因特网通信。

5.反向代理：代理可以假扮Web服务器，接收发给Web服务器的真实请求，发起与其他服务器的通信，以便按需定位所请求的内容。

6.内容路由器：可以根据因特网流量状况以及内容类型将请求导向特定的Web服务器

7.转码器：代理服务器在将内容发送给客户端之前，可以修改内容的主体格式，转码代理可以再传输GIF图片时，将其转换成JPEG图片，以减少尺寸等等。

8.匿名者：匿名者代理会主动从HTTP报文中删除身份特性（比如客户端IP地址、From首部、Referer首部、cookie、URI的会话ID），从而提高高度的私密性和匿名性。

代理会去往何处?

部署代理服务器的几种方式：
1.出口代理：可以将代理固定在本地网络的出口点，以便控制本地网络与大型因特网之间的流向。可以在公司网络中使用出口代理，提供针对公司外部恶意黑客的防火墙保护，或降低带宽费用，提高因特网流量的性能。
2.访问（入口）代理：代理长飞放在ISP（互联网服务提供商）访问点上，用以处理来自客户的聚合请求。ISP使用缓存代理来存储常用文档的副本，以提高用户（尤其是高速连接用户）的下载速度，降低因特网带宽耗费
3.反向代理：通常会被部署在网络边缘，在Web服务器之前。在那里它们可以处理所有传送给Web服务器的请求，并只在必要时向Web服务器请求资源。替代物可以提高Web服务器的安全特性，或者将快速的Web服务器缓存放在较慢的服务器之前，以提高性能。方向代理通常会直接毛用Web服务器的名字和IP地址，这样所有的请求就会被发送给代理而不是服务器了。
4.网络交换代理：可以将具有足够处理能力的代理放在网络之间的因特网对等交换点上，通过缓存来减轻因特网节点的拥塞，并对流量进行监视。

代理的层次结构？

可以通过代理层次结构将代理级联起来。如：

会将报文从一个代理传给另一个代理，直到最终抵达原始服务器为止。
Proxy层次结构中代理服务器被赋予了父和子的关系。靠近服务器被称为父代理，靠近客户端被称为子代理。
代理层次结构不一定非得是静态的。如：

如果所请求的对象属于一个付费使用内容分发服务的Web服务器，代理就会将请求发送给附近的一个缓存服务器，这个服务器会返回已返回已缓存对象，或者如果它那没有的话，它会去取回内容。
如果请求的是特定类型的图片，访问代理会将请求转发给一个特定的压缩代理，这个代理会去获取图片，然后对其进行压缩，这样通过客户端的慢速Modem下载时，速度会更快一些。
还有几个动态选择父代理的列子：
1.负载均衡：子代理可能会根据当前父代理上的工作负载级别来决定如何选择一个父代理，以均衡负载
2.地理位置附近的路由：子代理可能会选择负责原始服务器所在物理区域的父代理
3.协议/类型路由：子代理可能会根据URI将报文转发到不同的父代理和原始服务器上去。某些特定类型的URI可能要通过一些特殊的代理服务器转发请求，以便进行特殊的协议处理。
4.基于订购的路由：如果发布者为高性能服务额外付费了，它们的URI就会被转发到大型缓存或压缩引擎上去，以提高性能。

代理是如何获取流量的？

有四种常见方式可以使客户端流量流向代理：
1.修改客户端：很多Web客户端都支持手工和自动的代理配置。如果将客户端配置为使用代理服务器，客户端就会将HTTP请求有意地直接发送给代理，而不是原始服务器。
2.修改网络：网络基础设施可以通过若干种计数手段，在客户端不知道，或没有参与的情况下，拦截网络流量并将其导入代理。这种拦截通常都依赖于监视HTTP流量的交换设备及路由设备，在客户端毫不知情的情况下，对其进行拦截，并将流量导入一个代理。这种代理被称为拦截代理。
3.修改DNS的命名空间：放在Web服务器之前的代理服务器——替代物，会直接假扮Web服务器的名字和IP地址，这样，所有的请求就会发送给这些替代物，而不是服务器了。要实现这一点，可以手工编辑DNS名称列表，或者用特殊的动态DNS服务器根据需要来确定适当的代理或服务器。有时在安装过程中，真实服务器的IP地址和名称被修改了，替代物得到的会是之前的地址和名称。
4.修改Web服务器：也可以将某些服务器配置为向客户端发送一条HTTP重定向命令，将客户端请求重定向到一个代理上去。收到重定向命令后，客户端会与代理进行通信。

客户端的代理设置？

很多浏览器都提供了多种配置代理的方式，包括：
1.手工配置：显式地设置要使用的代理
2.预先配置浏览器：浏览器厂商或发行商会在浏览器发送给其客户之前预先对浏览器的代理设置进行手工设置
3.代理的自动配置：提供一个URI，指向一个用JavaScript语言编写的代理自动配置文件；客户端会取回这个JavaScript文件，并运行它以决定是否应该使用一个代理，如果是的话，应该使用哪个代理
4.WPAD的代理发现：有些浏览器支持Web代理自动发现协议（WPAD），这个协议会自动检测出浏览器可以从哪个“配置服务器”下载到一个自动配置文件

与代理请求有关的一些棘手问题？

代理URI和服务器URI的不同？
客户端向Web服务器发送请求时，请求行中只包含部分URI（没有方案、主机或端口）如：
GET /index.html HTTP/1.0
但当客户端向代理发送请求时，请求行中则包含完整的URI。如：
GET http://www.marys-antiques.com/index.html HTTP/1.0

为什么会有两种不同的请求格式，一种用于代理，另一种用于服务器？在原始的HTTP设计中，客户端会直接与单个服务器进行对话。不存在虚拟机，也没有为代理制定什么规则。单个的服务器都知道自己的主机名和端口。所以为了避免发送冗余信息，客户端只需发送部分URI即可，无需发送方案和主机以及端口。
代理出现之后，使用部分URI就有问题了。代理需要知道目标服务器的名称，这样它们才能建立自己与服务器的连接。基于代理的网关要知道URI的方案才能连接到FTP资源和其他方案上去。HTTP/1.0要求代理请求发送完整的URI，解决了这个问题，但它为服务器请求保留部分URI的形式（已经有相当多的服务器都改为支持完整URI）
因此，我们要将部分URI发送给服务器，将完整的URI发送给代理。

与虚拟主机一样的问题？
虚拟主机Web服务器会在很多Web站点间共享同一个物理Web服务器。包含部分URI的请求到达时，虚拟主机Web服务器需要知道目的Web站点的主机名。与上一个问题相似，但是解决方法不同：
1.显式的代理要求在请求报文中使用完整的URI来解决这个问题
2.虚拟主机Web服务器要求使用Host首部来承载主机和端口信息。

拦截代理会收到部分URI？
客户端并不总是知道它是在和代理对话，因为有些代理对客户端是不可见的。客户端的流量可能会经过替代物或拦截代理，在这两种情况下，客户端都会认为它在与Web服务器进行对话，不会发送完整的URI。如：
如前所述，反向代理是一个用来取代原始服务器的代理服务器，它通常会通过假扮服务器的主机名和IP地址来做到这一点。它会收到Web服务器请求，可能会向真正的服务器提供缓存的响应或者代理请求。客户端无法区别反向代理和Web服务器，因此它会发送部分URI
拦截代理是网络流量中的代理服务器，它会拦截从客户端发往服务器的请求，并提供一个缓存响应，或对其进行转发。由于拦截代理拦截了从客户端到服务器的流量，所以它会收到发送给Web服务器的部分URI

代理既可以处理代理请求，也可以处理服务器请求？
由于将流量重定向到代理服务器的方式有所不同，通用的代理服务器既应该支持请求报文中的完整URI，也应该支持部分URI。规则如下：
1.如果提供的是完整的URI，代理就应该使用这个完整的URI
2.如果提供的是部分URI，而且有Host首部，就应该用Host首部来确定原始服务器的名字和端口号。
3.如果提供的是部分URI，而且没有Host首部，有三种方法：
（1）如果代理是代表原始服务器的替代物，可以用真实服务器的地址和端口号来配置代理
（2）如果流量被拦截了，而且拦截者也可以提供原始的IP地址和端口，代理就可以用拦截技术提供的IP地址和端口号。
（3）如果所有方法都失败了，代理没有足够的信息来确定原始服务器，就必须返回一条错误报文

转发过程中对URI的修改？
代理服务器要在转发报文时修改请求URI的话，需要特别小心，对URI的微小修改，甚至是看起来无害的修改，都可能给下游服务器带来一些互操作性的问题。

URI的客户端自动扩展和主机名解析？
根据是否有代理，浏览器对请求URI的解析会有所不同。没有代理时，浏览器如果没有找到主机，很多浏览器都会尝试提供某种主机名自动“扩展”机制。

代理时URI的解析？
使用显式代理时，用户的URI会直接发送给代理，所以浏览器就不再执行所有便捷的扩展功能了。

有拦截代理时URI的解析？
使用不可见的拦截代理时，对主机名的解析会略有不同，因为对客户端来说，是没有代理的，这是浏览器会自动扩展主机名，直到DNS成功为止。

在第（1）步中，用户浏览器的URI地址窗口输入oreilly。
在第（2a）步中，浏览器通过DNS查找主机oreilly，但DNS服务器失败了，并回送响应说明主机为止，如第（2b）步所示
在第（3a）步中，浏览器进行自动扩展，将oreilly转换成www.oreilly.com。在第（3b）步中，DNS解析成功,将IP地址返回给了浏览器
在第（4a）步中，客户端已经成功解析了主机名，并有了一张IP地址列表。有些IP地址可能已经停用了。所以通常客户端会尝试着连接每个IP地址，直到成功为止。但对拦截代理来说，第一次连接请求就会被代理服务器拦截成功，不会连接到原始服务器上去，客户端认为它与Web服务器进行成功的对话，但那个Web服务器可能甚至都不处于活跃状态
在第（5b）步，代理与真正原始服务器进行交互时。可能会发现那个IP地址实际指向的是一个已停用的服务器，为了提供与浏览器相同级别的容错机制，代理可以通过解析Host首部的主机名，也可以通过对IP地址的方向DNS查找来尝试其他IP地址。对拦截和显式代理实现来说，在DNS解析到已经停用的服务器时，提供容错机制很重要。

追踪报文？

很多公司都会用缓存代理服务器来访问因特网。

随着代理的逐渐流行，我们要能够追踪经过代理的报文流，以检测出各种问题，其重要性就跟追踪经过不同交换机和路由器传输的IP分组流一样。

Via首部？
Via首部字段列出了与报文途径的每个中间节点（代理或网关）有关的信息。报文每经过一个节点，都必须将这个中间节点添加到Via列表的末尾。如：

说明第一个代理名proxy-62.irenes-isp.net实现了HTTP/1.1协议，另一个是实现了HTTP/1.0
代理也可以用Via首部来检测网络中的路由循环。代理应该在发送一条请求之前，在Via首部插入一个与其自身有关的独特字符串，并在输入的请求中查找这个字符串，已检测网络中是否存在路由循环。
每个Via路标中最多包含4个组件：一个可选的协议名（默认为HTTP）、一个必选的协议版本，一个必选的节点名和一个可选的描述性注释

Via与网关？
有些代理会为使用非HTTP协议的服务器提供网关的功能。Via首部记录了这些协议的转换。这样HTTP应用程序就会了解代理链上各点的协议处理能力以及所做的协议转换了。

Via的隐私和安全问题？
有时候我们并不希望在Via字符串中使用确切的主机名。除非显式地允许这种行为，否则当代理服务器作为网络防火墙的一部分使用时，是不应该转发防火墙后面那些主机名的名字和端口号的。
如果不允许进行Via节点名转发，作为安全防线的一部分使用的代理就应该用适当的假名来取代那台主机的名字。一般来说，即使隐藏了真实名称，代理也应该尝试着为每台代理服务器保留一个Via路标条目。

Trace方法？

通过HTTP/1.1的Trace方法，用户可以跟踪经代理链传输的请求报文，观察报文。Trace对代理流的调试非常有用。

其中有一个max-forwards首部来限制trace和options请求所经过的代理跳数。Max-Forwards请求首部字段包含了一个整数，如果值为0，那么即使接受者不是原始服务器，它也必须将Trace报文回送给客户端，而不应该继续转发，如果收到的值大于0，转发的报文中就必须包含一个更新了的Max-Forwards字段，其值会被减一。

代理认证？

代理可以作为访问控制设备使用。HTTP定义了一种名为代理认证的机制，这种机制可以组织对内容的请求，直到用户向代理提供了有效的访问权限证书为止。

步骤如下:
1.对受限内容的请求到达一台代理服务器时，代理服务器可以返回一个要求使用访问证书的407Proxy Authorization Required状态码
2.客户端收到407响应时，会尝试着从本地数据库或通过提示用户来搜集所需要的证书
3.只要获得了证书，客户端就会重新发送请求，在Proxy-Authorization首部字段中提供所要求的证书。
4.如果证书有效，代理就会将原始请求沿着传输链路向下传送，否则就发送另一条407应答。
若传输链路中有多个代理，且每个代理都要进行认证时，代理认证通常无法很好的工作。人们建议，应该对HTTP进行升级，将认证证书与代理链中特定的路标联系起来，但这些升级措施并没有得到广泛实现。