Oh!Coder

Coding Life

读《HTTP权威指南》笔记(五)

| Comments

第五部分是本书的最后一部分,主题是——内容发布与分发。

本部分分为四个章节,第十八章介绍了在现代的Web托管环境中部署服务器的若干方法,HTTP对虚拟Web托管的支持以及如何在地理上相距遥远的服务器之间复制内容。第十九章讨论了创建Web内容并将其放置到Web服务器上去的各种技术。第二十章探讨了各种将来访的Web流量分发到一组服务器上的技术和工具。第二十一章解释了日志的各种格式和各种常见问题。

下面还是对每一章分别做一些笔记。

第十八章:Web主机托管

本章主要讲述了关于Web主机托管的相关概念。那么首先介绍一下什么是Web主机托管。(Page.430)对内容资源的存储、协调以及管理的职责统称为Web主机托管。

对于主机托管,主要分为两大类。

  • 专用托管
  • 虚拟主机托管

对于专用托管,这里就不多说了。顾名思义,就是专门找一台机器作为服务器,你可以独自享用机器的相关资源。

下面主要说一说虚拟主机托管。首先介绍一下什么是虚拟主机。(Page.431)许多Web托管者通过让一些顾客共享一台计算机来提供便宜的Web主机托管服务。这称为共享主机托管或虚拟主机托管。对于同样多台的服务器,有一个称为服务器集群的概念,(Page.432)托管者呃可以创建成排同样的服务器,称为服务器集群(server farm),把负载分摊在群里的服务器上。

由于HTTP/1.0中的一个设计缺陷,不能为共享的Web服务器提供任何方法来识别要访问的是哪一个托管的网站。虽然HTTP/1.1要求服务器能够处理HTTP报文请求行上的完整URL,但将现存的应用程序都升级到这个规范还需要很长时间。在此期间,涌现了4种技术(Page.433~Page.434)。

  • 通过URL路径进行虚拟主机托管。
    在URL中增添专门的路径部分,以便服务器判断是哪个网站。

  • 通过端口号进行主机托管。
    为每个站点分配不同的端口号,这样请求就由Web服务器的单独实例来处理。

  • 通过IP地址进行主机托管。
    为不同的虚拟站点分配专门的IP地址,把这些地址都绑定到一台单独的机器上。这样,Web服务器就可以通过IP地址来识别网站名了。

  • 通过Host首部进行主机托管。
    很多Web托管者向HTTP的设计者施压,要求解决这个问题。HTTP/1.0的增强版和HTTP/1.1的正式版定义了Host请求首部来携带网站名称。Web服务器可以通过Host首部识别虚拟站点。

书中在对HTTP/1.1的Host首部的讲解,分别在四个方面做了讲解(Page.437~Page.438)。

  • 语法与用法
  • 缺失Host首部
  • 解释Host首部
  • Host首部与代理

使网站更可靠的办法,书中给出了几种方法。

  • 镜像的服务器集群(Page.438~Page.439)。
    服务器集群是一排配置相同的Web服务器,互相可以替换。每个服务器上的内容可以通过镜像复制,这样当某个服务器出问题的时候,其他的可以顶上。这里书中提到两个基本概念,主原始服务器和复制原始服务器(replica origin server)。(Page.439)某个服务器可能充当“内容权威”——它含有原始内容,这个服务器称为主原始服务器(master origin server)。从主原始服务器接收内容的镜像服务器称为复制原始服务器。这部分还书中谈到了两种方法可以把客户端的请求导向特定的服务器。一种是HTTP重定向。另一种是DNS重定向。

  • 内容分发网络(Page.440)
    简单地说,内容分发网络(CDN)就是对特定内容进行分发的专门网络。这个网络中的结点可以是Web服务器、反向代理或缓存。

  • CDN中的反向代理缓存(Page.440)
    反向代理缓存可以像镜像服务器一样接受服务器请求。它们代表原始服务器中的一个特定集合来接收服务器请求。反向代理和镜像服务器之间的区别在于反向代理通常是需求驱动的。它们不会保存原始服务器的全部内容副本,它们只保存客户端请求的那部分内容。

  • CDN中的代理缓存(Page.440)
    与反向代理不同,传统的代理缓存能收到发往任何Web服务器的请求。但是与反向代理比起来,代理缓存的内容一般都是按需驱动的,不能指望它是对原始服务器内容的精确复制。

第十九章:发布系统

这一章主要介绍了发布Web系统的两个工具,FrontPage和WebDAV。对于FrontPage,这里就不多说了,这个工具早就已经过时了,有兴趣的同学可以看一下维基百科上的介绍。下面就着重介绍一下WebDAV。

WebDAV与协作协作

WebDAV(Web Distributed Authoring and Versioning,分布式写作与版本管理)为Web发布增添了新的内容——协作。WebDAV(作为RFC2518发表)专注于对HTTP进行扩展,以提供协作写作的适宜平台。下面分别从不同方面对WebDAV进行介绍。

WebDAV的方法

WebDAV定义了一些新的HTTP方法并修改了其他一些HTTP方法的操作范围。WebDAV新增的方法如下(Page.449~Page.450)。

  • PROPFIND
    获取资源的属性。

  • PROPPATCH
    在一个或多个资源上设定一个或多个属性。

  • MKCOL
    创建集合。

  • COPY
    从指定的资源把资源或者资源集合复制到指定的目的地。目的地可以在另一台机器上。

  • MOVE
    从指定的源端把资源或者资源集合移动到指定的目的地。目的地可以在另一台机器上。

  • LOCK
    锁定一个或多个资源。

  • UNLOCK
    把先前锁定的资源解锁。

其中WebDAV修改的HTTP方法有DELETE、PUT以及OPTIONS。本章后面在讲解WebDAV不同功能的时候会对这些操作有近一步的讲解。

WebDAV与XML

WebDAV的方法通常都需要在请求和响应中关联大量的信息。HTTP通常用报文首部来交换这类信息。然后,只在首部传输必要的信息已经暴露了一些局限性,包括难以有选择地对请求中的多个资源应用首部信息、不利于表示层次结构等。

WebDAV借助了XML解决这个问题,它是一种元标记语言,提供了描述结构化数据的格式。XML为WebDAV提供了以下解决方案(Page.450)。

  • 对那些描述数据处理方式的指令进行格式化的方法。
  • 在服务器上对复杂的响应进行格式化的方法。
  • 交换与所处理的集合和资源有关的定制信息的方法。
  • 承载数据自身的灵活工具。
  • 对大多数国际化问题的健壮解决方案。

习惯上会把XML文档里引用的方案定义保存在一个DTD(Document Type Definition,文档类型定义)文件中。

WebDAV首部集

WebDAV引入了一些HTTP首部来增强新方法的功能。这里做一个简介(Page.451~Page.452)。

  • DAV
    用于了解服务器的WebDAV能力。

  • Depth
    这是一个关键元素,用于把WebDAV扩展到支持含有多级层次关系的资源组。

  • Destination
    首部对WebDAV定义的许多方法进行了修改时。用到Depth首部的方法有:LOCK、COPY以及MOVE。

  • Destination
    定义这个首部是用来辅助COPY或MOVE方法标识目标URI的。

  • If
    定义的唯一一个状态令牌是锁定令牌。

  • Lock-Token
    UNLOCK方法需要用这个首部指定要删除的锁。

  • Overwrite
    用于COPY和MOVE方法,指定是否要覆盖目标。

  • Timeout
    客户端用这个请求首部指定要求锁定的超时值。

WebDAV的锁定与防止覆写

WebDAV支持两种类型的锁:

  • 对资源或集合的独占写锁;
  • 对资源或集合的共享写锁。

独占写锁保证只有锁的拥有者有写权限。这种锁完全消除了潜在的冲突。共享写锁允许多个人在某个给定的文件上工作。这种锁定机制在多名作者对各自的活动都知晓的情况下可以很好地工作。

WebDAV中有两个新方法支持锁定机制:LOCK和UNLOCK。

WebDAV中的一个强大特性是它能够允许单个LOCK请求锁定多个资源。WebDAV的锁定不需要客户端保持与服务器的连接。下面是一个简单的LOCK请求示例(Page.453~Page.454):

LOCK /ch-publish.fm HTTP/1.1 Host: minstar Content-Type: text/xml User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT) Content-Length: 201 <?xml version="1.0"> </a:lockscpe> AuthorA </a:lockinfo> </code>

提交的XML以\<lockinfo\>元素作为其基元素。在\<lockinfo\>结构中,有以下3种子元素(Page.454)。

  • \<locktype\>
    指明锁定的类型。当前只有一种可选值,即write
  • \<lockscope\>
    指明这是独占锁还是共享锁。
  • \<owner\>
    这个字段设置为当前持有锁的人。

下面是这个LOCK请求的成功响应(Page.454):

HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Fri, 10 May 2002 20:56:18 GMT Content-Type: text/xml Content-Length: 419 AutherA opaquelocktoken:\*\*\*\*\* 0 Second-180

\<lockdiscovery\>元素充当着存储锁信息的容器。嵌入在\<lockdiscovery\>元素中的子元素有\<activelock\>,它持有请求发送来的信息(\<locktype\>\<lockscope\>以及\<owner\>)。此外,\<activelock\>中还含有以下子元素(Page.454~Page.455)。

  • \<locktoken\>
    用称为opaquelocktoken的URI方案唯一标识的锁。考虑到HTTP天生就是无状态的,该令牌用于在将来的请求中标识锁的所有权。
  • \<depth\>
    它是Depth首部的值的副本。
  • \<timeout\>
    指明锁的超时时间。在上面的响应中,超时值是180秒。

UNLOCK方法用于解除资源上的锁。示例如下(Page.456):

UNLOCK /ch-publish.fm HTTP/1.1 Host: minstar.inktomi.com User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT) Lock-Token: opaquelocktoken:\*\*\*\*\*\*\*\*\* HTTP/1.1 204 OK Server: Microsoft-IIS/5.0 Date: Fri, 10 May 2002 20:56:18 GMT

与大多数资源管理请求一样,要是UNLOCK操作成功,WebDAV要满足两个条件:第一,先前已经成功完成了摘要认证步骤;第二,要与在Lock-Token首部中发送的锁定令牌相匹配。如果解锁成功,会向客户端发送204 NO Content状态码。

属性和元数据

属性描述了资源的信息,包括作者的名字、修改日期、内容分级,等等。HTML中的元标记的确提供了把这种信息嵌入在内容之中的机制,但很多种资源(比如所有二进制数据)都无法嵌入元数据。

PROPFIND方法

PROPFIND方法用于获取一个给定文件或一组文件(也称为“集合”)的属性。PROPFIND支持3种类型的操作:

  • 请求所有的属性及其值;
  • 请求一组属性及其值;
  • 请求所有属性的名称。
PROPPATCH方法

PROPPATCH方法为对指定资源设置或删除多个属性提供了原子化机制。原子化可以保证要么所有请求都成功,要么跟所有请求都没发出一样。

PROPPATCH方法的XML基元素是\<propertyupdate\>。它作为一个容器使用,容纳了需要修改的属性。XML的\<set\>和\<remove\>元素用于描述操作。

集合与名字空间管理

集合是指对预定义的层次结构中的资源进行的逻辑或物理上的分组。WebDAV使用了XML的名字空间机制。与传统的名字空间不同,XML名字空间的分区在阻止所有名字空间冲突的同时,还允许进行精确的结构控制。WebDAV提供了5种方法对名字空间进行操作:DELETEMKCOLCOPYMOVE以及PROPFIND

MKCOL方法

MKCOL方法允许客户端在服务器上指定的URL处创建集合。

COPY与MOVE方法

MKCOL一样,有若干种方法可以定义新的COPYMOVE操作方法。其中一种方式规定COPY方法先对源进行GET请求,下载资源,然后用PUT请求上传回服务器。可以设想,MOVE方法也有类似的操作情况(有个额外的DELETE操作)。

增强的HTTP/1.1方法

WebDAV修改了HTTP中的DELETEPUT以及OPTIONS方法的语义。GETHEAD方法的语义保持不变。POST执行的操作总是由特定的服务器实现来定义的,而WebDAV没有对POST的语义进行任何修改。

第二十章:重定向与负载均衡

顾名思义,本章主要是介绍重定向和负载均衡。首先呢,本章一开始街扫了为什么要使用重定向,书中给出了三种使用重定向的原因(Page.470)。

  • 可靠地执行HTTP事务;
  • 最小化时延;
  • 节约网络带宽。

通用的重定向方法

书中列出了几种常见的重定向方法。

HTTP重定向(Page.474)

Web服务器可以将短的重定向报文发回给客户端,告诉他们去其他地方试试。有些Web站点会将HTTP重定向作为一种简单的负载均衡形式来使用。处理重定向的服务器(重定向服务器)找到可用的负载最小的内容服务器,并将浏览器重定向到那台服务器上去。与其他一些形式的重定向相比,HTTP重定向的优点之一就是重定向服务器知道客户端的IP地址。

HTTP重定向可以在服务器间导引请求,但它有以下几个缺点(Page.475)。

  • 需要原始服务器进行大量处理来判断要重定向到哪台服务器上去。有时,发布重定向所需的处理量几乎与提供页面本身所需的处理量一样。
  • 增加了用户时延,因为访问页面时要进行两次往返。
  • 如果重定向服务器出故障,站点就会瘫痪。
DNS重定向(Page.476~Page.479)
  • DNS轮转
    最常见的重定向技术之一也是最简单的重定向技术之一。DNS轮转使用了DNS主机名解析中的一项特性,在Web服务器集群中平衡负载。这是一种单纯的负载均衡策略,没有考虑任何与客户端和服务器的相对位置,或者服务器当前负载有关的因素。
  • 多个地址及轮转地址的循环
    大多数DNS客户端只会使用多地址集中的第一个地址。为了均衡负载,大多数DNS服务器都会在每次完成查询之后对地址进行轮转。这种地址轮转通常称作DNS轮转。
  • 用来平衡负载的DNS轮转
    由于大多数DNS客户端只使用第一个地址,所以DNS轮转可以在多台服务器间提供负载均衡。如果DNS没有对地址进行轮转,大部分客户端就总是会将负载发送给第一台服务器。
  • DNS缓存带来的影响
    DNS对服务器的每次查询都会得到不同的服务器地址序列,所以DNS地址轮转会将负载分摊。但是这种负载均衡并不完美,因为DNS查找的结果可能会被记住,并被各种应用程序、操作系统和一些简易的子DNS服务器重用。很多Web浏览器都会对主机进行DNS查找,然后一次次地使用相同的地址,以减少DNS查找的开销,而且有些服务器也更愿意保持与同一台客户端的联系。另外,很多操作系统都会自动进行DNS查找,并将结果缓存,但并不会对地址进行轮转。因此,DNS轮转通常都不会平衡单个客户端的负载——一个客户端通常会在很长时间内连接到一台服务器上。
  • 其他基于DNS的重定向算法
    1.负载均衡算法
    2.邻接路由算法
    3.故障屏蔽算法
任播寻址(Page.480)

在任播寻址中,几个地理上分散的Web服务器拥有完全相同的IP地址,而且会通过骨干路由器的“最短路径”路由功能将客户端的请求发送给离它最近的服务器。

IP MAC转发(Page.481)

在以太网中,HTTP报文都是以携带地址的数据分组的形式发送的。每个分组都有一个第四层地址,由源IP地址、目的IP地址以及TCP端口号组成,它是第四层设备所关注的地址。每个分组还有一个第二层地址、MAC(Media Access Control,媒体访问层)地址,这是第二层设备(通常是交换机和Hub)所关注的地址。第二层设备的任务是接收具有特定输入MAC地址的分组,然后将其转发到特定的输出MAC地址上去。

IP地址转发(Page.482)

在IP地址转发中,交换机或其他第四层设备会检测输入分组中的TCP/IP地址,并通过修改目的IP地址(不是目的MAC地址),对分组进行相应的转发。与MAC转发相比,这么做的优点是目标服务器不需要位于一跳远的地方;只需要位于交换机的上游就行了,而且通常第三层的端到端因特网路由都会将分组传送到正确的地方。这种类型的转发也被称为NAT(Network Address Translation,网络地址转换)。

网元控制协议(Page.484)

NECP(Network Element Control Protocol,网元控制协议)允许网元(NE,路由器和交换机等负责转发IP分组的设备)与服务器(SE,Web服务器和代理缓存等提供应用层请求的设备)进行交互。

代理的重定向方法

介绍了三种类型的方法。分别是显示浏览器配置、代理自动配置、Web代理自动发现协议。下面我们分别做一个简单的介绍。

显示浏览器配置(Page.485)

大多数浏览器都可以配置为从代理服务器上获取内容——浏览器中有一个下拉菜单,用户可以在这个菜单中输入代理的名字或IP地址以及端口号。

但是,显示浏览器配置有以下两个主要的缺点。

  • 配置为使用代理的浏览器,即使在代理无法响应的情况下,也不会去联系原始服务器。如果代理崩溃了,或者没有正确配置浏览器,用户就会遇到连接方面的问题。
  • 对网络架设进行修改,并将这些修改通知给所有的终端用户都是很困难的。如果服务提供商要添加更多的代理服务器,或者使其中一些退出服务,用户都要修改浏览器代理设置。
代理自动配置(Page.486~Page.487)

显示配置浏览器使其联系特定的代理,这样会限制网络架构方面的变动,因为它是靠用户来介入并重新配置浏览器的。自动配置方式可以动态配置浏览器,连接到正确的代理服务器,以解决这个问题。这种方法已经实现了,被称为代理自动配置协议(PAC)协议。PAC是网景公司定义的。

PAC的基本思想是让浏览器去获取一个称为PAC的特殊文件,这个文件说明了每个URL所关联的代理。

Web代理自动发现协议(Page.487~Page.492)

WPAD(Web代理自动发现协议)的目标是在不要求终端用户手工配置代理设置而且不依赖透明流量拦截的情况下,为Web浏览器提供一种发现并使用附近代理的方式。因为可供选择的发现协议有很多,而且不同浏览器的代理使用配置也存在差异。

缓存重定向方法(Page.492~Page.496)

WCCP重定向

Cisco系统公司开发的WCCP可以使路由器将Web流量重定向到代理缓存中去。WCCP负责路由器和缓存服务器之间的通信,这样路由器就可以对缓存进行验证(确保它们已启动且正在运行),在缓存之间进行负载均衡,并将特定类型的流量发送给特定的缓存了。WCCP版本2(WCCP2)是个开放的协议。

因特网缓存协议(Page.496~Page.497)

ICP(因特网缓存协议)允许缓存在其兄弟缓存中查找命中内容。可以把ICP当作一个缓存集群协议。HTTP请求报文的最终目的地可以通过一系列的ICP查询确定,从这个角度来说,它就是一个重定向协议。

缓存阵列路由协议(Page.497~Page.500)

代理服务器通过拦截来自单个用户的请求,提供所请求Web对象的缓存副本,极大地降低了发往因特网的流量。但随着用户数的增加,大量流量可能会使代理服务器自身超载。

对此问题的一种解决方案就是使用多个代理服务器将负载分散到一组服务器上。CARP(缓存阵列路由协议)是微软公司和网景公司提出的一个标准,通过这个协议来管理一组代理服务器,使这组代理服务器对用户来说就像一个逻辑缓存一样。

CARP是ICP的一个替代品。CARP和ICP都允许管理者通过使用多个代理服务器来提高性能。但CARP的一个缺点是,如果某个代理服务器不可用了,就要重新修改散列表以反映这种变化,而且必须重新配置现代代理服务器上的内容。

总之,CARP协议允许将一组代理服务器看成单个的集群缓存,而不是(像ICP中那样的)一组相互合作但又相互独立的缓存服务器。

超文本缓存协议(Page.500~Page.503)

HTCP(超文本缓存协议)允许兄弟缓存之间通过URL和所有的请求及响应首部来互相查询文档是否存在,以降低错误命中的可能。

HTCP允许通过查询报文将请求和响应首部发送给兄弟缓存,这样可以降低缓存查询中的错误命中率。通过进一步允许在兄弟缓存间交换策略信息,HTCP还可以提高兄弟缓存之间的合作能力。

第二十一章:日志记录与使用情况跟踪

本章主要介绍了服务器上的日志。大多数情况下,日志的记录出于两种原因:查找服务器或代理中存在的问题(比如,哪些请求失败了),或者是生成Web站点访问方式的统计信息。

通常情况下,记录下来的几个字段示例为(Page.506):

  • HTTP方法;
  • 客户端和服务器的HTTP版本;
  • 所请求资源的URL;
  • 响应的HTTP状态码;
  • 请求和响应报文的尺寸(包含所有的实体主体部分);
  • 事务开始时的时间戳;
  • Referer首部和User-Agent首部的值。

日志格式

常见日志格式(Page.507)

最常见的日志格式之一就是常用日志格式。这种日志格式最初由NCSA定义,很多服务器在默认情况下都会使用这种日志格式。

组合日志格式(Page.508)

另一种常用日志格式为组合日志格式(Combined Log Format)。

网景扩展日志格式(Page.509)

网景的格式是基于NCSA的常用日志格式的,但它们扩展了该格式,以支持与代理和Web缓存这样的HTTP应用程序相关的字段。

网景扩展2日志格式(Page.510)

另一种网景日志格式,网景扩展2日志格式采用了扩展日志格式,并添加了一些与HTTP代理和Web缓存应用程序有关的附加信息。

Squid代理日志格式(Page.512)

Squid代理缓存是Web上一个很古老的部分。

命中率测量(Page.515~Page.516)

原始服务器通常会出于计费的目的保留详细的日志记录。由于日志数据会遗失,所以,内容提供者会对其最重要的页面进行缓存清除(cache bust)。缓存清除是指内容提供者有意将某些内容设置为无法缓存,这样,所有对此内容的请求都会被导向原始服务器。

命中率测试协议是对HTTP的一种扩展,它为这个问题提供了一种解决方案。命中率测量协议要求缓存周期性地向原始服务器汇报缓存访问的统计数据。

概述

命中率测量协议定义了一种HTTP扩展,它提供了一些基本的功能,缓存和服务器可以实现这些功能来共享访问信息,规范已缓存资源的可使用数次数。

Meter首部

命中率测量扩展建议使用新增加的首部Meter,缓存和服务器可以通过它在相互间传输与用法和报告有关的指令,这与用来进行缓存指令交换的Cache-Control首部很类似。

Comments