《计算机网络：自顶向下方法（原书第6版）》一2.2　Web和HTTP

本节书摘来华章计算机《计算机网络：自顶向下方法（原书第6版）》一书中的第2章 ，第2.2节，（美）James F.Kurose Keith W.Ross　著 陈　鸣　译 更多章节内容可以访问云栖社区“华章计算机”公众号查看。

2.2　Web和HTTP

20世纪90年代以前，因特网的主要使用者还是研究人员、学者和大学生，他们登录远程主机，在本地主机和远程主机之间传输文件，收发新闻，收发电子邮件。尽管这些应用非常有用（并且继续如此），但是因特网基本上不为学术界和研究界之外所知。到了20世纪90年代初期，一个主要的新型应用即万维网（World Wide Web）登上了舞台［Berners-Lee 1994］。Web是一个引起公众注意的因特网应用，它极大地改变了人们与工作环境内外交流的方式。它将因特网从只是很多数据网之一的地位提升为仅有的一个数据网。
也许对大多数用户来说，最具有吸引力的就是Web的按需操作。当用户需要时，就能得到所想要的内容。这不同于无线电广播和电视，迫使用户只能收听、收看内容提供者提供的节目。除了可以按需操作以外，Web还有很多让人们喜欢和珍爱的特性。任何人使信息在Web上可用都非常简单，即只需要极低的费用就能成为出版人。超链接和搜索引擎帮助我们在Web站点的海洋里导航。图形化的界面刺激着我们的感官。表单、Java小程序和很多其他的装置，使我们可以与Web页面和站点进行交互。并且Web为许多在2003年以后出现的招人喜爱的应用提供了平台，这些应用包括YouTube、Gmail和Face book(脸谱)。

2.2.1　HTTP概况

Web的应用层协议是超文本传输协议（HyperText Transfer Protocol,HTTP），它是Web的核心，在［RFC 1945］和［RFC 2616］中进行了定义。HTTP由两个程序实现：一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中，通过交换HTTP报文进行会话。HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。在详细解释HTTP之前，应当回顾某些Web术语。
Web页面（Web page）（也叫文档）是由对象组成的。一个对象（object）只是一个文件，诸如一个HTML文件、一个JPEG图形、一个Java小程序或一个视频片段这样的文件，且它们可通过一个URL地址寻址。多数Web页面含有一个HTML基本文件（base HTML file）以及几个引用对象。例如，如果一个Web页面包含HTML文本和5个JPEG图形，那么这个Web页面有6个对象：一个HTML基本文件加5个图形。HTML基本文件通过对象的URL地址引用页面中的其他对象。每个URL地址由两部分组成：存放对象的服务器主机名和对象的路径名。例如，URL地址http://www.someSchool.edu/someDepartment/picture.gif，其中的www.someSchool.edu就是主机名，/someDepartment/picture.gif就是路径名。因为Web浏览器（Web browser）（例如Internet Explorer和Firefox）实现了HTTP的客户端，所以在Web环境中我们经常交替使用“浏览器”和“客户”这两个术语。Web服务器（Web server）实现了HTTP的服务器端，它用于存储Web对象，每个对象由URL寻址。流行的Web服务器有Apache和Microsoft Internet Information Server（微软互联网信息服务器）。

HTTP定义了Web客户向Web服务器请求Web页面的方式，以及服务器向客户传送Web页面的方式。我们稍后详细讨论客户和服务器的交互过程，而其基本思想在图2-6中进行了图示。当用户请求一个Web页面（如点击一个超链接）时，浏览器向服务器发出对该页面中所包含对象的HTTP请求报文，服务器接收到请求并用包含这些对象的HTTP响应报文进行响应。
HTTP使用TCP作为它的支撑运输协议（而不是在UDP上运行）。HTTP客户首先发起一个与服务器的TCP连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问TCP。如同在2.1节中描述的那样，客户端的套接字接口是客户进程与TCP连接之间的门，在服务器端的套接字接口则是服务器进程与TCP连接之间的门。客户向它的套接字接口发送HTTP请求报文并从它的套接字接口接收HTTP响应报文。类似地，服务器从它的套接字接口接收HTTP请求报文和向它的套接字接口发送HTTP响应报文。一旦客户向它的套接字接口发送了一个请求报文，该报文就脱离了客户控制并进入TCP的控制。2.1节讲过，TCP为HTTP提供可靠数据传输服务。这意味着，一个客户进程发出的每个HTTP请求报文最终能完整地到达服务器；类似地，服务器进程发出的每个HTTP响应报文最终能完整地到达客户。这里我们看到了分层体系结构最大的优点，即HTTP协议不用担心数据丢失，也不关注TCP从网络的数据丢失和乱序故障中恢复的细节。那是TCP以及协议栈较低层协议的工作。
注意到下列现象很重要：服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。假如某个特定的客户在短短的几秒钟内两次请求同一个对象，服务器并不会因为刚刚为该客户提供了该对象就不再做出反应，而是重新发送该对象，就像服务器已经完全忘记不久之前所做过的事一样。因为HTTP服务器并不保存关于客户的任何信息，所以我们说HTTP是一个无状态协议（stateless protocol）。我们同时也注意到Web使用了客户-服务器应用程序体系结构（如2.1节所述）。Web服务器总是打开的，具有一个固定的IP地址，且它服务于可能来自数以百万计的不同浏览器的请求。

2.2.2　非持续连接和持续连接

在许多因特网应用程序中，客户和服务器在一个相当长的时间范围内通信，其中客户发出一系列请求并且服务器对每个请求进行响应。依据应用程序以及该应用程序的使用方式，这一系列请求可以以规则的间隔周期性地或者间断性地一个接一个发出。当这种客户-服务器的交互是经TCP进行的，应用程序的研制者就需要做一个重要决定，即每个请求/响应对是经一个单独的TCP连接发送，还是所有的请求及其响应经相同的TCP连接发送呢？采用前一种方法，该应用程序被称为使用非持续连接（non-persistent connection）；采用后一种方法，该应用程序被称为使用持续连接（persistent connection）。为了深入地理解该设计问题，我们研究在特定的应用程序即HTTP的情况下持续连接的优点和缺点，HTTP既能够使用非持续连接，也能够使用持续连接。尽管HTTP在其默认方式下使用持续连接，HTTP客户和服务器也能配置成使用非持续连接。
1.采用非持续连接的HTTP
我们看看在非持续连接情况下，从服务器向客户传送一个Web页面的步骤。假设该页面含有一个HTML基本文件和10个JPEG图形，并且这11个对象位于同一台服务器上。该HTML文件的URL为：http://www.someSchool.edu/someDepartment/home.index。
我们看看发生了什么情况：

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

当浏览器收到Web页面后，显示给用户。两个不同的浏览器也许会以不同的方式解释（即向用户显示）该页面。HTTP与客户如何解释一个Web页面毫无关系。HTTP规范（［RFC 1945］和［RFC 2616］）仅定义了在HTTP客户程序与HTTP服务器程序之间的通信协议。
上面的步骤举例说明了非持续连接的使用，其中每个TCP连接在服务器发送一个对象后关闭，即该连接并不为其他的对象而持续下来。值得注意的是每个TCP连接只传输一个请求报文和一个响应报文。因此在本例中，当用户请求该Web页面时，要产生11个TCP连接。
在上面描述的步骤中，我们有意没有明确客户获得这10个JPEG图形对象是使用10个串行的TCP连接，还是某些JPEG对象使用了一些并行的TCP连接。事实上，用户能够配置现代浏览器以控制并行度。在默认方式下，大部分浏览器打开5～10个并行的TCP连接，而每条连接处理一个请求响应事务。如果用户愿意，最大并行连接数可以设置为1，这样10条连接就会串行建立。我们在下一章会看到，使用并行连接可以缩短响应时间。
在继续讨论之前，我们来简单估算一下从客户请求HTML基本文件起到该客户收到整个文件止所花费的时间。为此，我们给出往返时间（Round-Trip Time，RTT）的定义，该时间是指一个短分组从客户到服务器然后再返回客户所花费的时间。RTT包括分组传播时延、分组在中间路由器和交换机上的排队时延以及分组处理时延（这些在1.4节已经讨论过）。现在考虑当用户点击超链接时会发生什么现象。如图2-7所示，这引起浏览器在它和Web服务器之间发起一个TCP连接；这涉及一次“三次握手”过程，即客户向服务器发送一个小TCP报文段，服务器用一个小TCP报文段做出确认和响应，最后，客户向服务器返回确认。三次握手中前两个部分所耗费的时间占用了一个RTT。完成了三次握手的前两个部分后，客户结合三次握手的第三部分（确认）向该TCP连接发送一个HTTP请求报文。一旦该请求报文到达服务器，服务器就在该TCP连接上发送HTML文件。该HTTP请求/响应用去了另一个RTT。因此，粗略地讲，总的响应时间就是两个RTT加上服务器传输HTML文件的时间。

2.采用持续连接的HTTP
非持续连接有一些缺点。首先，必须为每一个请求的对象建立和维护一个全新的连接。对于每个这样的连接，在客户和服务器中都要分配TCP的缓冲区和保持TCP变量，这给Web服务器带来了严重的负担，因为一台Web服务器可能同时服务于数以百计不同的客户的请求。第二，就像我们刚描述的那样，每一个对象经受两倍RTT的交付时延，即一个RTT用于创建TCP，另一个RTT用于请求和接收一个对象。
在采用持续连接的情况下，服务器在发送响应后保持该TCP连接打开。在相同的客户与服务器之间的后续请求和响应报文能够通过相同的连接进行传送。特别是，一个完整的Web页面（上例中的HTML基本文件加上10个图形）可以用单个持续TCP连接进行传送。更有甚者，位于同一台服务器的多个Web页面在从该服务器发送给同一个客户时，可以在单个持续TCP连接上进行。可以一个接一个地发出对对象的这些请求，而不必等待对未决请求（流水线）的回答。一般来说，如果一条连接经过一定时间间隔（一个可配置的超时间隔）仍未被使用，HTTP服务器就关闭该连接。HTTP的默认模式是使用带流水线的持续连接。我们把量化比较持续连接和非持续连接性能的任务留作第2、3章的课后习题。鼓励读者阅读文献［Heidemann 1997；Nielsen 1997］。

2.2.3　HTTP报文格式

HTTP规范［RFC 1945；RFC 2616］包含了对HTTP报文格式的定义。HTTP报文有两种：请求报文和响应报文。下面讨论这两种报文。
1.HTTP请求报文
下面提供了一个典型的HTTP请求报文：

通过仔细观察这个简单的请求报文，我们就能知道很多东西。首先，我们看到该报文是用普通的ASCII文本书写的，这样有一定计算机知识的人都能够阅读它。其次，我们看到该报文由5行组成，每行由一个回车和换行符结束。最后一行后再附加一个回车换行符。虽然这个特定的报文仅有5行，但一个请求报文能够具有更多的行或者至少为一行。HTTP请求报文的第一行叫做请求行（request line），其后继的行叫做首部行（header line）。请求行有3个字段：方法字段、URL字段和HTTP版本字段。方法字段可以取几种不同的值，包括GET、POST、HEAD、PUT和DELETE。绝大部分的HTTP请求报文使用GET方法。当浏览器请求一个对象时，使用GET方法，在URL字段带有请求对象的标识。在本例中，该浏览器正在请求对象/somedir/page.html。其版本字段是自解释的；在本例中，浏览器实现的是HTTP/1.1版本。
现在我们看看本例的首部行。首部行Host:www.someschool.edu指明了对象所在的主机。你也许认为该首部行是不必要的，因为在该主机中已经有一条TCP连接存在了。但是，如我们将在2.2.5节中所见，该首部行提供的信息是Web代理高速缓存所要求的。通过包含Connection:close首部行，该浏览器告诉服务器不希望麻烦地使用持续连接，它要求服务器在发送完被请求的对象后就关闭这条连接。User-agent:首部行用来指明用户代理，即向服务器发送请求的浏览器的类型。这里浏览器类型是Mozilla/5.0，即Firefox浏览器。这个首部行是有用的，因为服务器可以有效地为不同类型的用户代理实际发送相同对象的不同版本。（每个版本都由相同的URL寻址。）最后，Accept-language:首部行表示用户想得到该对象的法语版本（如果服务器中有这样的对象的话）；否则，服务器应当发送它的默认版本。Accept-language:首部行仅是HTTP中可用的众多内容协商首部之一。
看过一个例子之后，我们再来看看如图2-8所示的一个请求报文的通用格式。我们看到该通用格式与我们前面的例子密切对应。然而，你可能已经注意到了在首部行（和附加的回车和换行）后有一个“实体体”（entity body）。使用GET方法时实体体为空，而使用POST方法时才使用该实体体。当用户提交表单时，HTTP客户常常使用POST方法，例如当用户向搜索引擎提供搜索关键词时。使用POST报文时，用户仍可以向服务器请求一个Web页面，但Web页面的特定内容依赖于用户在表单字段中输入的内容。如果方法字段的值为POST时，则实体体中包含的就是用户在表单字段中的输入值。

当然，如果不提“用表单生成的请求报文不是必须使用POST方法”这一点，那将是失职。HTML表单经常使用GET方法，并在（表单字段中）所请求的URL中包括输入的数据。例如，一个表单使用GET方法，它有两个字段，分别填写的是“monkeys”和“bananas”，这样，该URL结构为www.somesite.com/animalsearch?monkeys&bananas。在日复一日的网上冲浪中，你也许已经留意到了这种扩展的URL。
HEAD方法类似于GET方法。当服务器收到使用HEAD方法的请求时，将会用一个HTTP报文进行响应，但是并不返回请求对象。应用程序开发者常用HEAD方法进行调试跟踪。PUT方法常与Web发行工具联合使用，它允许用户上传对象到指定的Web服务器上指定的路径（目录）。PUT方法也被那些需要向Web服务器上传对象的应用程序使用。DELETE方法允许用户或者应用程序删除Web服务器上的对象。
2.HTTP响应报文
下面我们提供了一条典型的HTTP响应报文。该响应报文可以是对刚刚讨论的例子中请求报文的响应。

我们仔细看一下这个响应报文。它有三个部分：一个初始状态行（status line），6个首部行（header line），然后是实体体（entity body）。实体体部分是报文的主要部分，即它包含了所请求的对象本身（表示为data data data data…）。状态行有3个字段：协议版本字段、状态码和相应状态信息。在这个例子中，状态行指示服务器正在使用HTTP/1.1，并且一切正常（即服务器已经找到并正在发送所请求的对象）。
我们现在来看看首部行。服务器用Connection: close首部行告诉客户，发送完报文后将关闭该TCP连接。Date:首部行指示服务器产生并发送该响应报文的日期和时间。值得一提的是，这个时间不是指对象创建或者最后修改的时间；而是服务器从它的文件系统中检索到该对象，插入到响应报文，并发送该响应报文的时间。Server:首部行指示该报文是由一台Apache Web服务器产生的，它类似于HTTP请求报文中的User-agent:首部行。Last-Modified:首部行指示了对象创建或者最后修改的日期和时间。Last-Modified:首部行对既可能在本地客户也可能在网络缓存服务器上的对象缓存来说非常重要。我们将很快详细地讨论缓存服务器（也叫代理服务器）。Content-Length:首部行指示了被发送对象中的字节数。Content-Type:首部行指示了实体体中的对象是HTML文本。（该对象类型应该正式地由Content-Type:首部行而不是用文件扩展名来指示。）

看过一个例子后，我们再来查看响应报文的通用格式（如图2-9所示）。该通用格式能够与前面例子中的响应报文对应起来。我们补充说明一下状态码和它们对应的短语。状态码及其相应的短语指示了请求的结果。一些常见的状态码和相关的短语包括：

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

你想看一下真实的HTTP响应报文吗？这正是我们高度推荐的事，而且也很容易做到。首先用Telnet登录到你喜欢的Web服务器上，接下来输入一个只有一行的请求报文去请求放在该服务器上的某些对象。例如，假设你看到命令提示，键入：

（在输入最后一行后连续按两次回车。）这就打开一个到主机cis.poly.edu的80端口的TCP连接，并发送一个HTTP请求报文。你将会看到一个携带包括Ross教授主页的HTML基本文件的响应报文。如果你只是想看一下HTTP协议的报文行，而不是获取对象本身的话，那么可以用HEAD代替GET。最后，用/~banana/代替/~ross/，看看你得到什么类型的响应报文。
在本节中，我们讨论了HTTP请求报文和响应报文中的一些首部行。HTTP规范中定义了很多可以被浏览器、Web服务器和Web缓存服务器插入的首部行。我们只提到了全部首部行中的少数几个，在2.2.5节中我们讨论网络Web缓存时还会涉及其他几个。一本可读性很强的文献是［Krishnamurty 2001］，它对HTTP协议（包括它的首部行和状态码）进行了广泛讨论。
浏览器是如何决定在一个请求报文中包含哪些首部行的呢？Web服务器又是如何决定在一个响应报文中包含哪些首部行呢？浏览器产生的首部行与很多因素有关，包括浏览器的类型和协议版本（例如，HTTP/1.0浏览器将不会产生任何1.1版本的首部行）、浏览器的用户配置（如喜好的语言）、浏览器当前是否有一个缓存的但是可能超期的对象版本。Web服务器的表现也类似：在产品、版本和配置上都有差异，所有这些都会影响响应报文中包含的首部行。

2.2.4　用户与服务器的交互：cookie

我们前面提到了HTTP服务器是无状态的。这简化了服务器的设计，并且允许工程师们去开发可以同时处理数以千计的TCP连接的高性能Web服务器。然而一个Web站点通常希望能够识别用户，可能是因为服务器希望限制用户的访问，或者因为它希望把内容与用户身份联系起来。为此，HTTP使用了cookie。cookie在［RFC 6265］中定义，它允许站点对用户进行跟踪。目前大多数商务Web站点都使用了cookie。
如图2-10所示，cookie技术有4个组件：①在HTTP响应报文中的一个cookie首部行；②在HTTP请求报文中的一个cookie首部行；③在用户端系统中保留有一个cookie文件，并由用户的浏览器进行管理；④位于Web站点的一个后端数据库。使用图2-10，我们通过一个典型的例子看看cookie的工作过程。假设Susan总是从家中PC使用Internet Explorer上网，她首次与Amazon.com联系。我们假定过去她已经访问过eBay站点。当请求报文到达该Amazon Web服务器时，该Web站点将产生一个唯一识别码，并以此作为索引在它的后端数据库中产生一个表项。接下来Amazon Web服务器用一个包含Set-cookie:首部的HTTP响应报文对Susan的浏览器进行响应，其中Set-cookie:首部含有该识别码。例如，该首部行可能是

当Susan的浏览器收到了该HTTP响应报文时，它会看到该Set-cookie:首部。该浏览器在它管理的特定cookie文件中添加一行，该行包含服务器的主机名和在Set-cookie:首部中的识别码。值得注意的是该cookie文件已经有了用于eBay的表项，因为Susan过去访问过该站点。当Susan继续浏览Amazon网站时，每请求一个Web页面，其浏览器就会从该cookie文件中获取她对这个网站的识别码，并放到HTTP请求报文中包括识别码的cookie首部行中。特别是，发往该Amazon服务器的每个HTTP请求报文都包括以下首部行：

在这种方式下，Amazon服务器可以跟踪Susan在Amazon站点的活动。尽管Amazon Web站点不必知道Susan的名字，但它确切地知道用户1678按照什么顺序、在什么时间、访问了哪些页面！Amazon使用cookie来提供它的购物车服务，即Amazon能够维护Susan希望购买的物品列表，这样在Susan结束会话时可以一起为它们付费。
如果Susan再次访问Amazon站点，比如说一个星期后，她的浏览器会在其请求报文中继续放入首部行cookie:1678。Amazon将根据Susan过去在Amazon访问的网页向她推荐产品。如果Susan也在Amazon注册过，即提供了她的全名、电子邮件地址、邮政地址和信用卡账号，则Amazon能在其数据库中包括这些信息，将她的全名与识别码相关联（以及她在过去访问过的所有页面）。这就解释了Amazon和其他一些电子商务网站实现“点击购物”（one-click shopping）的道理，即当Susan在后继的访问中选择购买某个物品时，她不必重新输入姓名、信用卡账号或者地址等信息了。
从上述讨论中我们看到，cookie可以用于标识一个用户。用户首次访问一个站点时，可能需要提供一个用户标识（可能是名字）。在后继会话中，浏览器向服务器传递一个cookie首部，从而向该服务器标识了用户。因此cookie可以在无状态的HTTP之上建立一个用户会话层。例如，当用户向一个基于Web的电子邮件系统（如Hotmail）注册时，浏览器向服务器发送cookie信息，允许该服务器在用户与应用程序会话的过程中标识该用户。
尽管cookie常常能简化用户的因特网购物活动，但是它的使用仍具有争议，因为它们被认为是对用户隐私的一种侵害。如我们刚才所见，结合cookie和用户提供的账户信息，Web站点可以知道许多有关用户的信息，并可能将这些信息卖给第三方。Cookie Central ［Cookie Central 2012］包括了对cookie争论的广泛信息。

2.2.5　Web缓存

Web缓存器（Web cache）也叫代理服务器（proxy server），它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。如图2-11所示，可以配置用户的浏览器，使得用户的所有HTTP请求首先指向Web缓存器。一旦某浏览器被配置，每个对某对象的浏览器请求首先被定向到该Web缓存器。举例来说，假设浏览器正在请求对象http://www.someschool.edu/campus.gif，将会发生如下情况：

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

值得注意的是Web缓存器是服务器同时又是客户。当它接收浏览器的请求并发回响应时，它是一个服务器。当它向初始服务器发出请求并接收响应时，它是一个客户。
Web缓存器通常由ISP购买并安装。例如，一所大学可能在它的校园网上安装一台缓存器，并且将所有校园网上的用户浏览器配置为指向它。或者，一个主要的住宅ISP（例如AOL）可能在它的网络上安装一台或多台Web缓存器，并且预先配置其配套的浏览器指向这些缓存器。
在因特网上部署Web缓存器有两个原因。首先，Web缓存器可以大大减少对客户请求的响应时间，特别是当客户与初始服务器之间的瓶颈带宽远低于客户与Web缓存器之间的瓶颈带宽时更是如此。如果在客户与Web缓存器之间有一个高速连接（情况常常如此），并且如果用户所请求的对象在Web缓存器上，则Web缓存器可以迅速将该对象交付给用户。其次，如我们马上用例子说明的那样，Web缓存器能够大大减少一个机构的接入链路到因特网的通信量。通过减少通信量，该机构（如一家公司或者一所大学）就不必急于增加带宽，因此降低了费用。此外，Web缓存器能从整体上大大减低因特网上的Web流量，从而改善了所有应用的性能。

　图2-12　一个机构网络与因特网之间的瓶颈为了深入理解缓存器带来的好处，我们考虑在图2-12场景下的一个例子。该图显示了两个网络，即机构（内部）网络和公共因特网的一部分。机构网络是一个高速的局域网，它的一台路由器与因特网上的一台路由器通过一条15Mbps的链路连接。这些初始服务器与因特网相连但位于全世界各地。假设对象的平均长度为1Mb，从机构内的浏览器对这些初始服务器的平均访问速率为每秒15个请求。假设HTTP请求报文小到可以忽略，因而不会在网络中以及接入链路（从机构内部路由器到因特网路由器）上产生什么通信量。我们还假设在图2-12中从因特网接入链路一侧的路由器转发HTTP请求报文（在一个IP数据报中）开始，到它收到其响应报文（通常在多个IP数据报中）为止的时间平均为2秒。我们非正式地将该持续时延称为“因特网时延”。
总的响应时间，即从浏览器请求一个对象到接收到该对象为止的时间，是局域网时延、接入时延（即两台路由器之间的时延）和因特网时延之和。我们来粗略地估算一下这个时延。局域网上的流量强度（参见1.4.2节）为
（15个请求/s）×（1Mb/请求）/（100Mbps）=0.15
然而接入链路上的流量强度（从因特网路由器到机构路由器）为
（15个请求/s）×（1Mb/请求）/（15Mbps）=1
局域网上强度为0.15的通信量最多导致数十毫秒的时延，因此我们可以忽略局域网时延。然而，如在1.4.2节讨论的那样，如果流量强度接近1（就像在图2-12中接入链路的情况那样），链路上的时延会变得非常大并且无限增长。因此，满足请求的平均响应时间将在分钟的量级上。显然，必须想办法来改进时间响应特性。
一个可能的解决办法就是增加接入链路的速率，如从15Mbps增加到100Mbps。这可以将接入链路上的流量强度减少到0.15，这样一来，两台路由器之间的链路时延也可以忽略了。这时，总的响应时间将大约为2秒钟，即为因特网时延。但这种解决方案也意味着该机构必须将它的接入链路由15Mbps升级为100Mbps，这是一种代价很高的方案。
现在来考虑另一种解决方案，即不升级链路带宽而是在机构网络中安装一个Web缓存器。这种解决方案如图2-13所示。实践中的命中率（即由一个缓存器所满足的请求的比率）通常在0.2～0.7之间。为了便于阐述，我们假设该机构的缓存命中率为0.4。因为客户和缓存连接在一个相同的高速局域网上，这样40%的请求将几乎立即会由缓存器得到响应，时延约在10ms以内。然而，剩下的60%的请求仍然要由初始服务器来满足。但是只有60%的被请求对象通过接入链路，在接入链路上的流量强度从1.0减小到0.6。一般而言，在15Mbps链路上，当流量强度小于0.8时对应的时延较小，约为几十毫秒。这个时延与2秒因特网时延相比是微不足道的。考虑这些之后，平均时延因此为0.4×（0.010秒）+0.6×（2.01秒）　图2-13　为机构网络添加一台缓存器这略大于1.2秒。因此，第二种解决方案提供的响应时延甚至比第一种解决方案更低，也不需要该机构升级它到因特网的链路。该机构理所当然地要购买和安装Web缓存器。除此之外其成本较低，很多缓存器使用了运行在廉价PC上的公共域软件。
通过使用内容分发网络（Content Distribution Network，CDN），Web缓存器正在因特网中发挥着越来越重要的作用。CDN公司在因特网上安装了许多地理上分散的缓存器，因而使大量流量实现了本地化。有多个共享的CDN（例如Akamai和Limelight）和专用的CDN（例如谷歌和微软）。我们将在第7章中更为详细地讨论CDN。

2.2.6　条件GET方法

尽管高速缓存能减少用户感受到的响应时间，但也引入了一个新的问题，即存放在缓存器中的对象副本可能是陈旧的。换句话说，保存在服务器中的对象自该副本缓存在客户上以后可能已经被修改了。幸运的是，HTTP协议有一种机制，允许缓存器证实它的对象是最新的。这种机制就是条件GET（conditional GET）方法。如果：①请求报文使用GET方法；并且②请求报文中包含一个“If-Modified-Since:”首部行。那么，这个HTTP请求报文就是一个条件GET请求报文。
为了说明GET方法的操作方式，我们看一个例子。首先，一个代理缓存器（proxy cache）代表一个请求浏览器，向某Web服务器发送一个请求报文：

其次，该Web服务器向缓存器发送具有被请求的对象的响应报文：

该缓存器在将对象转发到请求的浏览器的同时，也在本地缓存了该对象。重要的是，缓存器在存储该对象时也存储了最后修改日期。第三，一个星期后，另一个用户经过该缓存器请求同一个对象，该对象仍在这个缓存器中。由于在过去的一个星期中位于Web服务器上的该对象可能已经被修改了，该缓存器通过发送一个条件GET执行最新检查。具体说来，该缓存器发送：

值得注意的是If-Modified-Since:首部行的值正好等于一星期前服务器发送的响应报文中的Last-Modified:首部行的值。该条件GET报文告诉服务器，仅当自指定日期之后该对象被修改过，才发送该对象。假设该对象自2011年9月7日09:23:24后没有被修改。接下来的第四步，Web服务器向该缓存器发送一个响应报文：

我们看到，作为对该条件GET方法的响应，该Web服务器仍发送一个响应报文，但并没有在该响应报文中包含所请求的对象。包含该对象只会浪费带宽，并增加用户感受到的响应时间，特别是如果该对象很大的时候更是如此。值得注意的是在最后的响应报文中，状态行中为304 Not Modified，它告诉缓存器可以使用该对象，能向请求的浏览器转发它（该代理缓存器）缓存的该对象副本。
我们现在完成了对HTTP的讨论，这是我们详细学习的第一个因特网协议（应用层协议）。我们已经学习了HTTP报文的格式，学习了当发送和接收这些报文时Web客户和服务器所采取的动作。我们还学习了一点Web应用程序基础设施，包括缓存、cookie和后端数据库，所有这些都以某种方式与HTTP协议有关。