1、HTTP——超文本传输协议

• 既然我们已经理解了Web 内容和应用，现在是时候考察在Web 服务器和客户之间传输所有这些信息的协议了。这就是超文本传输协议（ HTTP， HyperText Transfer Protocol)，由RFC 2616 说明。HTTP 是一个简单的请求。响应协议，它通常运行在TCP 之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII 码形式给出，就像SMTP 一样：而消息内容则具有一个类似MIME 的格式，也像SMTP 一样。这个简单模型是早期Web 成功的有功之臣，因为它使得开发和部署是那么的直截了当。
• 在本节，我们将着眼于时下使用HTTP 的一些更加重要的属性。然而，在进入HTTP的细节之前，我们注意到它在Internet 上的使用方式在不断地演化。HTTP 是一个应用层协议，因为它运行在TCP 之上，并且与Web 密切相关。这就是为什么我们在本章讨论它。然而，在另一种意义上， HTTP 变得越来越像一个传输层协议，因为它为进程之间跨越不同网络进行内容通信提供了一种方式。这些进程不一定必须是Web 浏览器和Web 服务器。媒体播放器也可以使用HTTP 与服务器通信并请求专辑信息。防病毒软件可以使用HTTP来下载最新的病毒库更新。开发人员可以使用HTTP 来获取项目文件。消费电子产品比如数码相框通常使用内嵌的HTTP 服务器作为与外界的接口。机器与机器之间的通信越来越多地通过HTTP 运行。例如，航空公司服务器可以使用SOAP（ 一种运行在HTTP 之上的XMLRPC ）联系一家汽车租赁服务器，并且进行汽车预订，所有这些都作为度假产品的一部分。这种趋势有可能继续下去，伴随着HTTP 的使用而不断扩大。

连接

• 浏览器与服务器联系最常用的方法是与服务器机器上的端口80 建立一个TCP 连接，虽然这个过程并不是正式要求的。使用TCP 的意义在于浏览器和服务器都不需要担心如何处理长消息、可靠性或拥塞控制。所有这些事情都由TCP 实现负责处理。
• 在Web 早期HTTP1.0 中，连接被建立起来以后浏览器只发送一个请求，之后一个响应消息被发回来，再然后TCP 连接就被释放了。那时，整个Web 页面通常只包含HTML文本，因此这种方法足够用了。很快， Web 页面发展成还含有大量的嵌入式内容链接，比如图标以及其他精美的东西。建立一个单独的TCP 连接来传输每个图标的操作方式代价太昂贵。这种现象导致了HTTP 1.1 的诞生，它支持持续连接（persistent connection ）。有了这种连接，就有可能建立一个TCP 连接，在其上发送一个请求并得到一个响应，然后再发送额外的请求并得到额外的响应。这种策略也称为连接重用（ connection reuse ）。通过把TCP连接的建立、启动和释放等开销分摊到多个请求上，相对于每个请求的TCP 开销就被大大地降低了。而且，还可以发送流水线请求，也就是说在请求1的响应回来之前发送请求2。
• 这3 种情况的性能差异如图所示。图(a）部分显示了3 个请求，一个接着一个，每一个都是一个单独的连接。让我们假设这表示一个Web 页面，其中有两个嵌入式图像在同一台服务器上。图像的URL 被确定为主页，并且己经获取，因此在主页之后这些图像也己经获取过来。如今，一个典型的页面大约有40 个对象。在图(b）中，通过一个持续连接来获取页面。也就是说， TCP 连接在启动后是开放的，然后发送相同的3个请求，一个接着一个，后一个跟前一个一样，然后才关闭连接。可以观察到页面的提取任务更快速地完成了。加速的原因有两个：首先，时间没有浪费在建立更多的连接上。每个TCP 连接至少需要一个往返时间才能建立：其次，相同图像的传输更加迅速。为什么会这样？这是因为TCP 的拥塞控制。在一个连接的开始阶段， TCP 使用慢启动过程来增加吞吐量，直到它了解网络路径的行为。这个预热期的后果是多个短TCP连接比一个长TCP 连接传输信息所需的时间更长。
• 最后，在图(c）中，有一个持久连接和请求流水线。具体来说，第二个和第三个要求尽快发送出去，一旦检索主页足够识别出必须预取图像就立即发送请求。这些请求的响应最终紧随其后。这种方法减少了服务器处于空闲状态的时间，因此进一步提高了性能。
• 然而，持续连接不是免费的。一个新的问题出现了，那就是什么时候关闭连接。一个到服务器的连接在页面加载时应该保持开放。然后呢？对于用户来说有个很好的机会，他可以点击一个链接从服务器请求另一个页面。如果连接保持打开状态，那么下一个请求被立即发送出去。不过，谁也不能保证任意时间后客户将向服务器发出另一个请求。实际上，客户机和服务器通常将持续连接保持打开状态，直到它们己经闲置一小段时间（例如60秒），或者它们己经打开了大量的连接必须要关闭一些。
• 细心的读者可能己经注意到还有一种组合，我们到目前为止还没有提及。那就是，在每个TCP 连接上发送一个请求，但同时并行打开多个TCP 连接。这种并行连接（ parallel connection ）方法在持续连接之前被浏览器广泛使用。它具有与顺序连接相同的缺点一一额外的开销，但性能比顺序连接的要好。这是因为建立和加大并行连接隐藏着一些延迟。在我们的例子中，两个嵌入式图像的连接可以在同一时间建立。然而，在同一台服务器上运行多个TCP 连接会令人沮丧。原因在于TCP 为每个连接单独执行拥塞控制。因此，连接之间彼此竞争，造成丢包率上升，而且聚合起来比单个连接的网络用户更具侵略性。持续连接则更优越，应该比并行连接优先使用，因为它们避免了开销，而且不会遭受流量拥塞问题。

方法

• 尽管HTTP 是为Web 而设计的，但出于放眼未来面向对象的使用，它的设计有意识地比Web 所需要的更加通用。正是这个原因， HTTP 不仅支持请求一个Web 页面，而且支持操作一一称为方法（ method ）。这种通用性是SOAP 得以存在的主要原因。每个请求由一行或多行ASCII 文本组成，其中第一行的第一个词是被请求的方法名字。图中列出了内置的方法。方法名区分大小写，因此GET是合法的方法而get不是。
• GET方法请求服务器发送页面（在大多数情况下，当我们说“页面”时我们指的是“对象”，但是把一个页面想象成一个文件，理解这个概念就足够了〉。该页面被适当编码成MIME。大部分发送给Web服务器的请求都是GET 方法。GET 的通用形式是：
  GET filename HTTP/1.1
• 其中filename 是预取的页面名字， 1.1 是协议版本号。HEAD 方法只请求消息头，不需要真正的页面。这个方法可以收集建索引所需要的信息，或者只是测试一下URL 的有效性。当提交表单时需要用到POST 方法。POST 方法与GET 方法都可被用作SOAP Web 服务。与GET 类似，它也携带一个URL，但不是简单地检索一个页面，而是上载数据到服务器（即表单的内容或者RPC参数〉。然后，服务器利用这些数据做某件事，具体取决于URL ，概念上是将数据“附加”到对象上。效果或许是购买一个表项，或者调用一个过程。最后，方法返回一个指出结果的页面。
• 其余的方法对于浏览Web 并不常用。PUT 方法与GET 方法相反：它不是读取页面，而是写入页面。通过这个方法可以在远程服务器上建立起一组Web 页面。这个请求的主体包含了页面。页面可以利用MIME来编码，在这种情况下，跟在PUT 后面的行可能包含了认证头，以便证明调用者的确有权执行所请求的操作。DELETE 方法的用途可能与你想象的一样：删除页面，或者至少指出Web 服务器已经同意删除该页面。与PUT 方法类似，认证和许可机制在这里起到了很重要的作用。
• TRACE 方法用于调试。它指示服务器发回收到的请求。当请求没有被正确地处理而客户希望知道服务器实际得到的是什么样的请求时，这个方法非常有用。CONNECT 方法使得用户通过一个中间设备（比如Web 缓存〉与Web 服务器建立一个连接。OPTIONS 方法提供了一种办法让客户向服务器查询一个页面并且获得可用于该页面的方法和头。
• 每个请求都会得到一个响应，每个响应消息由一个状态行及可能的附加信息（例如全部或者部分Web 页面〉组成。状态行包括一个3 位数字的状态码，该状态码指明了这个请求是否被满足；如果没有满足，那么原因是什么。第一个数字把响应分成5大组，如图所示。1 ××码实际上很少被使用。2 ××码意味着这个请求被成功地处理，并且返回了相应的内容〈如果有的话〉。3 ××码告诉客户应该检查其他地方： 使用另一个不同的URL或者在它自己的缓存中查找（后面讨论）。4××码意味着由于客户错误而导致请求失败，比如无效请求或者不存在的页面。最后， 5 ××错误码意味着服务器自身出现内部问题，有可能是服务器代码中有错误，也可能是临时负载过重。

消息头

• 请求行（例如GET 方法的行）后面可能还有额外的行，其中包含了更多的信息。它们同称为请求头（request header ）。这些信息可以与一个过程调用的参数相类比。响应消息也有响应头（ response header）。有些头可以用在两个方向上。图中列出的是一些最重要的消息头。每个请求和响应通常具有不同的头。
• User-Agent 头允许客户将它的浏览器实现告知服务器（比如， Mozilla/5.0 和Chrome/5.0.375.125 ）。这些信息非常有用，服务器可以据此裁剪给浏览器的响应，因为不同浏览器的能力和行为大相径庭。如果客户对于可接受的信息有一定的限制，可以用4 个Accept 头告诉服务器愿意接受什么。第一个头指定了哪些MIME 类型是可以接受的（例如， text/html ）。第二个头给出了字符集（比如ISO-8859-5 或者Unicode-1-1） 。第三个头处理压缩方法（比如gzip ）。第四个头指明了一种自然语言（例如西班牙语〉。如果服务器有多个页面可供选择的话，那么它可以利用这些信息向客户提供所需要的页面。如果客户的请求不能满足，则返回一个错误码并且请求失败。
• lf-Modified-S ince 和lf-None-Match 头用于缓存。它们允许客户在网页的缓存副本不再有效时请求该网页。Host 头是服务器的名字，它取自URL 。这个头是强制性质的。有些IP 地址可能对应了多个DNS 名字，所以服务器需要某种方法来分辨出应该把请求传递给哪个主机来处理。对于那些被保护的页面， Authorization 头是必需的。在这种情况下，客户可能需要证明自己有权来查看被请求的页面。这个头就是用在这种情况下。客户端使用拼写错误的Referer 头给出了请求当前页面的URL 。大多数情况下，这是前一页的URL。这个头对于跟踪Web 浏览特别有用，因为它告诉了服务器客户如何到达该页面的。
• 尽管Cookie 是在RFC 2019 中而不是RFC 2616 中被阐述的，它们也有头。Set-Cookie头是服务器向客户端发送Cookie ，期待客户端保存Cookie，并且在后续的请求中返回给服务器，返回时要使用Cookie 头（请注意，针对Cookie 最近出了个规范说明了一种新的头，即RFC 2965 。但是它在很大程度上己经遭到行业拒绝，不太可能得到广泛实施〉。响应消息中还用到了许多其他的头。Server 头允许服务器在愿意时标识构建它的软件。下面5 个头，都从Content－起始，允许服务器描述它发送的页面的属性。
• Last-Modified 头说明了页面最后被修改的时间， Expires 头说明了页面能保持有效多长时间。这两个头在页面缓存机制中发挥着重要的作用。Location 头被服务器用来通知客户，它应该尝试另外一个不同的URL 。如果页面己经被移动，或者允许多个URL 指向同一个页面（可能在不同的服务器上〉，则可以使用这个头。它也可被用于另外一种情况，即公司的主页在com 域中，但是根据客户的IP 地址或者首选的语言，将客户的请求重定向到一个国家的或者地区的页面中。
• 如果一个页面非常大，则小客户可能不想一次获取所有的内容。有些服务器可以接受对于有节范围限定的请求，因此该页面可以通过多个小单位的请求取回来。AcceptRanges头声明了服务器愿意处理这种部分页面请求。Date 头可用在两个方向上，并且包含了发送消息的日期和时间，而Range 头则告诉了响应消息提供的网页的字节范围。ETag 头给出了一个简短的标签，作为页面内容的名称。它主要被用于缓存。Cache-Control 头给出了其他有关如何缓存（或更通常的是，如何不缓存〉网页的明确指示。最后， Upgrade 头用来切换到一个新的通信协议，比如未来的HTTP 协议或安全的传输协议。它允许客户宣布自己可以支持什么协议，同时允许服务器声称自己正在使用什么
  协议。

缓存

• 人们往往会返回到以前浏览过的Web 页面，而且相关的网页往往具有相同的嵌入式资源。比如有些例子包括用于整个网站导航的图像，以及常见的样式表和脚本。如果每次显示这些页面都要去服务器获取全部的资源，这将非常浪费，因为浏览器已经有了一个副本。积攒已经获取的网页供日后使用的处理方式称为缓存（ caching ）。其优点是当缓存的页面被重复使用时，没有必要进行重复传输。HTTP 内置了一种技术支撑，帮助客户标识他们何时可以放心地重用页面。这种支撑能减少网络流量和延迟，从而提高了性能。但现在存在一种权衡，即浏览器必须存储页面。因为本地存储成本已经很低廉，因此这几乎总是一个值得做的选项。这些网页通常保存在磁盘上，当稍后浏览器运行时可以直接使用它们。
• HTTP 缓存的困难问题在于如何确定以前缓存的页面和将要重新获取的页面是相同的。这个确定不能仅依靠URL 来作出。例如， URL 可能会给出一个页面，显示了最新的新闻项目。即使URL 保持不变，该页面的内容也会经常更新。另外一种情况是，页面的内容可能是来自希腊和罗马神话中的诸神列表，那么这种页面的改变速度应该不那么快。
• HTTP 使用两种策略来解决这个问题。这些策略如图所示，作为请求（第1 步）和响应（第5 步）之间的处理形式。第一种策略是页面验证（第2 步）。访问高速缓存，如果对所请求的URL 它有该页面的副本，而且该副本已知是新鲜的（即仍然有效），那么就没有必要从服务器重新获取。此时，直接返回缓存的页面。该缓存页面最初获取时返回的Expires 头以及当前的日期和时间可以被用来作出该副本是否有效的决定。
• 然而，并非所有的网页都有个方便的Expires 头来告诉你何时必须重新获取网页。毕竟，做出预测才是硬道理一一·尤其关于未来的预测。在这种情况下，浏览器可能使用启发式的方法来作出决策。例如，如果页面在过去的一年尚未修改（从Last-Modified 头获知），那么它极有可能在接下来的一个小时里不会有所改变，这或许是一个相当安全的赌注。然而，这里没有任何保证，也许下了个坏的赌注。例如，股市已经关闭一天，因此该页面数个小时都不曾改变，但下一个交易时段开始后它会迅速改变。因此，一个页面的缓存性随着时间的推移可能变化很大。基于这个原因，应谨慎使用启发式策略，尽管它们往往实际工作得挺好。
• 找到没有过期的页面是使用缓存的最大收益，因为这意味着根本不需要联系服务器。不幸的是，它并不总是能工作得很好。服务器必须谨慎地使用Expires 头，因为它们可能无法确定一个页面何时将被更新。因此，缓存的副本可能仍然是新鲜的，但客户并不知道。
• 第二个策略用在这种情况下。它询问服务器缓存的副本是否仍然有效。这个请求是一个条件GET (conditional GET ），如图中第3 步所示。如果服务器知道缓存的副本仍然是有效的，它可以发送一个简短的答复说是的（第4a 步〉。否则，它必须发送完整的响应消息（第4b 步〉。更多的头字段可用来让服务器检查一个缓存的副本是否仍然有效。客户端从Last-Modified 头可以获知缓存页面的最后更新时间。它可以使用If-Modified-Since 头将该时间发送给服务器，询问服务器所请求的页面在此期间是否发生过改变。
• 另一种选择是，服务器可能会返回一个包含ETag 头的页面。这个头给出了一个标签，是页面内容的一个短名称，有点像校验和但比它更好。（它可以是一个加密的哈希值〉。客户端可以向服务器请求验证缓存的副本，具体做法是给服务器发送If-None-Match 头，该头列出了缓存副本的标签。如果任何一个标签与内容相匹配，服务器将会予以响应，相应的缓存的副本就可以使用。在不太方便时可以使用这种方法，这种方法对确定页面是否新鲜很有用。例如，一个服务器可能会为相同的URL 返回不同的内容，这完全取决于首选什么样的语言和MIME 类型。在这种情况下，仅仅一个修改日期无助于服务器确定缓存页面是否新鲜。
• 最后，请注意这两种缓存策略都会被Cache-Control 头携带的指令所覆盖。当页面不恰当被缓存时，这些指令可以被用来限制缓存（例如， no-cache ）。比如，下一次抓取的动态页面将是不同的，因此不能缓存；或者那些需要授权的页面也不能被缓存。
• 关于如何缓存的方法有很多，我们谈两个要点。首先，缓存可以设置在除浏览器之外的其他地方。一般情况下，HTTP 请求可以通过一系列的缓存路由。使用浏览器之外的外部高速缓存方法称为代理缓存（ proxy caching）。每增加一个缓存级别可有助于进一步减少请求链。诸如ISP 和企业这些组织经常使用这种缓存方法，它们运行代理缓存为不同的用户提供了从缓存页面尽快获得响应的好处。其次，高速缓存对提升性能是个很大的推动，但它并没有人们所希望的那么多。原因是虽然在Web 上肯定有许多流行的文档，但也有很多人们获取的文档不是那么流行，其中很多还很长（例如，视频〉。不受欢迎的“长尾巴”文档占用了缓存空间，而且缓存能处理的请求数量随着高速缓存大小的增加而增长缓慢。Web 高速缓存能够处理的请求数量可能总是达不到全部请求数量的一半。

HTTP 实验

• 因为HTTP 是一个ASCII 协议，所以对于一个坐在终端（浏览器的对面〉前面的人来说很容易与Web 服务器直接通话。这里所需要的全部只是一个连到服务器端口80 的TCP连接。鼓励读者亲自尝试用下面的命令序列来做实验。在大多数UNIX shell 和Windows的命令窗口下这些命令部可以工作（只要telnet 程序可用〉。
  telnet www.ietf.org 80
  GET /rfc.html HTTP/1.1
  Host: www.ietf.org
• 这个命令序列启动一个telnet 连接（即TCP 连接〉，该连接指向端口为80的IETF的Web服务器 www.ietf.org。 然后是GET 命令，指定了URL 的路径和协议。尝试你自己选择的服务器和URL。接下来一行是强制的Host 头。最后一个头后面必须跟一个空行。它告诉服务器没有更多的请求头了。然后服务器发送响应消息。根据不同的服务器和URL ，可以观察到不同类型的头和页面。

2、移动Web

• Web 通常被大多数类型的计算机所用，这其中包括移动电话。在移动的同时通过无线网络浏览网页非常有用，但要做到这点面临着许多技术问题，因为太多的Web 内容是为具有宽带连接井有华丽表示的台式计算机而设计的。在本节，我们将描述如何从移动设备访问Web ，或者移动Web (mobile Web ），这些技术正处在开发之中。相比工作或家庭用的台式计算机，用移动电话来浏览Web 存在几个方面的困难：
  (1 ）相对小的屏幕妨碍了大页面和大图像的显示。
  (2 ）有限的输入能力使得URL 的输入很乏味或者输入法很慢。
  (3 ）无线链路的网络带宽有限，尤其是蜂窝。（3G）网络，费用还很高。
  (4 ）网络的连通性断断续续。
  (5 ）由于电池寿命、大小、散热以及成本等诸多原因，导致计算能力有限。
• 移动Web 的早期方法采用了一种新的协议栈，这种协议技专门针对能力有限的无线设备而发明出来的。无线应用协议( WAP, Wireless Application Protocol ）是这种策略的最知名的例子。经过各大移动电话厂商的努力， 1997 年WAP 正式启动，其中包括诺基亚、爱立信和摩托罗拉公司。然而，一路上意想不到的事情发生了。在接下来的十年间，随着3G数据服务的部署，以及移动电话有了更大的彩色显示屏、更快的处理器和802.11 无线功能，网络带宽和设备能力得到了巨大的提高。突然间，完全有可能在移动电话上运行简单的Web 浏览器。虽然这些移动电话与台式机之间始终存在着一个沟整，并且这个沟整永远也不会消除，但是当初推动一个单独协议栈的技术问题现在己经淡化。
• 当前使用得越来越多的方法是移动电话和台式机运行相同的Web 协议，并且当用户恰好在移动设备上时Web 站点负责提供移动友好（ mobile－friendly ）的内容。通过查看请求头信息， Web 服务器能够检测出应该返回桌面版本的网页还是移动版本的网页。User-Agent头在这方面特别有用，因为它标识了浏览器软件。因此，当Web 服务器接收到一个请求时，它可能首先查看头，然后给iPhone 返回图像小、文字少和简单的导航页面，而给笔记本电脑用户返回一个全功能的网页。W3C 从几个方面鼓励这种移动终端和计算机通用的方法。一种方式是标准化移动Web内容的最佳实践（ best practice ）。第一个规范提供了60 个这样的最佳实践（ Rabin 和McCathieNevile, 2008 ）。因为通信成本高于计算成本，其中的大多数实践采取了明智的措施来减少页面的大小，包括使用压缩算法，并且最大限度地提高缓存的有效性。这种方法鼓励了网站，尤其是大型网站创建移动Web 版本的页面内容，因为这是虏获移动Web 用户所必须要做的事情。为了帮助这些用户，还有一个标志指示可以在移动Web 上（很好）浏览的页面。
• 另一种有用的工具是一个精简版的HTML，称为基本XHTML（XHTML Basic ）。这种语言是XHTML 的一个子集，专用于移动电话、电视机、个人数字助理、自动售货机、传呼机、汽车、游戏机，甚至于表。出于这个原因，它不支持样式表、脚本或框，但大多数的标准标签它都有。它们被分成11 个模块。有些是必需的，而有些是可选的。所有的模块都以XML 定义。图中列出了一些模块和标签例子。
• 然而，并非所有的页面都能设计成在移动Web上工作良好。因此，一种互补的方法是使用内容转换或转码（ content transfonnation or transcoding ）。在这种方法中，将一台计算机设置在移动电话和服务器之间，它从移动电话获得请求，然后从服务器预取内容，最后把它转换成移动Web 内容。一种非常简单的转换方法是减少大型图片的尺寸，将它重新格式化成一个较低的分辨率。当然还可以使用其他许多小而有用的转换方法。自从移动Web 出现以来，转码技术的使用己经取得了一些成功。然而，当这两种方法都使用时，究竟由服务器还是转码器来作出移动内容的决策，两者之间存在着一种紧张关系。例如，一个Web 站点针对移动Web 可能会选择一种图像和文字的特殊组合，只能由一个转码器来改变图像的格式。
• 我们讨论至今一直关注着Web 内容，而没有涉及协议，因为实现移动Web 的最大问题正是由内容引起的。我们简要提及协议问题。Web 所用的HTTP, TCP 和IP 协议可能消耗掉相当数量的带宽，因为这些协议的开销不小（比如协议头）。为了解决这个问题，WAP 和其他解决方案定义了特殊用途的协议。这在很大程度上是没有必要的。报头压缩技术可以减少这些协议的开销。通过这种方式，很可能只需要一组协议（ HTTP, TCP, IP ），无论是高带宽还是低带宽链路都使用这组协议。在低带宽链路上使用时只需要打开头压缩技术。

3、Web 搜索

• 为了完成对Web 的描述，我们将讨论可以说是最成功的Web 应用程序：搜索。1998年，时任斯坦福大学研究生的Sergey Brin 和Larry Page 组建了一个称为谷歌（ Google ）的新兴公司，目标是建立一个更好的网络搜索引擎。他们秉持当时激进的想法：一个搜索算法计算每个页面多少次被其他页面所指是评价该页面重要性的更好手段，比每个页面包含多少个被搜索关键词的手段更好。例如，许多页面链接到思科（ Cisco ）的主页，对一个搜索“Cisco ”的用户而言，这个主页比思科以外的公司碰巧有个页面多次出现“思科”的页面要重要得多。
• 从某种意义上说，搜索仅仅是另一个Web 应用程序， 尽管它是最成熟的Web 应用程序之一， 因为自Web 初期以来它一直在被不断地开发。然而， Web 搜索已经成为日常生活中不可缺少的应用。估计每天有超过10 亿个网页被搜索。寻找所有其他信息方式的人把搜索作为起始点。例如，要找出在西雅图哪里有卖蔬菜和调味品，刚开始没有明显的网站可以使用。但机会存在于搜索引擎知道一个网页具有所需的信息，因而可以快速地引导你找到答案。
• 要以传统的方式进行Web 搜索，用户将她的浏览器指向一个Web 搜索网站的URL。主要的搜索网站包括谷歌、雅虎和Bing。接下来，用户使用表单提交搜索词。这种行为导致搜索引擎对它的数据库执行一次查询，搜索相关的页面或图像，或者想搜索的任何类型的资源，并且将查询结果作为一个动态页面返回。然后，用户可以按照链接找到己被发现的网页。
• Web 搜索是进行讨论的一个有趣话题，因为它对网络的设计和使用有很大影响。首先，存在一个Web 搜索如何找到网页的问题。Web 搜索引擎必须有一个运行查询算法的页面数据库。每个HTML 页面可能包含指向其他页面的链接，而且每一件有趣的事情（或者至少是可搜索的）链接在某个地方。这意味着，从少数页面开始通过遍历所有网页和链接，在理论上可能找出Web上的所有其他页面。这个过程称为Web 爬虫（ Web crawling ）。所有的Web 搜索引擎均使用Web 爬虫程序（ Web crawler ） 。
• 与爬虫有关的一个问题是它能找到什么样的页面。获取静态文件，然后跟随链接很容易做到。然而，许多网页包含一些程序，根据用户的交互显示不同页面。其中一个例子是在线商店的目录。该目录可能包含根据产品数据库创建的动态页面，以及针对不同产品的查询。这种类型的内容不同于很容易遍历的静态页面。Web 爬虫如何找到这些动态页面？答案是，在大多数情况下，它们抓取不到。这种隐藏的内容称为深层Web (deep Web ）。如何搜索深部web 是一个开放的问题，研究人员正在努力解决之。也有一些约定，网站提供一个页面（称为robots.txt） 告诉爬虫程序该站点的哪些部分应该或者不应该访问。
• 第二个需要考虑的问题是如何处理所有爬虫抓到的数据。为了使得索引算法能在大量的数据上运行，页面必须被有效存储起来。虽然估计值在不断地变化，但主要的搜索引擎被认为具有数百亿页面的索引，这些页面取自Web 的可见部分。平均页面大小大约为320KB。这些数字意味着，抓取一个Web 的副本需要20PB 量级或2×10¹⁶个字节量级的存储量。虽然这是一个真正庞大的数字，但它是Internet 数据中心可以轻松存储和处理的数据量（ Chang 等， 2006 ）。例如，如果磁盘的存储成本20 美元／TB ，那么2× 10⁴TB 的成本为400 000 美元，这个数字对于像谷歌、微软和雅虎这样的公司实在不能算大。虽然网络还在扩大，但磁盘的成本也在急剧下降，因此存储整个Web 在可预见的未来对于大公司仍然是可行的。
• 要使这些数据有意义则是另外一回事。你或许欣赏XML如何帮助程序轻松地提取数据结构，自主特设的格式会导致很多猜测。还有格式之间的转换问题，甚至是语言之间的翻译。但是，即使知道数据的结构也只是解决了问题的一部分。明白它的意思才是硬道理。从更相关的结果页面开始搜索查询，这是可以获得更大价值的关键所在。最终目标是要能够回答问题，例如，在你城市的哪里能买到便宜但像样的烤箱。
• Web 搜索的第三个方面是它已经提供了更高层次的命名。没有必要记住一个长长的URL，假设你记名字比记URL 记得更好，那么用一个人的名字来搜索网页一样可靠（或者更多）。这一策略越来越成功。犹如DNS 域名贬低了计算机的IP 地址，Web搜索降低了计算机的URL。此外，有利于搜索的是它能纠正拼写和输入错误，否则如果你输入了一个错误的URL，你只能得到错误的页面。
• 最后， Web 搜索向我们显示的事情很少与网络设计有关，但与某些Internet 服务增长有关的是：广告中有太多的钱。广告是驱动Web 搜索增长的经济引擎。从印刷广告到Web广告的主要变化在于：Web 广告具备根据人们正在寻找的对象来发放广告的能力，以此提高了广告的相关性。拍卖机制的变异方法被用来匹配搜索查询与最有价值的广告。当然，这种新的模式己经引起了新的问题，比如“点击欺诈”，在这种情况下，程序模仿用户点击广告造成没有真正赢利的报酬。