46、万维网之一（应用层）

引言

• Web 是万维网（ World Wide Web ）的俗称，它是一个体系结构框架。该框架把分布在整个Internet 数百万台机器上的内容链接起来供人们访问。Web 刚出现时在瑞士被科研人员用来相互之间协同设计高能物理实验，仅十年间它就演变成今天被数百万人认为的“ Internet ”应用。Web 诞生于1989 年的欧洲原子能研究中心CERN。最初的想法是帮助大型研究组成员通过修改报告、计划、绘图、照片和其他文档的方式来进行合作，这些文档由粒子物理实验产生，并且研究组的成员通常分散在好几个国家或好几个时区。将文档链接成Web 的提议由CERN 物理学家Tim Berners-Lee 提出， 18 个月后第一个（基于文本的）原型系统投入运行。该系统的公开文档发表在Hypertext’ 91 会议，它立即引起了另一个研究组的注意，该研究组由伊利诺伊大学的Marc Andreessen 领导，他最终开发了第一个图形浏览器。这就是Mosaic 浏览器，正式发布于1993.2。正如他们所说的，其余的现在己经成为历史。Mosaic 是如此的受欢迎，一年后Andreessen 离开学校组建了网景通信公司，公司目标是开发Web 软件。接下来的3 年，网景的Netscape Navigator 和微软的IE 浏览器进入了一场浏览器大战，每一个都试图捕捉这个新兴市场的更大份额，为此疯狂地加入比对手更多的功能（而且导致了更多的错误〉。
• 从20 世纪90 年代到本世纪初，网站和网页（称为Web 内容〉成指数倍地增长，直到达到具有数百万计网站和数十亿网页的规模。这些网站中的一小部分盛极一时，网站和它们背后的公司主要定义了Web，正如今天人们所体验的那样。这些公司包括书店（亚马逊于1994 年成立，市值500 亿美元〉、跳蚤市场（易趣， 1995 成立，市值300 亿美元）、搜索（谷歌， 1998 成立，市值150 亿美元〉和社会网络( Facebook, 2004 成立，私人公司，价值超过150 亿美元〉。到2000 年期间，许多Web 公司一夜之间晋升数百万美元身价，当最后表明原来一切都只是炒作时，几乎接近破产。这一切甚至还有一个特殊名称，即所谓的点com 时代（ dot com era ）。新的想法仍然丰富着Web 世界。许多新想法来自年轻的学生。例如，当Mark Zuckerberg 开始创建Facebook 时是哈佛大学的学生： Sergey Brin 和Larry Page 创建Google 时是斯坦福大学的学生。
• 1994 年， CERN 和MIT 签署了建立万维网联盟( W3C, World Wide Web Consortium)的协议。W3C 是一个组织，它致力于进一步开发Web 、对协议进行标准化，并鼓励站点之间实行互操作。Bemers-Lee 担任了联盟的主管。从那时起，己经有几百所大学和公司加入了该联盟。尽管现在关于Web 的书籍数不胜数，但获取关于Web 最新信息的最佳之处（很自然地〉还是在Web 本身。W3C 联盟的主页是 www.w3.org ，感兴趣的读者可以从那里找到涵盖该联盟所有文档和活动的页面链接。

1、体系结构概述

• 站在用户的角度看， Web 由大量分布在全球范围的内容组成，这些内容以Web 页面(Web page ）或简称为页面（ page ）的形式表示。每个页面可以包含指向其他页面的链接，这些页面可以分布在全球任何地方。用户单击一个链接就可以跟随这个链接来到它所指向的页面。这个过程可无限地重复下去。让一个页面指向另一个页面的想法现在称为超文本（ hypertext ），这种想法在1945 年由一个卓有远见的MIT 电子工程系教授Vannevar Bush 发明（ Bush, 1945 ），也就是说早在Internet 被发明出来之前就已经有了Web 。事实上，它在商业计算机之前就己经存在了，虽然几所大学生产出来的粗糙原型机能填满大型会议室，而且能力还不及一个现代化的袖珍计算器。
• 通常观看页面的程序称为浏览器（ browser ）。Firefox, Internet Explorer 和Chrome 是比较流行的浏览器。浏览器取回所请求的页面，对页面内容进行解释，并在屏幕上以恰当的格式显示出来。页面内容本身可能是文本、图像和格式化的命令混合体，表现的形式多种多样：可以表现成传统的文档形式，或者表现成其他内容的形式（比如视频〉，或者是一个能产生图形界面的程序，用户通过该界面实行与网页的交互方式。
• 页面的照片如图左边一般所示。这是华盛顿大学计算机科学与工程系的一个页面。这个页面显示了文本和图形元素（大多数内容太小无法阅读〉。页面中的某些部分与指向其他页面的链接有关。与另一个页面相关的一小段文字、一个图标、一个图像等都称为超链接( hyperlink ）。为了跟随一个链接，用户将鼠标光标放在页面区域的链接部分（这会使光标发生变化），然后单击链接。点击链接只是告诉浏览器去获取另一个页面的简单方式。在Web 初期，链接通过下划线和彩色文本来突出强调，以便使它们脱颖而出。如今， Web 页面的创作者己经有各种方法来控制链接区域的外表，因此一个链接可能会作为一个图标出现，或当鼠标滑过它时改变外观。正是页面的创造者使得链接在视觉上表现鲜明，从而提供了一个可用的接口。
• 系里的学生跟随一个链接到一个特别为他们而设计内容的页面，能学到更多东西。通过点击圈起来的区域就可以访问该链接。然后，浏览器抓取新的一页并显示出来，如图左下角所示的那部分。除了这个例子外，第一页还包含着指向数十个其他网页的链接。页面显示背后的基本工作模型如图所示。在这里，客户机器上的浏览器正在显示一个Web 页面。每一页的抓取都是通过发送一个请求到一个或多个服务器，服务器以页面的内容作为响应。抓取网页所用的“请求-响应”协议是一个简单的基于文本协议，它运行在TCP 之上，就像SMTP 一样。这个协议就是所谓的超文本传输协议（ HTTP, HyperText Transfer Protocol ）。内容可能只是一个磁盘读取的文档，或者是数据库查询和程序执行的结果。如果每次显示的是相同的一个文档，则称该网页为静态页面（ static page ）。相反，如果每次显示的是程序按需产生的内容，或者页面本身包含了一个程序，则称该网页为动态页面（dynamic page ）。
• 一个动态的页面每次显示时本身表现可能是不同的。例如，电子商店的首页可能对每个访问者显示的内容不尽相同。如果一个书店的顾客在过去买了一些推理小说，那么当这位顾客访问商店的主页后，可能会看到突出显示的新的惊悚小说，而另一位更喜欢烹饪的顾客可能首先映入眼帘的是新的烹饪书籍。网站如何跟踪哪位顾客喜欢什么我们马上就会说明。简单地说，其答案涉及一种Cookie。
• 在图中，浏览器接触三个服务器获取了两个页面，这三个服务器分别是edu.cs. washington 、youtube.com 和 google-analytics.com。来自这些不同服务器的内容集成在一起通过浏览器显示。显示细化了网页处理的范围，主要取决于什么样的内容。除了渲染文字和图形外，它可能还涉及播放一段视频，或者运行一个脚本把作为页面一部分的用户界面呈现出来。在这种情况下， cs.washington.edu 服务器提供了主网页， youtube.com 服务器提供了一段嵌入的视频，而 google-analytics.com 服务器没有提供任何用户可见的内容，但它追踪访问网站的用户。我们稍后将详细讨论跟踪器。

客户端

• 现在让我们来看图中Web 浏览器这边的详细情况。基本上，一个浏览器是一个程序，它可以显示Web 页面并且捕获鼠标在显示页面上点击的表项。当一个表项被击中时，浏览器就跟踪相应的超链并获取被选中的页面。当Web 最初被建立时，为了让一个页面指向另一个Web 页面，很显然需要某些机制来命名和定位页面。尤其是，在显示一个被选中的页面之前，首先必须回答3 个问题：
  (I ）这个页面叫什么？
  (2 ）这个页面在哪里？
  (3 ）如何访问这个页面？
• 如果每个页面都以某种方式被分配了一个唯一的名字，那么在标识页面时就不会存在任何歧义。但是，问题还没有解决。考虑把人与页面作个对比。在美国，几乎每个人都有一个社会保险号， 因为任何两个人都不可能拥有相同的社会保险号，因此社会保险号是一个具有唯一性的标识符。然而，如果你仅仅知道一个社会保险号，那么你是无法找到该保险号所有者的地址，当然你也无法知道到底应该用英语、西班牙语还是汉语来给他写信。Web 基本上也有同样的问题。
• web 选择的解决方案是用一种能同时解决上述3 个问题的方式来标识页面。每个页面被分配一个统一资源定位符（URL, Uniform Resource Locator），用来有效地充当该页面在全球范围内的名字。URL 包括3 个部分：协议（也称为方案（ scheme ））、页面所在机器的DNS 名字，以及唯一指向特定页面的路径〈通常是读取的一个文件或者运行在机器上的一个程序〉。一般情况下， 路径是一个模仿文件目录结构的层次名字。然而，如何解释路径是服务器的事，而且路径可能反映了实际的目录结构，也可能不反映实际的目录结构。
• 作为一个例子，图中显示的页面的URL 是：
  http : //www.cs.washington.edu/index.html
  这个URL 由3 部分组成：协议（http〉、主机的DNS 域名( www.cs.washington.edu)和路径名（ index.html) 。当用户点击一个超链，浏览器就执行一系列的步骤来获取该超链指向的网页。让我们跟踪点击例子中链接时所发生的步骤：
  (1 ）浏览器确定URL （ 通过观察选中的什么〉。
  (2 ）浏览器请求DNS查询服务器 www.cs.washington.edu 的IP 地址。
  (3 ) DNS 返回128.208.3.88 。
  (4 ）浏览器与128.208.3.88 机器的80 端口建立一个TCP 连接， 80 端口是HTTP 协议
  的知名端口。
  (5 ）浏览器发送HTTP 报文，请求／index.html 页面。
  (6 ) www.cs.washington.edu 服务器发回页面作为HTTP 响应，例如发送文件／index.html 。
  (7 ）如果该页面包括需要显示的URL，那么浏览器经过同样的处理过程获取其他URL 。在这种情况下， URL 包括多个取自www.cs.washington.edu 的内嵌图像、一个取自youtube.com 的内嵌视频和一个取自google-analytics.com 的脚本。
  (8 ）浏览器显示页面／index.html，如图所示。
  (9 ）如果短期内没有向同一个服务器发出其他请求，那么释放TCP 连接。
• 许多浏览器会在屏幕底部的状态栏中显示它们目前正在执行哪一步。这样，当性能较差时，用户可以看到是由于DNS 没有响应、服务器没有响应，或者干脆正在一个缓慢或拥塞的网络上传输页面。URL 设计是开放式的，在某种意义上它很简单，允许浏览器使用多种协议去获得各种不同的资源。事实上，已经定义了针对各种其他协议的URL 。下表列出了稍微简化了的常见形式。
• http 协议是Web 的母语，即Web 服务器讲的语言。HTTP代表超文本传输协议（ HyperText Transfer Protocol ）。ftp 协议用于通过FTP 访问文件，这是Internet 的文件传输协议。FTP 早在Web 之前就有，己经被使用超过30 年。通过提供一个简单的可点击界面而不是一个命令行界面， Web使得用户更加易于获得存放在世界各地众多FTP 服务器上的文件。这种获取信息的方式改进是蔚为壮观Web 增长的原因之一。使用file 协议或者更简单地只要给出一个文件名就有可能通过Web 页面来访问本地文件。这种方法并不需要一个服务器。当然，它仅适用于本地文件，而不能用于远程文件。mailto 协议并没有真正抓取网页，但反正是有用的。它允许用户从Web 浏览器发送电子邮件。大多数浏览器针对一个mailto 链接会以启动用户的邮件代理作为回应，返回一个已经写好地址字段的邮件。rtsp 和sip 协议用于创建流式媒体会话和音视频的呼叫。最后， about 协议是一种惯常方式，主要用来提供有关浏览器的信息。例如， about: plugins链接会导致大部分浏览器显示一个网页，该网页列出它们利用浏览器扩展可以处理的MIME 类型，这种浏览器扩展称为插件。
• 总之， URL 的设计不仅允许用户浏览网页，而且允许用户运行一些旧的协议，比如FTP和电子邮件，以及涉及音频和视频的新协议：除此之外，还提供了访问本地文件和浏览器信息的便利方法。这种方法不需要专门为其他服务设计特殊的用户界面程序，而是把几乎所有的Internet 访问集成到单一的程序： Web 浏览器。如果这种想法不是由一个在瑞士研究实验室工作的英国物理学家发明的，那么它可能很容易得到一些软件公司广告的梦想计划的支持。
• 抛开所有这些漂亮的属性，越来越多的Web 使用已经暴露出URL 方案中的固有弱点。一个URL 指向一个特定的主机，但有时引用一个页面而无须告诉它在哪里也是很有用的。例如，对于被大量引用的页面，需要有多个相距甚远的副本，以便减少网络流量。
• 为了解决这类问题， URL已经被推广到统一资源标识符（ URI, Uniform Resource Identifiers ）。某些URI 告诉浏览器如何定位资源，这些就是URL ；其他URI 告诉了资源名字，但没有说明到哪里可以找得到它，这些URI 就称为统一资源名（ URN, Uniform Resource Names ）。如何书写URI 的规则由RFC 3986 给出说明，而不同URI 方案的使用则由IANA负责跟踪。除了在上表列出的主要方案外，还有许多不同类型的URI。

MIME 类型

• 为了能够显示新页面（或任何页面），浏览器必须了解其格式。为了让所有的浏览器都了解所有网页，网页必须以一种标准化的语言编写，这个语言就称为HTML 。它是Web 的通用语（现在）。虽然浏览器基本上是一个HTML 解释器，但大多数的浏览器有众多的按钮和功能，帮助用户更容易地浏览网页。大多数浏览器有一个返回到前一页、前进到下一页的按钮（只有当用户操作了回退动作后），和一个直接通往用户首选页的按钮。大多数浏览器还有一个按钮或菜单项用来在给定页面上设置书签，而且还提供了另一个显示书签列表的按钮或菜单项，这种方式下只需要点击几下鼠标就有可能重新审视书签。
• 正如我们的例子所显示的那样， HTML 页面包含了丰富的内容元素，而不只是简单的文本和超文本。为了增加一般性，并不是所有的页面都需要包含HTML。一个页面可能由一段MPEG 格式的视频、一个PDF 格式的文件、一张JPEG 格式的照片、一首MP3 格式的歌曲，或任何数百种其他文件类型的内容组成。由于标准的HTML页面可以链接到任何一种格式的内容，因此当浏览器命中一个它不知道如何解释的页面时，问题就产生了。
• 不是把浏览器越做越大，使其内置的解释器能适应快速增长的文件类型，相反大多数浏览器都选择了一个更为一般性的解决方案。当一台服务器返回一个页面时，它同时也返回了一些关于此页面的其他信息。这些信息包括页面的MIME 类型（电子邮件中有说明）。具有text/html 类型的页面可被直接显示，就像其他一些内置类型的网页一样。如果MIME 类型不是一个内置的类型，那么浏览器查阅其MIME 类型表，以便确定如何显示该页面。此表将MIME 类型与观众关联。
• 有两种可能的方式：插件和辅助应用程序。插件（ plug-in ）是一个第三方代码模块，作为扩展被安装到浏览器中，如图所示。常用的插件例子有PDF 、Flash 和Quicktime，主要用来呈现文档和播放音视频。由于插件运行在浏览器内部，因此它们可以访问当前的页面，也可以修改页面的外观。
• 每种浏览器都有一组过程，所有的插件必须实现这些过程，这样浏览器才可以调用插件。例如，通常浏览器的基本代码会调用一个专门过程，将待显示的数据传递给插件。这组过程就是插件的接口，它与特定的浏览器相关。另外，浏览器也为插件提供了一组它自己的过程，以便向插件提供服务。浏览器接口较为典型的过程包括申请和释放内存、在浏览器的状态栏上显示一条消息，以及向浏览器查询有关的参数。
• 在一个插件被使用以前，首先必须安装该插件。一般的安装过程是，用户到插件的Web 站点下载一个安装文件。执行安装文件将插件解压缩，并且执行适当的调用以便注册该插件的MIME 类型，并将浏览器与读插件关联起来。浏览器通常预载了一些流行的插件。另一种扩展浏览器的方式是使用一个辅助应用程序（ helper application ）。这是一个作为独立进程运行的完整程序，如图所示。因为辅助应用程序是独立运行的程序，因此接口与浏览器非常靠近。它通常只是接受一个存储了待显示内容的临时文件名字，然后打开该文件并显示其内容。典型地，辅助应用程序是一些独立于浏览器而存在的大型程序，比如Microsoft Word 或者PowerPoint。许多辅助应用程序使用MIME 的application 类型。因此，目前已经定义了相当多的子类型，例如， application/vnd.ms-powerpoint 表示PowerPoint 文件。Vnd 代表特定于开发商的格式。通过这种方式， URL 就可以直接指向一个PowerPoint 文件，并且当用户单击它时，浏览器自动启动PowerPoint，并将待显示的内容传递给它。
• 辅助应用程序并不受限于只能使用MIME 的application 类型。例如， image/x-photoshop 代表Adobe Photoshop。因此，可以将浏览器配置成能处理几乎无限多种文档的类型，而且无须改变浏览器本身。现代Web 服务器常常被配置成具有数百种“类型／子类型”的组合，每当安装一个新程序时，新的类型／子类型组合也随之被加入进来。针对一些子类型，比如video/mpeg，当多个插件和辅助应用程序都适用的时候，就会产生冲突。当注册的最后一个覆盖掉己有与MIME 类型关联的插件或者辅助应用程序，从而为自己捕获类型时。因此，安装一个新的程序可能会改变浏览器处理现有类型的方式。
• 浏览器也能够打开本地的文件，而不一定非得从远程的Web 服务器上取回文件，就像没有网络一样。然而，浏览器需要某种方式来确定文件的MIME 类型。标准的方式是操作系统将文件的扩展与MIME 类型关联起来。在典型的配置中，当浏览器打开foo.pdf 时，它就会用application/pdf 插件，而当打开bar.doc 文件时则通过application/msword 辅助应用程序调用Word 。
• 同样地，由于许多程序都希望处理某些类型的文件，比如说mpg，所以这里还可能发生冲突。在安装过程中，供经验丰富用户使用的程序常常会针对它们处理的MIME 类型和扩展名，给用户显示一些复选框，并且允许用户选择合适的程序，这样就不会无意中覆盖掉已有的关联关系。面向消费者市场的程序则假设用户根本不知道什么是MIME 类型，它们只是尽可能地抓取到所有的类型，而根本不关心以前安装的程序做过什么。
• 能够将浏览器扩展成拥有处理大量新类型的能力确实非常方便，但这也导致了麻烦。当Windows 个人计算机上的浏览器抓取了一个扩展名为exe 的文件时，它知道这个文件是可执行程序，因而没有对应的辅助应用程序。很显然它应该运行这个程序，然而，这可能是一个巨大的安全漏洞。一个恶意的Web 站点所需做的全部事情只是生成一个包含许多图片（比如电影明星或体育明星）的Web 页面，并且将所有的图片都链接到一个病毒上。于是，单击任何一幅图片都会导致取回一个未知的、可能恶意的可执行程序，并且在用户的机器上运行。为了预防这样的不速之客入侵，Firefox和其他浏览器配置成特别小心地自动运行未知程序，但是，并不是所有的用户都懂得什么样的配置才是安全的而不是便利的。

服务器端

• 关于客户端的介绍己经很多了，现在让我们来看看服务器端。正如我们在前面所看到的，当用户键入一个URL 或者单击一行超文本时，浏览器会解析URL，并且将http://和下一个斜线之间的那部分解释成待查找的DNS 名字。有了服务器的IP 地址以后，浏览器与该服务器的端口80 建立一个TCP 连接：然后它发送一条命令，其中包含了URL 的剩余部分，即该服务器上某个页面的路径：最后服务器返回该页面供浏览器显示。
• 乍一看， Web 服务器与传输层章节中的Internet文件服务器示例非常类似。该图中的服务器得到一个待查找
  的文件名字，并且通过网络返回结果。在这两种情况下，服务器在它的主循环中执行如下步骤：
  (1 ）接受来自客户端（浏览器）的TCP 连接。
  (2 ）获取页面的路径，即被请求文件的名字。
  (3 ）获取文件（从磁盘上）。
  (4 ）将文件内容发送给客户。
  (5 ）释放该TCP 连接。
• 现代的Web 服务器具有更多的功能，但本质上这就是Web 服务器在最简单情况下所做的工作，即获取一个包含网页内容的文件。对于动态内容，第三步必须替换成运行一个程序（由路径确定），该程序能返回网页的内容。然而，为了单位时间处理多个请求， Web 服务器的实现具有不同的设计。简单设计的一个问题是文件访问通常成为瓶颈。相对程序执行而言，读磁盘的速度很慢，而且通过操作系统调用重复读取相同的磁盘文件。另一个问题是一次只能处理一个请求。文件或许会很大，当系统在传输该文件时其他请求都被阻塞了。
• 一种显而易见的改进方法（所有的Web 服务器都采用了这种方法）是在内存中维护一个缓存，其中保存着n个最近使用过的文件或者数千兆量的内容。服务器在从磁盘读取文件之前，首先检查缓存。如果缓存中有该文件，则直接从内存中取出文件，从而消除了访问磁盘的时间。虽然真正有效的缓存需要大量的内存，以及一定的额外处理时间来完成检查缓存和管理其内容，但是，节省下来的时间几乎总是抵得上这些开销和费用。
• 为了解决一次只能服务一个请求的问题，一种策略是将服务器设计成多线程模式(multithreaded）。在其中一种设计方案中，服务器由一个前端模块（front-end module ）和k个处理模块（ processing module ）组成，如图所示。前端模块接受所有入境请求： k+1个线程全部属于同一个进程，这样所有处理模块都可以访问当前进程地址空间中的缓存。当一个请求到达时，前端模块接受它，并为其创建一条描述该请求的简短记录，然后将该记录递交给其中一个处理模块。
• 处理模块首先检查缓存，查看其中是否有所需的文件。如果缓存中有该文件，则处理模块修改记录，在记录中增加一个指向该文件的指针：如果缓存中没有该文件，则处理模块执行一次磁盘操作将该文件读入缓存（可能要丢弃其他一些缓存的文件，以便腾出空间）。从磁盘上读取文件后，将该文件放入缓存，同时把它发送给客户。这种方案的优点是当一个或多个处理模块因为等待磁盘操作或者网络操作的完成而被阻塞时（因此不占用CPU 时间），其他模块可以继续处理其他的请求。有了k 个处理模块，吞吐量可以达到单线程服务器下的k 倍。当然，当磁盘或者网络成为受限因素时，必须使用多个磁盘或者更快的网络才能获得比单线程模式实质性的性能提高。
• 现代Web 服务器所做的不只是接受文件名和返回文件。事实上，每个请求的实际处理过程可能非常复杂。由于这个原因，在许多服务器中，每个处理模块要执行一系列步骤。前端将每个入境请求传递给第一个可用模块，然后该模块根据这个特定请求的需要，执行下列步骤中的某个子集。这些步骤发生在TCP 连接和任何安全传输机制（例如SSL/TLS）建立之后。
  (1 ）解析被请求的Web 页面的名字。
  (2 ）执行对该页面的访问控制。
  (3 ）检查缓存。
  (4 ）从磁盘上获取请求的页面或者运行一个创建页面的程序。
  (5 ）确定响应中的其余部分（比如要发送的MIME 类型）。
  (6 ）把响应返回给客户。
  (7 ）在服务器的日志中增加一个表项。
• 第(1）步是必需的，因为入境请求中可能并没有包含文件或者程序的字面意义上的实际名字。它或许包含了需要转换的内置缩写。作为一个简单例子，在URLhttp://www.cs.vu.nl中的文件名是空的。在这种情况下，有必要将它扩展到某个默认的文件名，通常是index.html 。另一个常用的规则是将～user／映射到user 的web 目录。这些规则可以联合使用。
• 因此本书作者之一（AST）的主页可以通过下面的URL 到达：
  http://www.cs.vu.nl/~ast/
  即使在特定默认目录下的实际文件名是index.html 。同样地，现代浏览器可以指定配置信息，比如浏览器软件和用户的默认语言〈例如意大利语或英语〉。这样，如果可能，服务器就能为移动设备选择具有小图片和恰当语言的Web 页面。一般来说，文件名的扩展并不像它首次出现时那样微不足道，因为对于如何把路径映射到文件目录和程序有各种各样的惯例。
• 第（2）步检查是否存在与该页面关联的任何访问限制。并非所有的网页都向公众开放。确定客户端是否有权限获取一个页面可能依赖于客户端的身份（例如，给出用户名和密码〉，或者客户端在DNS 或IP 地址空间的位置。例如，一个页面可能被限制于只向公司内部的员工开放。如何实现这一点则取决于服务器的设计。例如，对于流行的Apache 服务器，惯常的做法是把后缀名为.htaccess 的文件放置在被限制访问的页面所在的目录，该文件列出
  了对页面的访问限制。
• 第(3）步和第（4）步涉及页面的获取。是否可以从缓存中获取页面取决于处理规则。例如，因为程序每次运行都可能产生不同的结果，因此由正在运行的程序创建的页面并不总是可以被缓存。甚至文件也应该偶尔被检查一下，看看它们的内容是否已经发生改变，以便旧的内容从缓存中删除。如果页面需要运行一个程序，那么还存在一个设置程序参数或输入的问题。这些数据来自请求的路径或请求中的其他部分。
• 第（5）步确定响应页面内容时有关的其他部分。MIME 类型就是一个例子。它可能来自文件的扩展名、一个文件的前几个字或程序的输出、一个配置文件，以及其他可能的来源。
• 第（6）步通过网络返回页面。为了提高性能，一个TCP 连接可以被客户端和服务器用来获取多个页面。这种连接的重用性意味着需要一些逻辑，将一个请求映射到一个共享的连接并且返回请求的每个响应，以便它与正确的请求关联。
• 第（7）步是为了行政管理的需要在系统日志中增加一个表项反映此次访问，同时还记录任何其他重要的统计数据。这种日志可以在日后被用来挖掘出有关用户行为的有价值信息，例如，人们访问网页的次序。

Cookie

• 到目前为止，正如我们所描述的那样，浏览网站只涉及一系列独立页面的获取。完全没有登录会话的概念。浏览器发送一个请求给服务器，并获得返回的文件。然后，服务器彻底忘记它已经看到过哪些特定的客户。
• 这种模式对于检索公开可用的文件资源完全足够，而且在Web 创造初期运作良好。然而，它不适合为不同的用户返回不同的页面，应该给用户返回什么页面取决于他们之前在服务器上做了什么。这样的行为需要与网站进行多次交互。例如，某些网站（例如报纸〉要求客户注册（并且有可能要付费〉才能使用。这就提出了一个问题，服务器如何区分来自以前注册过的用户的请求还是来自没有注册过的其他人的请求？第二个例子是电子商务。如果用户在电子商店漫步，不时地折腾放到虚拟购物车中的项目，服务器如何保持跟踪其购物车的内容？第三个例子是定制的门户网站，比如雅虎。用户可以设置其个性化的初始页面，该页面只给出他们想要的信息（例如，他们的股票和喜爱的运动队〉，但是，如果服务器不知道用户是谁，它该如何显示正确的页面？
• 乍一看，读者可能会立即想到服务器可以通过观察用户的IP 地址来跟踪他们。然而，这个想法并不奏效。首先，许多用户通过共享的计算机工作，特别是在家里：而且IP 地址仅仅标识了计算机而不标识用户。其次，更糟糕的是，许多公司使用NAT，因而所有用户发出的出境数据包具有相同的IP 地址。也就是说，所有NAT 盒子后面的计算机从服务器的角度来看是同一台机器。
• 这个问题的解决方案是采用了一项称为小甜饼（Cookie，它是一小段文本信息，伴随着用户请求页面在Web 服务器和浏览器之间传递）的备受批评的技术。这个名称来自于很早以前的程序员行话，即程序调用一个过程并得到一些信息，这些信息稍后在完成某些工作时可能需要用得到。从这种意义上来说， UNIX 文件描述符或Windows 对象句柄都可以被看作是一种Cookie 。Cookie 首次实现在1994 年Netscape 浏览器中，后来在RFC 2109中对此作了正式定义。
• 当客户请求一个Web 页面时，服务器除了提供所请求的页面以外，还以Cookie 的形式提供了一些附加的信息。Cookie 是一个相当小的命名的串（最多4KB ），服务器将它与浏览器关联。这种关联与用户关联不一样，但它非常接近而且比IP 地址更有用。浏览器把服务器所提供的Cookie 通常存储在客户机磁盘Cookie 目录下一段时间，这样在整个浏览器调用期间一直坚持Cookie，除非用户禁用Cookie。 Cookie 只是字符串，而不是可执行程序。原则上，一个Cookie 可能包含病毒，但由于Cookie 只被当作数据处理，因而不存在病毒得以实际运行从而造成损害的正式途径。然而，始终有可能存在一些黑客利用一个浏览器的漏洞，来激活病毒。
• 一个Cookie 可能包含至多5 个字段，如表所示。域（ Domain ）指出Cookie 来自何方。浏览器应该检查服务器没有谎报它们的域名。每个域为每个客户端应该存储不超过20 个Cookie。路径（ Path ）是服务器目录结构中的一个路径，它标识了服务器文件树的哪些部分可能使用该Cookie。路径通常是／，这意味着整棵树。
• 内容（ Content ）字段采用“名字＝值”的形式。这里名字和值都可以是服务器期望的任何内容。这个字段正是存放Cookie 内容的地方。过期时间(Expires）字段指定了该Cookie 何时过期。如果这个字段不存在，则浏览器在退出时将丢弃Cookie，这样的Cookie 称为非持续Cookie ( nonpersistent cookie ）；如果针对某个Cookie 提供了时间和日期，那么这样的Cookie 称为持续Cookie (persistent cookie)，它被一直保存直至过期为止。过期时间采用了格林尼治标准时间。为了从客户的硬盘上删除一个Cookie ，服务器只需将它再发送一次，但是将该Cookie 的过期时间指定为一个已经经过去的时间即可。
• 最后，通过设置安全（ Secure ）字段指示浏览器只向使用安全传输连接的服务器返回Cookie，所谓的安全传输就是SSL/TLS。这个功能可用于电子商务、银行和其他安全类应用。
• 我们现在己经看到了如何获得Cookie，但如何使用Cookie 呢？在浏览器向某个Web站点发出一个页面请求之前，浏览器检查它的Cookie 目录，确定这个请求前往的目标域是否在当前客户端放置了Cookie 。如果存在相应的Cookie，则该域放置的所有Cookie 都被包含到请求消息中。服务器得到了这些Cookie 以后，就可以按它所期望的方式来解释它们。
• 我们现在来看Cookie 的一些可能用法。在上表中，第一个Cookie 由toms-casino.com设置，并且被用来标识一个顾客。当该顾客下个星期登录进去花掉了一些钱时，浏览器将Cookie 发送过去，因此服务器就知道他是谁了。有了顾客的ID ，服务器就可以在数据库中查找该顾客的消费记录，并利用这些记录信息来创建一个合适的Web 页面显示给该顾客。如果已知该顾客爱好赌博，则为其显示的页面可能由扑克游戏、今日赛马比赛名单，或老虎机组成。
• 第二个Cookie 来自 joes-store.com。这里的场景是顾客在商店里闲逛，寻找想购买的好东西。当她发现一件便宜货并单击它时，服务器将该货物放入她的购物车（由服务器维护〉，同时创建一个包含商品数量和产品代码的Cookie，并把它发送给客户。当客户继续在商店里闲逛时，每当客户点击一个新页面，该Cookie 随着该新页面的请求被返回到服务器端。随着顾客购买的物品累计得越来越多，服务器将它们统统加入到Cookie 中。最后，当客户单击“前往结账”时，这个Cookie 现在包含了她想购买商品的完整列表，它和当前的请求一起被发送给服务器。通过这种方式，服务器就能够精确地知道顾客想购买哪些东西。
• 第三个Cookie 用于Web 门户站点。当用户单击一个指向该门户的链接时，浏览器将Cookie 发送过去。它告诉该门户站点创建一个页面，包含Cisco 公司和Oracle 公司的股票价格，以及纽约喷气机队橄榄球赛的结果。由于Cookie 最多可以达到4 KB长，所以还有足够的空间来存放关于报纸头条新闻、本地天气、特价信息等更多用户喜好的信息。这样网站经营者可以了解用户如何浏览他们的网站，广告商为一个特定用户建立浏览的广告或网站的概况。备受争议的是用户通常不知道他们的活动被跟踪了，即使详细的资料和跨越看似与网站无关。尽管如此， Web 跟踪( Web tracking ）是一项大生意。提供并跟踪广告的DoubleClick 跻身于世界上最繁忙的前100 网站，这是由Web 监测公司Alexa 作出的排名。Google Analytics 为运营商跟踪站点的使用情况，它已被世界上最繁忙的10 万个网站中一半以上的网站所使用。
• 利用Cookie，服务器很容易地就能跟踪用户的活动。假设一个服务器想知道它有多少个只来过一次的访问者，以及每个人在离开该站点前看过多少页面。当第一个请求到来时，它不会随带任何Cookie，因此服务器返回一个包含“ Counter= I ”的Cookie。用户浏览本站点的后续网页将会把这个Cookie 送回给服务器。服务器每次递增该计数器并送回给客户。通过跟踪这个计数器，服务器就可以知道有多少人在看了第一个页面后就离开了，有多少人看了第二个页面才离开，等等。
• 跟踪用户跨越站点的浏览行为仅仅稍微复杂一点。其工作过程如下所述。一家广告代理商，比如说Sneaky广告，它联系了一些主要的Web 站点，在这些站点的页面上放置一些广告来宣传它企业客户的产品，为此它当然向这些站点的所有者支付一定的费用。广告公司并不是向这些站点提供一个放在每个页面上的GIF 或JPEG 文件，而是提供一个URL,这个URL 被加入到每个页面中。广告公司给出的每个URL 包含一个路径上的唯一数字，例如
  htttp://www.sneaky.com/38267 4902342.gif
• 当用户第一次访问一个包含该广告的页面P 时，浏览器获取HTML 文件。然后浏览器检查该HTML 文件，并看到了指向 www.sneaky.com 上图像文件的链接，因此它向 www.sneaky.com 发送一个对该图像的请求。一个包含广告的GIF 文件，连同一个包含了唯一用户ID ( 即上表中4627239101 ）的Cookie ，一起被返回给客户。sneaky公司记录下这样的事实：此ID 的用户曾经访问过页面P 。要做到这点很容易，因为被请求的路径(382674902342.gif）只在页面P 上被引用过。当然，实际的广告可能出现在成千上万个页面，但每次都有一个不同的文件名。sneaky公司也许在每次发布广告时从产品制造商那里获得几美分的收益。
• 稍后，当这个用户访问另一个包含sneaky 广告的Web 页面时，浏览器首先从服务器获回HTML 文件，然后它看到页面上有一个指向http://www.sneaky.com/193654919923.gif的链接， T是请求该文件。由于浏览器己经有一个来自 sneaky.com 域的Cookie ，于是它将这个含有用户ID 的sneaky Cookie 也包含在请求中。sneaky现在知道该用户已经访问了第二个页面。
• 在适当的时候，即使用户从未点击过任何广告， Sne啕r 也能够建立起有关该用户浏览习惯的详细轮廓。当然，它还没有用户的名字（虽然它有用户的IP 地址，也许根据其他数据库信息就足以推断出用户的名字〉。然而，如果该用户曾经将他的名字提供给任何一个与Sneaky 合作的站点，那么现在sneaky就拥有了一份带有用户名字的完整轮廓信息，它可以卖给任何一个有意购买此类信息的人。出售这些信息可能会给sneaky带来足够的利润，使它能在更多的Web 站点上放置更多的广告，从而收集更多的信息。
• 如果sneaky想要做得更加偷偷地不为人知，则广告不必做成传统的横幅广告。一个由背景颜色单像素组成的“广告”（因此是不可见的〉与横幅广告具有完全相同的效果：它要求浏览器取回这个1*1 像素的gif 图像，并将该像素所属域的所有Cookie 发送给服务器。
• Cookie 己经成为是否侵害用户在线隐私的一个辩论焦点，因为像上面这样的跟踪行为侵犯了用户的在线隐私。在整个商业中最阴险的环节在于许多用户完全不知道自己的信息被他人收集，甚至可能认为自己是安全的，因为他们没有点击任何广告。出于这个原因，跨站点跟踪用户的Cookie 被许多人认为是间谍软件Cspyware ）。看看你的浏览器中是否早就己经存储了Cookie。大多数浏览器会显示此信息，同时还会显示当前的隐私偏好设置。你或许会惊讶地发现姓名、电子邮件地址或密码以及不透明的标识符。希望你不会发现信用卡号码，但Cookie 被滥用的潜在性非常明显。
• 为了维护外表上的隐私，有些用户将他们的浏览器配置成拒绝所有的Cookie。 然而，这会带来一些问题，因为许多Web 站点没有Cookie 无法正常工作。另外，大多数浏览器允许用户阻止第三方Cookie。第三方Cookie ( third-party cookie ）是从一个不同于主页网站的其他网站获得的Cookie ，例如， sneaky.com Cookie 就是在与一个完全不同网站的P 页面交互时所用的。阻止这些Cookie 有助于防止跨网站的跟踪。安装浏览器的扩展也可以提供细粒度的控制如何使用Cookie （或者说，不使用Cookie ）。随着辩论的继续，许多公司正在制定有关隐私政策，限制它们如何共享信息，以便防止用户信息被滥用。当然，政策只是公司简单地说它们将如何处理信息。例如：“我们可能会使用从你那里收集到的信息来指导我们的业务”一一这或许正是销售信息。