• 万维网 (World Wide Web)

• Web 具有的按需操作

  2.2.1

  HTTP 概况

• Web 应用层协议是超文本传输协议 (HyperText Transfer Protocol, HTTP)

  • Web 的核心
  • RFC 1945 与 RFC 2616 中进行了定义

• HTTP 由两个程序实现：

  1. 客户程序
  2. 服务器程序
  • 客户程序和服务器程序运行在不同的端系统中，通过交换 HTTP 报文进行会话。
  • HTTP 定义了这些保温的结构以及客户和服务器进行报文交换的方式。

• Web 页面 (Web page) 也叫文档是由对象组成的。

  • 一个对象 (object) 只是一个文件
    • xxx.html
    • xxx.jepg
    • xxx.mp3
    • xxx.avi
  • 这样的文件可以通过一个 URL 地址寻址

• 多数 Web 页面含有一个 HTML 基本文件 (base HTML file) 以及几个引用对象。

  • 一个 Web 页面含有一个 HTML 基本文件和 5 个 jepg 图形；那么即有 6 个对象
  • HTML 基本文件通过对象的 URL 地址引用页面中的其他对象。
  • 每个 URL 地址由两部分组成：
    1. 存放对象的服务器主机名
    2. 对象的路径名
       • http://www.something.com/demo/hello.gif
       • www.something.com 就是主机名
       • /demo/hello.gif 就是路径名

• Web 浏览器 (Web browser) 实现了 HTTP 的客户端，所以Web 环境中经常交替使用 “浏览器” 和 “客户”两个术语。

• Web 服务器 (Web server) 实现了 HTTP 的服务器端，用于存储 Web 对象，每个对象由 URL 寻址。
  • Apache
  • Microsoft Internet Information Server 微软互联网信息服务器等
• HTTP 定义了 Web 客户向 Web 服务器请求 Web 页面的方式，以及服务器向客户传送 Web 页面的方式。

• 当用户请求一个 Web 页面时，浏览器向服务器发出对该页面中所包含对象的 HTTP 请求报文，服务器接收到请求并用包含这些对象的 HTTP 响应报文进行响应。

• HTTP 使用 TCP 作为他的支撑运输协议。

• HTTP 客户首先发起一个与服务器的 TCP 连接。
• 一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问 TCP。
  • 客户端的套接字接口是客户进程与 TCP 连接的 “门”
  • 服务器端的套接字接口是服务器进程与 TCP 连接的 “门”
• 客户向他的套接字接口发送 HTTP 请求报文并从他的套接字接口发送 HTTP 响应报文。
• 服务器从他的套接字接口接收 HTTP 请求报文和向他的套接字接口发送 HTTP 响应报文。
• 一旦客户向他的套接字接口发送了一个请求报文，该报文就脱离了客户控制进入 TCP 的控制。
  • TCP 为 HTTP 提供可靠数据服务。
  • 一个客户进程发出的每个 HTTP 请求报文最终能完整地到达服务器；反之亦然。
    • 这是分层体系结构最大地优点：HTTP 协议不用担心数据丢失，不用关注 TCP 从网络地数据丢失和乱序故障中恢复地细节。
    • 这是 TCP 以及协议栈较低层协议地工作。
• 服务器向客户发送被请求的文件，但不存储任何有关客户的状态信息。
  • 短时间内多次请求，服务器并不会因为做过相同的事情就不再做出反应，仍能重新发送对象。
  • 所以 HTTP 是一个无状态协议 (stateless protocol)
• Web 是一个 客户 - 服务器应用程序体系结构
  • Web 服务器总是打开的
  • 具有固定的 IP 地址
  • 可以服务不同的浏览器请求

2.2.2

非持续连接和持续连接

• 很多因特网应用程序中，客户和服务器会长时间通信。
• 客户发出的请求经 TCP 进行的
  • 非持续连接 (non-persistent connection)
    • 每个请求是一个单独的 TCP 连接发送
  • 持续连接 (persistent connection)
    • 所有的请求以及响应经相同的 TCP 连接发送
• HTTP 在默认的方式下使用持续连接，HTTP 客户和服务器也能配置成非持续连接。

1. 采用非持续连接的 HTTP

举例：从服务器向客户传送一个 Web 页面的步骤

• 该页面含有一个 HTML 基本文件 和 10 个 jepg 图形
• 11 个对象位于同一台服务器上
• HTML 文件的 URL：http://www.someSchool.edu/someDepartment/home.index

1. HTTP 客户进程在 80 端口发起一个到服务器 www.someSchool.edu 的 TCP 连接。
   • 80 端口是 HTTP 的默认端口
   • 客户和服务器上分别有一个套接字与该连接相关联。
2. HTTP 客户经他的套接字向该服务器发送一个 HTTP 请求报文。
   • 请求报文中包含了路径名: /someDepartment/home.index
3. HTTP 服务器进程经他的套接字接收该请求报文
   • 从其存储器 (RAM 或 磁盘) 中检索出其对象: www.someSchool.edu/someDepartment/home.index
   • 在一个 HTTP 响应报文中封装对象
   • 通过其套接字向客户发送响应报文
4. HTTP 服务器进程通知 TCP 断开该 TCP 连接。
   • 但是直到 TCP 确认客户已经完整地收到响应报文为止，才会实际中断连接。
5. HTTP 客户接收响应报文，TCP 连接关闭。
   • 该报文指出封装的对象是一个 HTML 文件，客户从响应报文中取出该文件，检查该 HTML 文件，得到对 10个 jepg 图形的引用。
6. 对每个引用的 jepg 图形对象重复前 4 个步骤。

• 当浏览器收到 Web 页面后，向用户展示该页面。
• 不同的浏览器可能以不同的方式解释 (显示) 页面。
• HTTP 与客户如何解释一个 Web 页面没有关系。
• HTTP 规范仅定义在 HTTP 客户程序与 HTTP 服务器程序之间的通信协议。

例子解读

• 每个TCP连接在服务器发送一个对象后关闭，即该连接并不为其他的对象而持续下来。
• 每个TCP连接只传输一个请求 报文和一个响应报文。
• 当用户请求该Web页面时，要产生11个TCP连接
• 用户能够配置现代浏览器来控制连接的并行度
  • 没有明确客户获得这10个JPEG图形对象是使用10个串 行的TCP连接，还是某些JPEG对象使用了一些并行的TCP连接
• 默认方式下，大部分浏览器打开5 ~ 10个并行的TCP连接，而 每条连接处理一个请求响应事务
• 如果用户愿意，最大并行连接数可以设置为1,这样10条连 接就会串行建立

单估算用户请求到接收文件所用时间

• 往返时间 (Round-Trip Time, RTT)，一个短分组从客户到服务器然后再返回客户所花费的时间。
  • 分组传播时延
  • 分组在中间路由器和交换机上的排队时延
  • 分组处理时延

• 在客户端与服务器之间发起一个 TCP 连接
• 三次握手
  • 客户向服务器发送一个小 TCP 报文段
  • 服务器用一个小 TCP 报文段做出确认和响应
  • 客户向服务器返回确认
• 三次握手中的前两个部分所耗费的时间占用了一个 RTT。
• 完成三次握手的前两个部分后，客户结合三次握手的第三部分 (确认) 向该 TCP 连接发送一个 HTTP 请求报文。
• 一旦该请求报文到达服务器，服务器就在该 TCP 连接上发送 HTML 文件。该 HTTP 请求/响应 用去了另一个 RTT。
• 粗略的讲，总响应时间就是 2个 RTT 加上服务器传输 HTML 文件的时间。

非持续连接的缺点

1. 必须为每一个请求的对象建立和维护一个全新的连接。
   • 对于每个这样的连接，在客户和服务器中都要分配 TCP 的缓冲区和保持 TCP 变量。
   • 这样给 Web 服务器带来了严重的负担。
     • 一台 Web 服务器可能同时服务与数以百计不同的客户的请求。
2. 每一个对象经受两倍 RTT 的交付时延，一个 RTT 用于创建 TCP，另一个用于请求和接收一个对象。

2. 采用持续连接的 HTTP

• 在采用HTTP 1.1持续连接的情况下，服务器在发送响应后保持该TCP连接打开
• 在 相同的客户与服务器之间，后续的请求和响应报文能够通过相同的连接进行传送
• 特别 是，一个完整的Web页面（上例中的HTML基本文件加上10个图形）可以用单个持续 TCP连接进行传送
• 位于同一台服务器的多个Web页面在从该服务器发送给同一个客户时，可以在单个持续TCP连接上进行
• 对对象的这些请求可以一个接一个地发 出，而不必等待对未决请求（流水线）的回答
• 一般来说，一条连接经过一定时间间 隔（一个可配置的超时间隔）仍未被使用，HTTP服务器就关闭该连接。
• HTTP的默认模 式是使用带流水线的持续连接
• HTTP/2 ［RFC 7540］是在HTTP 1. 1基础上构建 的，它允许在相同连接中多个请求和回答交错，并增加了在该连接中优化HTTP报文请求 和回答的机制。

2.2.3

HTTP 报文格式

1. HTTP 请求报文

• HTTP 规范包含了对 HTTP 报文格式的定义。

• HTTP 有两种报文：请求报文和响应报文。

  例子：一个 HTTP 请求报文

  GET /somedir/page.html HTTP/1.1
  Host: www.someschool.edu
  Connection: close
  User-agent: Mozilla/5.0
  Accept-language: fr

• 到该报文 是用普通的ASCII文本书写的，这样有一定计算机知识的人都能够阅读它

• 到该报文由5行组成，每行由一个回车和换行符结束
  • 最后一行后再附加一个回车换行 符
  • 一个请求报文能够具有更多的行或者至少为一行
• HTTP请求报文的第一行叫作请求行 (request line)
  • 请求行有3个字段：方法字段、URL字段和HTTP版本字段
  • 方法字段可以取几种不同的值，包括GET、POST、HEAD、PUT和DELETE。
  • 绝大部分的HTTP请求报文使用 GET方法
    • 当浏览器请求一个对象时，使用GET方法，在URL字段带有请求对象的标识。
      • 该浏览器正在请求对象 /somedir/page.html
      • 浏览器实现的是 HTTP/1.1 版本
• 第二行叫做首部行 (header line)
  • Host: www.someschool.edu 指明了对象所在的主机。
  • 你也许认为该首部行是不必要的，因为在该主机中已经有一条TCP连接存在了
  • 该首部行提供的信息是Web代理高速缓存所要求的。(2.2.5)
  • 通 过包含Connection: close首部行，该浏览器告诉服务器不要麻烦地使用持续连接，它要求 服务器在发送完被请求的对象后就关闭这条连接
  • User-agent:首部行用来指明用户代理， 即向服务器发送请求的浏览器的类型
  • 这里浏览器类型是Mozilla/5.0,即Firefox浏览器
  • 通过以上信息的配置，服务器可以有效地为不同类型的用户代理实际发送相同对象的不同版本
    • 每个版本都由相同的URL寻址
  • Accept-language：首部行表示用户想 得到该对象的法语版本
    • 否则，服务器应当发送它的 默认版本
    • Accept-language:首部行仅是HTTP中可用的众多内容协商首部之一

举例：请求报文的通用格式

• 在首部 行（和附加的回车和换行）后有一个 “实体体” （entity body）
• 使用GET方 法时实体体为空，而使用POST方法时 才使用该实体体
• 当用户提交表单时， HTTP客户常常使用POST方法，例如 当用户向搜索引擎提供搜索关键词时
• 使用POST报文时，用户仍可以向服务 器请求一个Web页面，但Web页面的 特定内容依赖于用户在表单字段中输入 的内容。
  • 使用POST报文时，用户仍可以向服务 器请求一个Web页面，但Web页面的 特定内容依赖于用户在表单字段中输入的内容。
• 如果方法字段的值为POST时， 则实体体中包含的就是用户在表单字段中的输入值。
• HTML表单经常使用GET方法，并在（表单字段中）所请求的URL中包括 输入的数据
  • 一个表单使用GET方法，它有两个字段，分别填写的是 “monkeys” 和 “bananas”, 这样，该 URL 结构为 www. somesite. com/animalsearch? monkeys&bananaso
• HEAD 方法类似于 GET。
  • 当服务器收到一个使用HEAD方法的请求时，将会用一 个HTTP报文进行响应，但是并不返回请求对象。
  • 应用程序开发者常用HEAD方法进行调 试跟踪。
• PUT方法常与Web发行工具联合使用，它允许用户上传对象到指定的Web服务 器上指定的路径（目录）。
  • PUT方法也被那些需要向Web服务器上传对象的应用程序使 用。
• DELETE方法允许用户或者应用程序删除Web服务器上的对象。

2. HTTP 响应报文

HTTP 响应报文举例

• 这个响应报文有三个部分：
  1. 初始状态行 (status line)
     • 协议版本字段
     • 状态码
     • 相应状态信息
     • 本例中，状态行指示服务器正在使用 HTTP/1.1，返回 200 OK 表示服务器已经找到并正在发送请求的对象
  2. 首部行 (header line)
     • (下面会详细解释)
  3. 实体体 (entity body)
     • 实体部分是报文的主要部分
     • 包含了请求的对象本身
       • 表示为 data data data data data …

首部行

• Connection: close
  • 服务器用告诉客户，在发送完报文后将关闭该 TCP 连接。
• Date
  • 首部行指示服务器产生并发送该响应报文的日期和时间。
    • 这个时间不是指对象创建或最后修改的时间，而是服务器从它的文件系统中搜索到该对象，将该对象插入响应报文，并发送该响应报文的时间。
• Server
  • 首部行指示该报文是由一台 Apache Web 服务器产生的。
  • 类似于 HTTP 请求报文中的 User-agent: 首部行
• Last-Modified
  • 首部行指示了对象创建或者最后修改的日期和时间。
  • 首部行既可能在本地客户端，也可能在网络缓存服务器上的对象缓存。
• Content-Length
  • 首部行指示被发送的对象中的字节数。
• Content-Type
  • 首部行指示了实体体中的对象是 HTML 文本。
    • 该对象类型应该正式地由 Content-Type: 首部行来指示，而不是用文件扩展名来指示。

对状态码的补充

状态码及其响应的短语指示了请求的结果。

• 200 OK
  • 请求成功
  • 信息在返回的响应报文中
• 301 Moved Permanently
  • 请求的对象已经被永久转移
  • 新的 URL 定义在响应报文的 Location: 首部行中
  • 客户软件将自动获取新的 URL
• 400 Bad Request
  • 一个通用差错代码
  • 该请求不能被服务器所理解
• 404 Not Found
  • 被请求的文档不在服务器上
• 505 HTTP Version Not Supported
  • 服务器不支持请求报文所使用的 HTTP 协议版本

查看一个真实的 HTTP 响应报文

• Telnet 登录到一个 Web 服务器上
• 输入一个只有一行的请求报文去请求放在该服务器上的某些对象

• 在输入最后一行后连续按两次回车
• 打开一个到主机 giga.cs.umass.edu 的 80 端口的 TCP 连接，并发送一个 HTTP 请求报文。
• 将会看到一个携带包括本书交互式课后作业的基本 HTML 文件的响应报文。
• 如果指示想看 HTTP 协议的报文行，而不是获取对象本身，可以用 HEAD 代替 GET。

小结

• HTTP 规范中定义了许许多多的首部行，这些首部行都可以被浏览器，Web 服务器 和 Web 缓存服务器插入。

• 见 Krishnamurty 2001 -> 首部行和状态码

• 浏览器如何决定一个请求报文中包含哪些首部行？

  • 浏览器的首部行与很多因素有关
    • 浏览器的类型
    • 浏览器的协议版本 (HTTP/1.0 不会产生任何 HTTP/1.1 版本的首部行)
    • 浏览器的用户配置 (如喜好的语言)
    • 浏览器当前是否有一个缓存的但是可能超预期的对象版本
• Web 服务器如何决定在一个响应报文中包含哪些首部行？
  • 产品，版本，配置等信息都会影响响应报文中包含的首部行。

2.2.4

• 前面提到 HTTP 服务器是无状态的。
  • 简化了服务器的设计，并且允许工程师去开发高并发的 TCP 连接的高性能 Web 服务器。
• 一个 Web 站点通常希望能够识别用户，可能是因为服务器希望限制用户的访问，或者希望把内容与用户身份联系起来。
• HTTP 使用了 cookie。
  • cooke 在 RFC 6265 中定义
  • 允许站点对用户进行跟踪

• cookie 技术有 4 个组件

1. 在 HTTP 响应报文中有一个 cookie 的首部行
2. 在 HTTP 请求报文中有一个 cookie 的首部行
3. 在用户端系统中保留一个 cookie 文件，并由用户的浏览器进行管理
4. 位于 Web 站点的一个后端数据库

cookie 典型例子

1. 用户 Susan
2. 家中 PC 的 IE 浏览器
3. 首次于 Amazon.com 联系
4. 已经访问过 eBay.com

• 当请求报文到达 Amazon Web 服务器，该 Web 站点将产生一个唯一识别码，并以此作为索引在它的后端数据库中产生一个表项。
• Amazon Web 将用一个包含 Set-cookie: 首部的 HTTP 响应报文对 Susan 的浏览器进行响应
  • Set-cookie: 首部含有该识别码
  • 例如: Set-cookie: 1678

• 当 Susan 的浏览器接收到该 HTTP 响应报文时，会看到该 Set-cookie: 首部。

  • 该浏览器在他管理的特定 cookie 文件中添加一行：服务器的主机名和在 Set-cookie: 首部中的识别码
  • 该 cookie 文件已经有了用于 eBay 的表项，因为已经访问过。
  • 现在，浏览器就会查询该 cooie 文件并抽取对这个网站的识别码，并放到 HTTP 请求报文中包括识别码的 cookie 首行中。
  • 以后，发往该 Amazon 服务器的每个 HTTP 请求都会包含以下首部行 Cookie: 1678
  • 这种方式下，Amazon 服务器可以跟踪 Susan 在 Amazon 站点的活动。
  • 尽管 Amazon Web 站点不必知道 Susan 的名字，但是它确切知道用户 1678 按照什么顺序，在什么时间，访问了什么页面。

  • Amazon 使用 cookie 来提供他的购物车服务，即 Amazon 能够维护 Susan 的物品列表，在会话结束的时候能够对物品进行付费。

  • 一周后，再次访问 Amazon 站点，浏览器会在其请求报文中继续放入首部行 cookie: 1678。

  • Amazon 将根据 Susan 过去在 Amazon 访问的页面向她推荐产品 (大数据)
  • 如果 Susan 在 Amazon 注册过，提供全名，电子邮件地址，邮政地址，信用卡等信息
    • Amazon 能够在其数据库中包括这些信息
    • 将 Susan 的名字与其识别码相关联 (以及她过去访问过的本站的所有页面)
    • 解释了 Amazon 和其他一些电子商务网站实现 “点击购物” (one-click shopping) 的道理
      • Susan 后继访问中选择购买某个物品，不用重新认证或输入相应个人信息了。

• cookie 可以用于标识一个用户。

  • 用户首次访问一个站点，需要提供一个用户标识 (可能是名字)
  • 后继会话中，浏览器向服务器传递一个 cookie 首部，从而向该服务器标识了用户。
  • cookie 可以在无状态的 HTTP 之上建立一个用户会话层。
    • 用户像一个基于 Web 的电子邮件系统注册时，浏览器向服务器发送 cooie 信息，允许该服务器在用户与应用程序会话的过程中标识该用户。

• 尽管 cookie 简便了例如网上购物的操作，但是这也是对用户隐私的一种侵害。

  • Web 站点能够通过 cookie 和 用户提供的账户信息得到用户私密信息并将其卖给第三方。

2.2.5 Web cache

• Web 缓存器 (Web cache) 也叫代理服务器 (proxy server)
  • 能够代表初始 Web 服务器来满足 HTTP 请求的网络实体。
  • Web 缓存器有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。

• 可以配置用户的浏览器，使得用户的所有 HTTP 请求首先指向 Web 缓存器。
• 一旦某浏览器被配置，每个对某对象的浏览器请求首先被定向到该 Web 缓存器。

  举例

  浏览器正在请求对象 http://www.someschool.edu/campus.gif

1. 浏览器创建一个到 Web 缓存器的 TCP 连接，并向 Web 缓存器中的对象发送一个 HTTP 请求
2. Web 缓存器进行检查，看看本地是否存储了该对象副本。
   1. 若有，Web 缓存器就向客户浏览器用 HTTP 相应报文返回该对象。
   2. 若没有，Web 缓存器就打开一个与该对象的初始服务器(www.someschool.edu) 的 TCP 连接。
      • Web 缓存器在这个缓存器到服务器的 TCP 连接上发送一个对该对象的 HTTP 请求。
      • 在收到该请求后，初始服务器向该 Web 缓存器发送具有该对象的 HTTP 相应。
3. 当 Web 缓存器接收到该对象时，它在本地存储空间存储一份副本，并向客户的浏览器用 HTTP 相应报文发送该副本 (通过现有的客户浏览器和 Web 缓存器之间的 TCP 连接)

• Web 缓存器既是服务器又是客户。
  • 接收浏览器的请求并发回相应时，它是一个服务器。
  • 当它向初始服务器发出请求并接收响应时，它是一个客户。
• Web 缓存器通常由 ISP 购买并安装。
  • 安装的浏览器会指向这些缓存器。
• 在因特网上部署 Web 缓存器的原因
  1. Web 缓存器可以大大减少对客户请求的响应时间
     • 特别是客户与初始服务器之间的瓶颈带宽远低于客户与 Web 缓存器之间的瓶颈带宽
  2. Web 缓存器能够大大减少一个机构的接入链路到因特网的通信量。
     • 通过减少通信量，机构不必急于增加带宽，减少了费用支出。
  3. Web 缓存器能够从整体上减低因特网上的 Web 流量，从而改善了所有应用的性能。

举例：理解缓存器

• 两个网络，机构 (内部) 网络和公共因特网的一部分。
  • 机构网络是一个高速的局域网
    • 机构网络上的一台路由器与因特网上的一台路由器通过一条 15 Mbps 的链路连接
• 初始服务器与因特网相连但位于全国各地
• 对象的平均长度为 1 Mb
• 从机构内的浏览器对这些初始服务器的平均访问速率为每秒 15 个请求。
• 假设 HTTP 请求报文极小，不会在网络及链路 (从机构内部路由器到因特网路由器) 上产生通信量。

• 假设从因特网接入链路一侧的路由器转发 HTTP 请求报文 (在一个 IP 数据报中) 开始，到它收到其响应报文 (通常在多个 IP 数据报中) 为止的时间平均为 2 秒。(非正式地称为因特网时延)

• 总地响应时间 (从浏览器请求一个对象到接收到该对象为止地时间) = 局域网时延 + 接入时延 (两台路由器之间地时延) + 因特网时延

• 局域网上的流量强度 = 15 请求/s * 1 Mb/请求 / 100 Mbps = 0.15
• 接入链路上的流量强度 = 15 请求/s * 1 Mb/请求 / 15 Mbps = 1
• 局域网上的强度 0.15 的通信量通常最多导致数十毫秒的时延，因此可以忽略局域网时延。
• 如果流量强度接近 1，链路上的时延会变得非常大并且无限增长。
  • 满足请求的平均响应时间将在分钟量级上
  • 必须想办法改进时间响应特性

解决方案

1. 增加链路的速率 (升级链路带宽)

   • 15 Mbps 升级到 100 Mbps
   • 这样就将接入链路上的流量强度减少到 0.15
   • 两台路由器之间的链路时延也可以忽略了。
   • 总相应时间大约 2 秒，即因特网时延。
   • 增加大量成本，代价很高。

2. 在机构网络中安装一个 Web 缓存器

• 实践中的命中率 (由一个缓存器所满足的请求的比率) 通常在 0.2 ~ 0.7 之间。
• 假设本次机构的缓存命中率为 0.4
• 客户和缓存连接在同一个高速的局域网上，40% 的请求立即由缓存器得到响应，时延约 10 ms 以内
• 剩下 60% 的请求仍然要由初始服务器来满足
  • 接入链路上的流量强度从 1.0 减小到 0.6
  • 一般而言，15 Mbps 的链路上，流量强度小于 0.8 对应的时延较小，约几十毫秒
• 平均时延 = 0.4 0.010 + 0.6 2.01 > 1.2
• 第二种解决方案提供的响应时延甚至比第一种更低，也不需要升级机构到因特网的链路。
  • 成本低
  • 很多缓存器使用了运行在廉价 PC 上的公共域软件
• Web 缓存器使用内容分发器 (Content Distribution Network, CDN)
  • CDN 公司在因特网上安装了许多地理上分散的缓存器，使大量流量实现了本地化。

2.2.6

条件 Get 方法

• 高速缓存能够减少用户感受到响应的时间
• 但是存放在缓存器中的对象副本可能是老旧的。
  • 保存在服务器上的对象自该副本缓存在客户端上后可能已经被修改。
• HTTP 协议由一种机制即条件 GET (conditional GET) 方法，允许缓存器证实它的对象是最新的。
  1. 请求报文使用 GET 方法
  2. 请求报文中包含一个 “If-Modified-Since: “ 首部行

举例：条件 GET 方法的操作方式

• 一个代理缓存器 (proxy cache) 代表一个请求浏览器向某 Web 服务器发送一个请求报文

• 该服务器向缓存器发送具有被请求的对象的响应报文

• 该缓存器将对象转发到请求的浏览器的同时，也在本地缓存了该对象。
• 缓存器在存储该对象时也存储了最后修改日期。
• 一段时间后，另一个用户经过该缓存器请求同一个对象
  • 原对象仍然存储在这个缓存器中
  • 可能位于 Web 服务器上的该对象已经被修改
• 该缓存器通过发送一个条件 GET 执行最新检查

• If-Modified-Since: 首部行的值等于之前服务器发送的响应报文中的 Last-Modified: 首部行的值。
  • 该条件 GET 报文高速服务器，仅当自指定日期之后该对象被修改过才发送对象。
  • 若没有被修改，Web 服务器向缓存器发送一个响应报文

• 作为对该条件的 GET 方法的响应，该 Web 服务器仍发送一个响应报文
  • 里面并没有包含该响应报文中包含所请求的对象
  • 包含对象会浪费带宽，并增加响应时间
  • 状态行中的 304 Not Modified 告诉缓存器 Web 服务器中的对象并没有被修改，可以直接使用缓存器中的对象副本传回发送对象请求的浏览器