计算机网络 第二章：应用层（2）
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 使用 InternetExplorer 上网，她首次与 Amazon. com 联系。我们假定过去她已经访问过 eBay 站点。当请求报文到达该 Amazon Web 服务器时，该 Web 站点将产生一个唯一识别码，并以此作为索引在它的后端数据库中产生一个表项。 接下来 Amazon Web 服务器用一个包含 Set-cookie : 首部的 HTTP 响应报文对 Susan 的浏览器进行响应，其中 Set-cookie :首部含有该识别码。例如，该首都行可能是
Set-cookie：1678
当 Susan 的浏览器收到了该 HTTP 响应报文时，它会看到该 Set- cookie: 首部。该浏览器在它管理的特定 cookie 文件中添加一行，该行包含服务器的主机名和在 Set- cookie: 首部中的识别码。值得注意的是该 cookie 文件已经有了用 eBay 的表项，因为 Susan 过去访问过该站点。Susan 继续浏览 Amazon 网站时，每请求一个 Web 页面，其浏览器就会查询该 cookie 文件并抽取她对这个网站的识别码，并放到 HTTP 请求报文中包括识别码的 cookie 首部行中。特别是，发往该 Amazon 服务器的每个 HTTP 请求报文都包括以下首部行：
cookie:1678
这种模式下，Amazon 服务器可以跟踪 Susan 在 Amazon 站点的活动。尽管 Amazon Web 站点不必知道 Susan 的名字，但它确切地知道用户 1678 按照什么顺序、在什么时间、访问了哪些页面! Amazon 使用 cookie 来提供它的购物车服务，即 Amazon 能够维护 Susan 希望购买的物品列表，这样在 Susan 结束会话时可以一起为它们付费。
如果 Susan 再次访问 Amazon 站点，比如说一个星期后 ，她的浏览器会在其请求报文中继续放入首部行 cookie: 1678。Amazon 将根据 Susan 过去在 Amazon 访问的网页向她推荐产品。如果 Susan 也在 Amazon 注册过，即提供了她的全名、电子邮件地址、邮政地址和信用卡账号，则 Amazon 能在其数据库中包括这些信息，将 Susan 的名字与识别码相关联（以及她在过去访问过的本站点的所有页面） 这就解释了 Amazon 和其他一些电子商务网站实现"点击购物" (one-click shopping) 的道理，即当 Susan 在后继的访问中选择购买某个物品时，她不必重新输入姓名、信用卡账号或者地址等信息了。
从上述讨论中我们看到， cookie 可以用于标识一个用户。用户首次访问一个站点时，可能需要提供一个用户标识(可能是名字)。在后继会话中，浏览器向服务器传递一个 cookie 首部，从而向该服务器标识了用户。因此 cookie 可以在无状态的 HTTP 之上建立一个用户会话层。例如，当用户向一个基于 Web 的电子邮件系统(如 Hotmail) 注册时，浏览器向服务器发送 cookie 信息，允许该服务器在用户与应用程序会话的过程中标识该用户。
2.2.5 Web 缓存
Web 缓存器（Web cache）也叫代理服务器，它是能够代表初始 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 (例如Comcast) 可能在它的网络上安装一台或多台 Web 缓存器，并且预先配置其配套的浏览器指向这些缓存器。
在因特网上部署 Web 缓存器有两个原因。
① Web 缓存器可以大大减少对客户请求的响应时间，特别是当客户与初始服务器之间的瓶颈带宽远低于客户与 Web 缓存器之间的瓶颈带宽时更是如此。如果在客户与 Web 缓存器之间有一个高速连接(情况常常如此) ，并且如果用户所请求的对象在 Web 缓存器上，则 Web 缓存器可以迅速将该对象交付给用户。
② 如我们马上用例子说明的那样， Web 缓存器能够大大减少一个机构的接入链路到因特网的通信量。通过减少通信量，该机构(如一家公司或者一所大学)就不必急于增加带宽，因此降低了费用。此外， Web 缓存器能从整体上大大减低因特网上的 Web 流量，从而改善了所有应用的性能
考虑在图 2-12 场景下的例子：该图显示了两个网络，即机构（内部）网络和公共因特网的一部分。机构网络是一个高速的局域网，它的一台路由器与因特网上的一台路由器通过一条 15Mbps 的链路连接。这些初始服务器与因特网相连但位于全世界各地。假设对象的平均长度为 1 Mb ，从机构内的浏览器对这些初始服务器的平均访问速率为每秒 15 个请求。假设 HTTP 请求报文小到可以忽略，因而不会在网络中以及接入链路（从机构内部路由器到因特网路由器）上产生什么通信量。 我们还假设在图 2-12 中从因特网接入链路一侧的路由器转发 HTTP 请求报文(在一个IP数据报中)开始，到它收到其响报文(通常在多个IP 数据报中)为止的时间平均为 2秒。我们非正式地将该悖续时延称为" 因特网时延 "
总的响应时间，即从浏览器请求一个对象到接收到该对象为止的时间，是局域网时延、接入时延（两台路由器之间的时延）和因特网时延之和。
粗略估算这个时延
局域网上的流量强度为 （15个请求/s）*（1Mb/请求）/（100Mbps）=0.15
接入链路上的流量强度（从因特网路由器到机构路由器）为（15个请求/s）*（1Mb/请求）/（15Mbps）= 1
局域网上强度为 0.15 的通信量通常最多导致数十毫秒的时延，因此可以忽略局域网时延。然而，如果流量强度接近 1（如2-12接入链路那样），链路上的时延会变得非常大并且无限增长。因此，满足请求的平均响应时间将在分钟级上。
一个可能的解决办法就是增加接入链路的速率，如从 15Mbp 增加到 100 Mbps。这可以将接入链路上的流量强度减少到 0.15，这样一来 ，两台路由器之间的链路时延也可以忽略了。这时，总的响应时间将大约为 2 秒，即为因特网时延 但这种解决方案也意味着该机构必须将它的接入链路由 15 Mbps 升级 100 Mbp ，这是一种代价很高的方案。
考虑一种解决方案，不升级链路带宽而是在机构网络中安装一个 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秒）
这略大于 1.2 秒。因此，第二种解决方法提供的响应时延会比第一张解决方法低，也不需要该机构升级它到因特网的链路。
通过使用内容分发网络（CDN），Web 缓存器正在因特网中发挥着越来越重要的作用。CDN 公司在因特网上安装了许多地理上分散的缓存器，因而使大量流量实现了本地化。有多个共享的 CDN （例如 Akamai 和 Limelight）和专用的 CDN（如谷歌和 Netflix）。
2.2.6 条件 GET 方法
尽管高速缓存能减少用户感受到的响应时间，但也引入了一个新的问题，即存放在缓存器中的对象副本可能是陈旧的。换句话说，保存在服务器中的对象自该副本缓存在客户上以后可能已经被修改了。幸运的是，HTTP 协议有一种机制，允许缓存器证实它的对象是最新的。这种机制就是条件 GET (conditional GET) 方法。如果: ① 请求报文使用 GET 方法; 并且 ② 请求报文中包含一个"If-Modìfied-Since : "首都行。那么，这个 HTTP 请求报文就是一个条件 GET 请求报文。
说明 GET 方法的操作方式。看一个例子，首先，一个代理缓存器代表一个请求浏览器，向某 Web 服务器发送一个请求报文：
GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
其次，该 Web 服务器向缓存器发送具有被请求的对象的响应报文：
HTTP/1.1 200 OK
Date : Sat, 3 Oct 2015 1.5:39:29
Server: Apache/l.3 . 0 (Unix)
Last-Modified: Wed , 9 Sep 2015 09 :23:24
Content-Type : image/gif
(data data data data data ...)
该缓存器在将对象转发到请求的浏览器的同时，也在本地缓存了该对象。重要的是，缓存器在存储该对象时也存储了最后修改日期。最后，一个星期后，另一个用户经过该缓存器请求同一个对象，该对象仍在这个缓存器中。由于在过去的一个星期中位于 Web 服务器上的该对象可能已经被修改了，该缓存器通过发送一个条件 GET 执行最新检查。具体来说，该缓存器发送：
GET /fruit/kiwi . gif HTTP /1 .1
Host: www.exotiquecuisine . com
If-modified-since: Wed , 9 Sep 2015 09 : 23 : 24
值得注意的是 If-Modified-since：首部行的值正好等于一星期前服务器发送的响应报文中的Last-Modified：首部行的值。该条件 GET 报文告诉服务器，仅当自指定日期之后该对象被修改过，才发送该对象。假设该对象自 2015 年 9月 9日09：23：24 后没有修改。接下来第四步，Web 服务器向该缓存器发送一个响应报文：
HTTP/l . l 304 Not Modified
Date: Sat, 10 Oct 2015 15 : 39 : 29
Server: Apache/l . 3 . 0 (Unix)
(empty entity body)
我们看到，作为对该条件 GET 方法的响应，该 Web 服务器仍发送一个响应报文，但并没有在该响应报文中包含所请求的对象。包含该对象只会浪费带宽，并增加用户感受到的响应时间，特别是如果该对象很大的时候更是如此。值得注意的是在最后的响应报文中，状态行中为 304 Not Modified ，它告诉缓存器可以使用该对象，能向请求的浏览器转发它(该代理缓存器)缓存的该对象副本。
2.3 因特网中的电子邮件
图 2-14 给出了因特网电子邮件系统的总体情况。从该图中看到有 3 个主要组成部分：用户代理（user agent）、邮件服务器（mail server）和 简单邮件传输协议（SMTP）。
结合发送方 Alice 发电子邮件给接收方 Bob 的场景，对每个组成部分进行描述。用户代理允许用户阅读、回复、转发、保存和撰写报文。微软的 Outlook 和 Apple Mail 是电子邮件用户代理的例子。当 Alice 完成邮件撰写时，她的邮件代理向其邮件服务器发送邮件，此时邮件放在邮件服务器的外出报文队列中。Bob 要阅读报文时，他的用户代理在其邮件服务器的箱中取得该报文。
邮件服务器形成了电子邮件体系结构的核心。每个接收方(如 Bob) 在其中的某个邮件服务器上有一个邮箱( mailbox ) 。Bob 的邮箱管理和维护着发送给他的报文。一个典型的邮件发送过程是：从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中。Bob 要在他的邮箱中读取该报文时，包含他邮箱的邮件服务器（使用用户名和口令）来鉴别 Bob。Alice 的邮箱也必须能处理 Bob 的邮件服务器的故障。如果Alìce 的服务器不能将邮件交付给 Bob 的服务器，Alice 的邮件服务器在一个报文队列 (message queue) 中保持该报文并在以后尝试再次发送。通常每 30 分钟左右进行一次尝试；如果几天后仍不能成功，服务器就删除该报文并以电子邮件的形式通知发送方 (Alice)。
SMTP 是因特网电子邮件中主要的应用层协议。它使用 TCP 可靠数据传输服务，从发送方的邮件服务器向接收方的邮件服务器发送邮件。像大多数应用层协议一样， SMTP 有两个部分：运行在发送方邮件服务器的客户端 和 运行在接收方邮件服务器的服务器端 。每台邮件服务器上既运行 SMTP 的客户端也运行 SMTP 的服务器端。当一个邮件服务器向其他邮件服务器发送邮件时， 它就表现为 SMTP 的客户；当邮件服务器从其他邮件服务器上接收邮件时，它就表现为一个 SMTP 的服务器。
2.3.1 SMTP
SMTP 是因特网电子邮件的核心。如前所述，SMTP 用于从发送方的邮件服务器发送报文到接收方的邮件服务器。SMTP 问世的时间比 HTTP 要长得多（初始的 SMTP 协议的 RFC 可追溯到 1982 年，而 SMTP 在此之前很长一段时间就已经出现了）尽管电子邮件应用在因特网上的独特地位可以证明 SMTP 有着众多非常出色的性质，但它所具有的某种陈旧特征表明它仍然是一种继承的技术。例如，它限制所有邮件报文的体部分（不只是其首部）只能采用简单的 7 比特 ASCII 表示。20 世纪 80 年代早期，这种限制是明智的，因为当时传输能力不足，没有人会通过电子邮件发送大的附件或是大的图片、声音或者视频文件。然而，在今天的多媒体时代，ASCII 的限制的确有点痛苦，即在用 SMTP 传送邮件之前，需要将二进制多媒体数据编码为 ASCII 码，并且在使用 SMTP 传输后要求将相应的 ASCII 码邮件解码还原为多媒体数据。2.2 节讲过，使用 HTTP 传送前不需要将多媒体数据编码为 ASCII 码。
描述 SMTP 的基本操作，观察一种常见的情景。假设Alice 给 Bob 发送一封简单的ASCII报文
1) Alice 调用她的邮件代理程序并提供 Bob 的邮件地址(例如 bob@ someschool. edu) , 撰写报文，然后指示用户代理发送该报文。
2) Alice 的用户代理把报文发给她的邮件服务器，在那里该报文被放在报文队列中。
3) 运行在 Alice 的邮件服务器上的 SMTP 客户端发现了报文队列中的这个报文，它就创建一个到运行在 Bob 的邮件服务器上的 SMTP 服务器的 TCP 连接。
4) 在经过一些初始 SMTP 握手后， SMTP 客户通过该 TCP 连接发送 Alice 的报文。
5) Bob 的邮件服务器上， SMTP 的服务器端接收该报文 Bob 的邮件服务器然后将该报文放入 Bob 的邮箱中。
6）在 Bob 方便的时候，他调用用户代理阅读该报文。
观察到下述现象是重要的：SMTP 一般不使用中间邮件服务器发送邮件，即使这两个邮件服务器位于地球的两端也是这样。假设 Alice 的邮件服务器在中国香港，而 Bob 的服务器在美国圣路易斯，那么这个 TCP 连接也是从香港服务器到圣路易斯服务器之间的直接相连。特别是，如果 Bob 的邮件服务器没有开机，该报文会保留在 Alice 的邮件服务器上并等待进行新的尝试，这意味着邮件并不在中间的某个邮件服务器存留。
仔细观察：SMTP 是如何将一个报文从发送邮件服务器传送到接收邮件服务器的。将看到， SMTP 与人类面对面交往的行为方式有许多类似性。首先，客户 SMTP （运行在发送邮件服务器主机上）在 25 号端口建立一个到服务器SMTP (运行在接收邮件服务器主机上)的 TCP 连接。如果服务器没有开机，客户会在稍后继续尝试连接。一旦连接建立，服务器和客户执行某些应用层的握手，就像人们在互相交流前先进行自我介绍一样。SMTP 的客户和服务器在传输信息前先相互介SMTP 握手的阶段， SMTP 客户指示发送方的邮件地址(产生报文的那个人)和接收方的邮件地址。 一旦该 SMTP 客户和服务器彼此介绍之后，客户发送该报文 SMTP 能依赖 TCP 提供的可靠数据传输无差错地将邮件投递到接收服务器。该客户如果有另外的报文要发送到该服务器，就在该相同的 TCP 连接上重复这种处理；否则，它指示 TCP 关闭连接。
分析一个在 SMTP 客户（C）和 SMTP 服务器（S）之间交换报文的例子。客户的主机名为 crepes.fr，服务器的主机名为 hamburger.edu。以C：开头的 ASCII 码文本行正是客户交给其 TCP 套接字的那些行，以 S：开头的 ASCII 码则是服务器发送给其 TCP 套接字的那些行。一旦创建了 TCP 连接，就开始了下列过程。
在上例中，客户从邮件服务器 crepes. fr 向邮件服务器 hamburger. edu 发送了一个报文( "Do you like ketchup? How about pìckles? " )。作为对话的一部分，该客户发送了5 条命令：HELO (是 HELLO 的缩写)、 MAIL FROM、RCPT TO、DATA 以及 QUIT 。这些命令都是自解释的。该客户通过发送一个只包含一个句点的行，向服务器指示该报文结束了(按照 ASCII 码的表示方法，每个报文以 CRLF CRLF 结束，其中的 CR 和 LF 分别表示回车和换行）服务器对每条命令做出回答，其中每个回答含有一个回答码和一些(可选的)英文解释。我们在这里指出 SMTP 用的是持续连接：如果发送邮件服务器有几个报文发往同一个接收邮件服务器，它可以通过同一个 TCP 连接发送这些所有的报文。对每个报文，该客户用一个新的 MAIL FROM: crepes. fr 开始，用一个独立的句点指示该邮件的结束，并且仅当所有邮件发送完后才发送 QUIT。
强烈推荐使用 Telnet 与 一个 SMTP 服务器进行一次直接对话。使用的命令是
telnet serverName 25
其中 serverName 是本地邮件服务器的名称。当你这么做时，就直接在本地主机与邮件服务器之间建立一个 TCP 连接。输完上述命令后，你立即会从该服务器收到 220 回答。接下来，在适当的时机发出 HELO、MAIL FROM、RCPT TO、DATA、CRLF. CRLF 以及 QUIT 等SMTP 命令。
2.3.2 与 HTTP 的对比
比较 SMTP 和 HTTP。这两个协议都用于从一台主机向另一台主机传送文件：
HTTP 从 Web 服务器向 Web 客户（通常是一个浏览器）传送文件（也称对象）；SMTP 从一个邮件服务器向另一个邮件服务器传送文件（即电子邮件报文）。当进行文件传送时，持续的 HTTP 和 SMTP 都使用持续连接。因此，两个协议有一些共同特征。然而也有一些区别：
① HTTP 主要是一个拉协议，即在方便的时候，某些人在 Web 服务器上装载信息，用户使用 HTTP从该服务器拉取这些信息。特别是 TCP 连接是由想接收文件的机器发起的。另一方面，SMTP 基本上是一个推协议，即发送邮件服务器把文件推向接收服务器。特别是，这个 TCP 连接是由要发送该文件的机器发起的。
② SMTP 要求每个报文(包括它们的体)采用 7 比特 ASCII 码格式。如果某报文包含了非 7 比特 ASCII 字符(如具有重音的法文字符) 或 二进制数据(如图形文件) ，则该报文必须按照 7 比特 ASCII 码进行编码。 HTTP据则不受这种限制。
③ 如何处理一个既包含文本又包含图形(也可能是其他媒体类型)的文档。如我们在 2.2 节知道的那样， HTTP 把每个对象封装到它自己的 HTTP 响应报文中，SMTP 则把所有报文对象放在一个报文之中。
2.3.3 邮件报文格式
当 Alice 给 Bob 写一封邮寄时间很长的普通信件时，她可能要在信的上部包含各种各样的环境首部信息，如 Bob 的地址、她自己的回复地址以及日期等。同样，当一个人给另个人发送电子邮件时，一个包含环境信息的首部位于报文体前面。这些环境信息包括在系列首部行中，这些行由 RFC 5322 定义。首部行和该报文的体 用空行(即回车换行〉进行分隔。RFC 5322 定义了邮件首部行和它们的语义解释的精确格式。如同 HTTP 协议，每个首都行包含了可读的文本，是由关键词后跟冒号及其值组成的。某些关键词是必需的，另一些则是可选的。每个首部必须含有一个 From 首部行和一个 To 首部行；一个首部也许包含一个 Subject: 首部行以及其他可选的首部行。重要的是注意到下列事实：这些首部行不同于我们在 2.3.1 节所学到的 SMTP 命令(即使那里包含了某些相同的词汇，from 和 to) 那节中的命令是 SMTP 握手协议的一部分；本节中考察的首部行则是邮件报文自身的一部分。
一个典型的报文首部看起来如下：
From：alice@crepes.fr
TO：bob@hamburger.edu
Subject：Searching for the meaning of life.
在报文首部之后，紧接着一个空白行，然后是以 ACSII 格式表示的报文体。应当用 Telnet 向邮件服务器发送包含一些首部行的报文，包括 Subject：首部行。为此，输入命令 telnet serverName 25。
2.3.4 邮件访问协议
一旦 SMTP 将邮件报文从 Alice 的邮件服务器交付给 Bob 的邮件服务器，该报文就被放入了 Bob 的邮箱中。在此讨论中，我们按惯例假定 Bob 是通过登录到服务器主机，并直接在该主机上运行一个邮件阅读程序来阅读他的邮件的。直到 20 世纪 90 年代早期，这都是一种标准方式。而在今天，邮件访问使用了一种客户——服务器体系结构，即典型的用户通过在用户端系统上运行的客户程序来阅读电子邮件，这里的端系统可能是办公室的 PC、便携机或者是智能手机。通过在本地主机上运行邮件客户程序，用户享受一系列丰富的特性，包括查看多媒体报文和附件的能力。
假设 Bob（接收方）在其本地 PC 上运行用户代理程序，考虑在他的本地 PC 上也放置一个邮件服务器是自然而然的事。这种情况下，Alice 的邮件服务器就能直接与 Bob 的 PC 进行对话了。然而这种方法会有一个问题，前面讲过邮件服务器管理用户的邮箱，并且运行 SMTP 的客户端和服务器端。如果 Bob 的邮件服务器位于他的 PC上，那么为了能够及时接收可能在任何时候到达的新邮件，他的 PC 必须总是不间断地运行着并一直保持在线。这对于许多因特网用户而是不现实的。相反，典型的用户通常在本地 PC 上运行一个用户代理程序，而它访问存储在总保持开机的共享邮件服务器上的邮箱。该邮件服务器与其他用户共享， 并且通常由用户的 ISP 进行维护(如大学或公司)
现在我们考虑当从Alice 向 Bob 发送一个电子邮件报文时所取的路径。我们刚才已知道，在沿着该路径的某些点上，需要将电子邮件报文存放在 Bob 的邮件服务器上，通过让Alice 的用户代理直接向 Bob 的邮件服务器发送报文，就能够做到这一点。 这能够由SMTP 来完成：实际上， SMTP 被设计成将电子邮件从一台主机推到另一台主机。然而，通常 Alice 的用户代理和 Bob 的邮件服务器之间并没有一个直接的 SMTP 对话。相反，如图2-16 所示， Alice 的用户代理用 SMTP 将电子邮件报文推入她的邮件服务器，接着她的邮件服务器(作为一个 SMTP 客户)再用 SMTP 将该邮件中继到 Bob 的邮件服务器。为什么该过程要分成两步呢？主要是因为不通过Alice 的邮件服务器进行中继， Alice 的用户代理将没有任何办法到达一个不可达的目的地接收服务器。通过首先将邮件存放在自己的邮件服务器中， Alice 的邮件服务器可以重复地尝试向 Bob 的邮件服务器发送该报文，如每 30 分钟一次，直到 Bob 的邮件服务器变得运行为止 (并且如果 Alice 的邮件服务器关机，她则能向系统管理员进行申告!) SMTP RFC 文档定义 如何使用 SMTP 命令经过多个SMTP 服务器进行报文中继。
像 Bob 这样的接收方，是如何通过运行其本地 PC 上的用户代理，获得位于他的某 ISP 的邮件服务器上的邮件呢？值得注意的是 Bob 的用户代理不能使用 SMTP 得到报文，因为取报文是个拉操作，而 SMTP 协议是一个推协议。通过引入一个特殊的邮件访问协议来解决这个难题，该协议将 Bob 邮件服务器上的报文传送给他的本地 PC。目前有一些流行的邮件访问协议，包括第三版的邮局协议( Post ~ce Protocol Version 3 , POP3）、因特网邮件访问协议 （Internet Mail Access Protocol IMAP) 以及 HTTP。
图 2-16 总结了应用于因特网电子邮件的一些协议：SMTP 用来将邮件从发送方的邮件服务器传输到接收方的邮件服务器; SMTP 也用来将邮件从发送方的用户代理传送到发送方的邮件服务器。 POP3这样的邮件访问协议用来将邮件从接收方的邮件服务器传送到接收方的用户代理
1. POP3
POP3 是一个极为简单的邮件访问协议。因为该协议非常简单，故其功能相当有限。当用户代理（客户）打开了一个到邮件服务器（服务器）端口 110 上的 TCP 连接后， POP3就开始工作了。随着建立 TCP 连接， POP3 按照三个阶段进行工作：特许( authorization ) 、事务处理以及更新。在第一个阶段即特许阶段，用户代理发送（以明文形式）用户名和口令以鉴别用户。在第二个阶段即事务处理阶段，用户代理取回报文；同时在这个阶段用户代理还能进行如下操作，对报文做删除标记，取消报文删除标记，以及获取邮件的统计信息。在第三个阶段即更新阶段，它出现在客户发出了 quit 命令之后，目的是结束该 POP3 会话；这时，该邮件服务器删除那些被标记为删除的报文。
在 POP3 的事务处理过程中，用户代理发出一些命令，服务器对每个命令做出回答。回答可能有两种：+OK（有时后面还跟有服务器到客户的数据），被服务器用来指示前面的命令是正常的；-ERR，被服务器用来指示前面的命令出现了某些差错。
特许阶段有两个主要的命令：user < user name >和 pass < password >。 为了举例说明这两个命令，建议直接用 Telnet 登录到 POP3 服务器的 110 端口，然后发出这两个命令。假设邮件服务器的名字为 mailServer ，将看到类似的过程：
如果命令拼写错误，该 POP3 服务器将返回一个 -ERR 报文。
事务处理过程：使用 POP3 的用户代理通常被用户配置为“ 下载并删除 ” 或者 “ 下载并保留 ”方式。 POP3 用户代理发出的命令序列取决于用户代理程序被配置为这两种工作方式的哪一种。使用下载并删除方式：用户代理发出 list、retr 和 dele 命令。举例来说，假设用户在他的邮箱里有两个报文。在下面的对话中，C：（代表客户）是用户代理，S：（代表服务器）是邮件服务器。事务处理过程如下所示：
用户代理首先请求邮件服务器列出所有存储的报文长度。接着用户代理从邮件服务器取回并删除每封邮件。在特许阶段后，用户代理仅使用四个命令 list、retr、dele 和 quit，这些命令的语法定义在 RFC1939中。在处理 quit 命令后，POP3 服务器进入新阶段，从用户的邮箱中删除邮件1和 2。
使用下载并删除方式存在的问题是，邮件接收方 Bob 可能是移动的，可能希望从多个不同的机器访问他的邮件报文，如从办公室的 PC、家里的 PC 或他的便携机来访问邮件。下载并删除方式将对 Bob 的邮件报文根据这 3 台机器进行划分，特别是如果 Bob 最先是在他办公室的 PC 上收取了一条邮件，那么晚上当他在家里时，通过他的便携机将不能再收取该邮件。使用下载并保留方式，用户代理下载某邮件后，该邮件仍保留在邮件服务器上。这时， Bob 就能通过不同的机器重新读取这些邮件；他能在工作时收取一封报文，而在工作回家后再次询问它。
在用户代理与邮件服务器之间的 POP3 会话期间，该 POP3 服务器保留了一些状态信息；特别是记录了哪些用户报文被标记为删除了。然而， POP3 服务器并不在 POP3 会话过程中携带状态信息。会话中不包括状态信息大大简化了 POP3 服务的实现。
2. IMAP
使用 POP3 访问时，一旦 Bob 将邮件下载到本地主机 ，他就能建立邮件文件夹，并将下载的邮件放入该文件夹中。然后 Bob 可以删除报文，在文件夹之间移动报文并查询报文（通过发送方的名字或报文主题） 但是这种文件夹和报文存放在本地主机上的方式，会给移动用户带来问题，因为他更喜欢使用一个在远程服务器上的层次文件夹，这样他可以从任何一台机器上对所有报文进行访问。使用 POP3 是不可能做到这一点的， POP3 协议没有给用户提供任何创建远程文件 并为报文指派文件夹的方法。
为了解决这个问题，因特网邮件访问协议（IMAP）产生了，比 POP3 复杂的多。
IMAP 服务器把每个报文与一个文件夹联系起来；当报文第一次到达服务器时，它与收件人的 lNBOX 文件夹相关联。收件人则能够把邮件移到一个新的、用户创建的文件夹中，阅读邮件，删除邮件等。IMAP 协议为用户提供了创建文件夹以及将邮件从一个文件夹移动到另一个文件夹的命令。IMAP 还为用户提供了在远程文件夹中查询邮件的命令，按指定条件去查询匹配的邮件。值得注意的是，与 POP3 不同， IMAP 服务器维护了 IMAP 会话的用户状态信息，例如，文件夹的名字以及哪些报文与哪些文件夹相关联。
IMAP 的另一个重要特性是它具有允许用户代理获取报文某些部分的命令。例如，一个用户代理可以只读取一个报文的报文首部，或只是一个多部分 MIME 报文的一部分。用户代理和其邮件服务器之间使用低带宽连接(如一个低速调制解调器链路)的时候，这个特性非常有用。使用这种低带宽连接时，用户可能并不想取回他邮箱中的所有邮件，尤其要避免可能包含如音频或视频片断的大邮件。
3. 基于 Web 的电子邮件
使用这种 Web 服务，用户代理就是普通的浏览器，用户和他远程邮箱之间的通信则通过 HTTP 进行。当一个收件人(如 Bob) ，想从他的邮箱中访问一个报文时，该电子邮件报文从 Bob 的邮件服务器发送到他的浏览器，使用的是 HTTP 而不是 POP3 或者 lMAP 协议。当发件人(如 Alice) 要发送一封电子邮件报文时，该电子邮件报文从 Alice 的浏览器发送到她的邮件服务器，使用的是 HTTP而不是 SMTP。然而， Alice 的邮件服务器在与其他的邮件服务器之间发送和接收邮件时，仍然使用的是 SMTP。