计算机系统方法：9.1传统应用

我们开始讨论应用程序，重点是两个最流行的应用程序--万维网和电子邮件。广义上讲，这两种应用都使用了请求/回复范式--用户向服务器发送请求，然后服务器做出相应的回应。我们把这些称为 "传统 "应用，因为它们是自计算机网络早期就存在的那种应用的典型（尽管万维网比电子邮件要新得多，但它的根源是在它之前的文件传输）。相比之下，后面的章节将探讨最近流行的一类应用：流媒体应用（如视频和音频等多媒体应用）和各种基于叠加的应用。(请注意，这些类别之间有点模糊，因为你当然可以通过网络获得流式多媒体数据，但现在我们将重点放在网络的一般使用上，以请求网页、图像等）。

在仔细研究这些应用中的每一个之前，我们需要提出三个一般的观点。首先，区分应用程序和应用协议是很重要的。例如，超文本传输协议（HTTP）是一个应用协议，用于从远程服务器检索网页。许多不同的应用程序--即像Internet Explorer、Chrome、Firefox和Safari这样的网络客户端--为用户提供了不同的外观和感觉，但它们都使用相同的HTTP协议，通过互联网与网络服务器通信。事实上，正是由于该协议的发布和标准化，使得由许多不同的公司和个人开发的应用程序能够相互操作。这就是为什么这么多的浏览器能够与所有的网络服务器（其中也有很多种类）进行互操作。

本节将讨论两个非常广泛使用的标准化应用协议。

简单邮件传输协议（SMTP）是用来交换电子邮件的。

超文本传输协议（HTTP）被用来在网络浏览器和网络服务器之间进行通信。

其次，我们观察到许多应用层协议，包括HTTP和SMTP，都有一个配套的协议，规定了可以交换的数据的格式。这也是这些协议相对简单的原因之一。大部分的复杂性在这个配套的标准中得到了管理。例如，SMTP是一个交换电子邮件信息的协议，但RFC 822和多用途互联网邮件扩展（MIME）定义了电子邮件信息的格式。同样，HTTP是一个获取网页的协议，但超文本标记语言（HTML）是一个配套的规范，定义了这些网页的基本形式。

最后，由于本节描述的应用协议遵循相同的请求/回复通信模式，你可能会认为它们会建立在远程过程调用（RPC）传输协议之上。然而，情况并非如此，因为它们是在TCP之上实现的。实际上，每个协议都在一个可靠的传输协议（TCP）之上重新发明了一个简单的类似RPC的机制。我们说 "简单 "是因为每个协议都不是为了支持前一章讨论的那种任意的远程过程调用，而是为了发送和响应一组特定的请求信息。有趣的是，HTTP采取的方法被证明是相当强大的，这导致它被Web服务架构广泛采用，一般的RPC机制建立在HTTP之上，而不是反过来。本节末尾会有更多关于这个主题的内容。

9.1.1 电子邮件（SMTP、MIME、IMAP）

电子邮件是最古老的网络应用之一。毕竟，还有什么比想给你刚刚成功运行的跨国链路的另一端的用户发送消息更自然的呢？这是20世纪的 "华生先生，过来......我想见你 "的版本。令人惊讶的是，ARPANET的先驱们在创建该网络时并没有真正设想过将电子邮件作为一个关键的应用--远程访问计算资源是主要的设计目标，但它却成为了互联网最初的杀手级应用。

如上所述，重要的是（1）将用户界面（即你的邮件阅读器）与底层消息传输协议（如SMTP或IMAP）区分开来，以及（2）区分该传输协议与定义正在交换的消息格式的配套标准（RFC 822和MIME）。我们首先看一下消息格式。

消息格式

RFC 822定义的消息有两个部分：一个头和一个主体。这两部分都用ASCII文本表示。最初，正文被认为是简单的文本。尽管RFC 822已经被MIME增强，允许信息体携带各种数据，但情况仍然如此。这些数据仍然表示为ASCII文本，但由于它可能是一个编码版本，例如JPEG图像，它不一定能被人类用户阅读。稍后会有更多关于MIME的内容。

消息头是一系列以为结尾的行。(代表回车和换行，这是一对ASCII控制字符，通常用来表示文本行的结束。) 报头与邮件正文之间有一个空行。每一个标题行包含一个类型和值，用冒号隔开。这些标题行中有许多是用户所熟悉的，因为他们在撰写电子邮件时被要求填写这些标题；例如，标题确定了邮件的收件人，标题说了一些关于邮件的目的。其他标题是由底层的邮件发送系统填写的。例如，（该信息何时被传送），（什么用户发送了该信息），以及（处理该信息的每个邮件服务器）。当然，还有许多其他头行；感兴趣的读者可以参考RFC 822。

RFC 822在1993年进行了扩展（此后又进行了多次更新），允许电子邮件携带许多不同类型的数据：音频、视频、图像、PDF文档等等。MIME由三个基本部分组成。第一部分是一个头行的集合，增加了RFC 822所定义的原始头行。这些头行以各种方式描述了消息体中携带的数据。它们包括（正在使用的MIME版本）、（对消息中内容的可读描述，类似于行）、（消息中包含的数据类型）和（消息体中的数据是如何编码的）。

第二块是对一组内容类型（和子类型）的定义。例如，MIME定义了几种不同的图像类型，包括image/gif和image/jpeg，每种都有明显的含义。再比如，text/plain指的是简单的文本，你可能会在一个普通的822风格的信息中发现，而text/richtext表示一个包含 "标记 "文本的信息（使用特殊字体、斜体的文本等）。作为第三个例子，MIME定义了一个应用程序类型，其中的子类型对应于不同应用程序的输出（例如，应用程序/postscript和应用程序/msword）。

MIME还定义了一个多部分类型，说的是携带一种以上数据类型的信息如何结构化。这就像一种编程语言，定义了基本类型（如整数和浮点数）和复合类型（如结构和数组）。一个可能的多部分子类型是混合型，它说消息包含一组按指定顺序排列的独立数据片。然后每块都有自己的标题行，描述该块的类型。

第三部分是对各种数据类型进行编码的方法，以便它们可以在ASCII电子邮件中被发送。问题是，对于某些数据类型（例如，JPEG图像），图像中的任何给定的8位字节可能包含256个不同的值之一。这些值中只有一个子集是有效的ASCII字符。电子邮件只包含ASCII是很重要的，因为它们可能会通过一些中间系统（网关，如下所述），这些系统认为所有的电子邮件都是ASCII，如果包含非ASCII字符，就会破坏信息。为了解决这个问题，MIME使用了一种直接将二进制数据编码为ASCII字符集的方法。这种编码被称为base64。其原理是将原始二进制数据的每三个字节映射成四个ASCII字符。这是通过将二进制数据分组为24位单元，并将每个单元分成4个6位片断来实现的。每个6位片断映射到64个有效的ASCII字符中的一个；例如，0映射到A，1映射到B，以此类推。如果你看一个使用base64编码方案的信息，你会注意到只有52个大写和小写字母，10个数字0到9，以及特殊字符+和/，这些是ASCII字符集的前64个值。

作为一个旁观者，为了使那些仍然坚持使用纯文本邮件阅读器的人在阅读邮件时尽可能不感到痛苦，一个仅由普通文本组成的MIME邮件可以使用7位ASCII编码。还有一种可读的编码，主要用于ASCII数据。

把这些放在一起，一个包含一些纯文本、JPEG图像和PostScript文件的信息看起来会是这样的。