HTTP结构

第二部分的5章主要介绍了HTTP服务器,代理,缓存,网关和机器人应用程序,这些都是Web系统架构的构造模块。

Web服务器 第五章

Web服务器会对HTTP请求进行处理并提供响应。术语”web服务器”可以用来表示Web服务器的软件,也可以用来表示提供Web页面的特定设备或计算机。

实际的Web服务器会做些什么

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

第一步——接受客户端连接

如果客户端已经打开了一条到服务器的持久连接,可以使用那条连接来发送它的请求。否则,客户端需要打开一条新的到服务器的连接。
处理新连接
客户端请求一条道web服务器的TCP连接时,Web服务器会建立连接,判断连接的另一端是哪个客户端,从TCP连接中将IP地址解析出来。一旦新连接建立起来并被接受,服务器就会将新连接添加到其现存Web服务器连接列表中,并做好监视连接上数据传输的准备。

客户端主机名识别
可以用”反向DNS”对大部分Web服务器进行配置,以便将客户端IP地址转换成客户端主机名。但需要注意的是,主机名的查找可能会花费很长时间,这样会降低Web事务处理的速度。因此,很多大容量Web服务器要么会禁止主机名解析,要么只允许对特定内容进行解析。

第二步——接收请求报文

连接上有数据到达时,web服务器会从网络连接中读取数据,并将请求报文中的内容解析出来。
解析请求报文时,web服务器会不定期地从网络上接收输入数据。网络连接可能随时都会出现延迟。web服务器需要从网络中读取数据,将部分报文数据临时存储在内存中,直到收到足以进行解析的数据并理解其意义为止。
报文的内部表示法
有些Web服务器还会用便于进行报文操作的内部数据结构来存储请求报文,这样就可以将这些报文的数据存放在一个快速查询表中,以便快速访问特定首部的具体值了。

连接的输入/输出处理结构
不同的Web服务器结构以不同的方式为请求服务,如下。

  • 单线程Web服务器
  • 多进程及多线程Web服务器
  • 复用I/O的服务器
  • 复用的多线程Web服务器

第三步——处理请求

一旦web服务器收到了请求,就可以根据方法,资源,首部和可选的主体部分对请求进行处理了。

第四步——对资源的映射以及访问

Web服务器是资源服务器。他们负责发送预先创建好的内容,比如HTML页面或者JPEG图片,以及运行在服务器上的资源生成程序所产生的动态内容。在web服务器将内容传送给客户端之前,要将请求报文中的URI映射为Web服务器上适当的内容或内容生成器,以识别出内容的源头。

docroot
通常,web服务器的文件系统会有一个特殊的文件夹专门用于存放web内容。这个文件夹被称为文档的根目录(document root)。web服务器从请求报文中获取URI,并将其附加在文档根目录的后面。

目录列表
Web服务器可以接收对目录URL的请求,其路径可以解析为一个目录,而不是文件。我们可以对大多数Web服务器进行配置,使其在客户端请求目录URL时采取不同的动作。

  • 返回一个错误
  • 不返回目录,返回一个特殊的默认”索引文件” (DirectoryIndex index.html home.html)
  • 扫描目录,返回一个包含目录内容的HTML界面 (在Aapche中可以通过指令Options -Indexes禁止)

第五步——构建响应

一旦web服务器识别出了资源,就执行请求方法中描述的动作,并返回响应报文。响应报文中包含了响应状态码,响应首部,如果生成了响应主体的话,还包括响应主体。

第六步——发送响应

Web服务器通过连接发送数据时也会面临与接收数据一样的问题。服务器要记录连接的状态,还要特别注意对持久连接的处理。对非持久连接而言,服务器应该在发送了整条报文之后,关闭自己这一端的连接。
对持久连接来说,连接可能仍保持打开状态,在这种情况下,服务器要特别小心,要正确的计算Content-Length首部,不然客户端就无法知道响应什么时候结束了。

第七步——记录日志

当事务结束之后,web服务器会在日志文件中添加一个条目,来描述已执行的事务。

代理 第六章

web上的代理服务器是代表客户端完成事务处理的中间人。如果没有Web代理,HTTP客户端就要直接与HTTP服务器进行对话,有了Web代理,客户端就可以与代理进行对话,然后由代理代表客户端与服务器进行交流,客户端仍然会完成事务的处理,但它是通过代理服务器提供的优质服务来实现的。

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

代理的应用
代理服务器可以实现各种有用的功能,他们可以改善安全性,提高性能,节省费用。代理服务器可以看到并接触所有流过的HTTP流量,所有代理可以监视流量并对其进行修改,以实现很多有用的增值Web服务。

  • 儿童过滤器
  • 文档访问控制
  • 安全防火墙
  • web缓存
  • 反向代理
  • 内容路由器
  • 转码器
  • 匿名者

代理服务器的部署

可以根据其目标用途,将代理放在任意位置。

  • 出口代理
  • 访问(入口)代理
  • 反向代理
  • 网络交换代理

层次化的代理
可以通过代理层次结构将代理级联起来。在代理的层次结构中,会将报文从一个代理传给另外一个代理,直到最终抵达原始服务器为止(然后通过代理传回客户端)。

如何使用代理

  • 修改客户端的代理配置
  • 修改网络,对流量进行拦截并导入一个代理
  • 修改DNS的命名空间,假扮web服务器的名字和IP地址。
  • 修改Web服务器,服务器发送重定向命令

客户端的代理设置

  • 手工配置
  • 预先配置浏览器
  • 代理的自动配置 PAC
  • WPAD的代理发行

缓存 第七章

web缓存是可以自动保存常见文档副本的HTTP设备。当Web请求抵达缓存时,如果本地有”已缓存的”副本,就可以从本地存储设备而不是原始服务器中提取这个文档。

缓存可以优化一下问题

  • 冗余的数据传输
  • 带宽瓶颈
  • 瞬间拥塞
  • 距离时延

命中和未命中的

缓存无法保存世界上的每一份文档。可以用已有的副本为某些到达缓存的请求提供服务,这被称为缓存命中 (cache hit),其他一些请求可能因为没有副本可用,而被转发给原始服务器,这被称为缓存未命中(cache miss)。

  • 文档命中率 (说明了阻止了多个通往外部网络的Web事务,有效降低整体时延)
  • 字节命中率 (说明了阻止了多少字节传向因特网,有利于节省带宽)

    再验证

    缓存可以在任意时刻,以任意频率对副本进行再验证。如果验证过没有更新则将副本提供给客户端,这被称为再验证命中或缓慢命中,这种方式确实要与原始服务器进行核对,所以会比单纯的缓存命中要慢,但它没有从服务器中获取对象数据,所以要比缓存未命中快一些。

缓存的处理步骤

  1. 接收——缓存从网络中读取抵达的请求报文
  2. 解析——缓存对报文进行解析,提取出URL和各种首部
  3. 查询——缓存查看是否有本地副本可用,如果没有,就获取一份副本(并将其保存在本地)
  4. 新鲜度检测——缓存查看已缓存副本是否足够新鲜,如果不是,就询问服务器是否有任何更新
  5. 创建响应——缓存会用新的首部和已缓存的主体来构建一条响应报文
  6. 发送——缓存通过网络将响应发回给客户端
  7. 日志——缓存可选地创建一个日志文件条目来描述这个事务

保持副本的新鲜

文档过期 (document expiration)

通过特殊的HTTP Cache-Control: max-age = 484200首部和Expires: Fri, 05,2016, 17:20:30 GMT首部,HTTP让原始服务器向每个文档附加了一个过期日期。在缓存文档过期之前,可以以任意频率使用这些副本,而无需与服务器联系。
HTTP/1.0+的Expires首部使用的是绝对日期而不是相对时间,所以我们更倾向于使用比较新的HTTP/1.1的Cache-Control,绝对日期依赖于计算机时钟的正确设置。

服务器再验证 (server revalidation)

文档过期并不意味着它和服务器上目前活跃的文档有实际的区别,这只是意味着到了要进行核对的时间了。

  1. 如果再验证显示内容发生了变化,缓存会获取一份新的文档副本,并将其缓存在旧文档的位置上,然后将文档发送给客户端。
  2. 如果再验证显示内容没有发送变化,缓存只需要获取新的首部,包括一个新的过期时间,并对缓存中的首部进行更新就行了。

用条件方法进行再验证

HTTP定义了5个条件请求首部,对缓存再验证来说最有用的2个首部是If-Modified-Since:dateIf-None-Match:tag(只有两个条件都满足时,才能返回304响应)。

另外3个条件首部包括If-Unmodified-Since(在进行部分文件的传输时,获取文件的其余部分之前要确保文件未发生变化,此时这个首部是非常有用的),If-Range(支持对不完整文档的缓存)和If-Match(用于与web服务器打交道时的并发控制)

If-Modified-Since:Date 再验证

如果从指定日期之后文档被修改过了,就执行请求的方法。可以与Last-Modified服务器响应首部配合使用,只有在内容被修改后与已缓存版本有所不同时才去获取内容。

If-None-Match:实体标签再验证
有些情况下仅使用最后修改日期进行再严重是不够的

  • 有些文档可能会被周期性地重写(比如,从一个后台进程中写入),但实际包含的数据常常是一样的。经内容没有变化,但修改日期会发生变化。
  • 有些文档可能被修改了,但所做修改并不重要,不需要让世界范围内的缓存都重装数据(比如对拼写或注释的修改)
  • 有些服务器无法准确地判定其页面的最后修改日期
  • 有些服务器提供的文档会在亚秒间隙发生变化(比如,实时监视器),对这些服务器来说,以一秒为粒度的修改日期可能就不够用了

为了解决这些问题,HTTP允许用户对被称为实体标签(ETag)的“版本标识符”进行比较。实体标签是附加到文档上的任意标签(引用字符串)。
当发布者对文档进行修改时,可以修改文档的实体标签来说明这个新的版本,这样,如果实体标签被修改了,缓存就可以用If-None-Match条件首部来GET文档的新副本了。

控制缓存的能力

服务器可以通过HTTP定义的几种方式来指定在文档过期前可以将其缓存多长时间。按照优先级递减的顺序,服务器可以:

  • Cache-Control: no-store
  • Cache-Control: no-cache
  • Cache-Control: must-revalidate
  • Cache-Control: max-age
  • 附加一个Expires日期首部到响应中去
  • 不附加过期信息,让缓存确定自己的过期日期

集成点:网关,隧道及中继 第八章

网关 gateway

HTTP扩展和接口的发展是由用户需求驱动的。要在web上发布更复杂的资源的需求出现时,单个应用程序无法处理所有这些能想到的资源。

为了解决这个问题,开发者提出了网关的概念,网关可以作为某种翻译器使用,他可以自动将HTTP流量转换为其他协议,这样HTTP客户端无需了解其他协议,就可以与其他应用层序进行交互了。

可以用一个斜杠来分割客户端和服务器端协议,并以此对网关进行描述
<客户端协议>/<服务器端协议>

CGI Common Gateway Interface

CGI是一个标准接口集,web服务器可以用它来装载程序以响应对特定URL的HTTP请求,并收集程序的输出数据,将其放在HTTP响应中回送。

隧道

web隧道允许用户通过http连接发送非http流量,这样就可以在http上捎带其他协议数据了。使用web隧道最常见的原因就是要在http连接中嵌入非http流量,这样,这类流量就可以穿过只允许web流量通过的防火墙了。

中继 relay

中继是没有完全遵循http规范的简单http代理。中继负责处理http中建立连接的部分,然后对字节进行盲转发。

Web机器人 第九章

Web爬虫是一种机器人,它们会递归地对各种信息性Web站点进行遍历,获取第一个Web页面,然后获取那个页面指向的所有web页面,然后是那些页面指向的所有页面,以此类推。递归地跟踪这些web链接的机器人会沿着HTML超链接创建的网络”爬行”,所有称其为爬虫(crawler)或蜘蛛(spider)。

爬虫

根集

在把爬虫放出去之前,需要给他一个起始点。爬虫开始访问的URL初始集合被称作根集(root set)。

避免环路

机器人必须知道他们到过何处,以避免环路(cycle)的出现。

面包屑留下的痕迹

管理大规模web爬虫对其访问过的地址进行管理时使用的一些有用的技术

  • 树和散列表
  • 有损的存在位图
  • 检查点
  • 分类

别名

由于URL“别名”的存在,即使使用了正确的数据结构,有时也很难分辨出以前是否访问过某个页面,如果两个URL看起来不一样,但实际指向的是同一资源,就称这两个URL互为”别名”。

避免循环和重复的一些方法

  • 规范化URL
  • 广度优先的爬行
  • 节流
  • 限制URL大小
  • URL/站点黑名单
  • 模式检测
  • 内容指纹
  • 人工监视

机器人的HTTP

虚拟主机

机器人实现者要支持Host首部,随着虚拟主机的流行,请求中不包含Host首部的话,可能会使机器人将错误的内容与一个特定的URL关联起来。

条件请求

对时间戳或实体标签进行比较,看看它们最近获取的版本是否已经升级以减少获取未更新的内容。

分享 留言