计算机网络—应用层

本文基于《计算机网络自定向下》以及作者在学习计算机网络的总结，且当作自我学习的笔记

计算机网络的三种交换方式

电路交换

报文交换

分组交换

电路交换 报文交换 分组交换之间的对比

计算机网络的定义

计算机网络的分类

计算机网络的性能指标

速率

带宽

吞吐量

时延

时延带宽积

往返时间

利用率

丢包率

计算机网络体系结构

应用层

应用层协议原理

研发网络应用程序的核心是写出能够运行在不同的端系统和通过网络彼此通信的程序。

例如，在Web应用程序中，有两个互相通信的不同的程序：一个是运行在用户主机（桌面机、膝上机、平板电脑、智能电话等）上的浏览器程序；另一个是运行在Web服务器主机上的Web服务器程序。另一个例子是P2P文件共享系统，在参与文件共享的社区中的每台主机中都有一个程序。

在这种情况下，在各台主机中的这些程序可能都是类似的或相同的。因此，当研发新应用程序时，你需要编写将在多台端系统上运行的软件。该软件能够用如C、Java或Python来编写。重要的是，你不需要写在网络核心设备如路由器或链路层交换机上运行的软件。即使你要为网络核心设备写应用程序软件，你也不能做到这一点。如我们在第1章所知，以及如图1・24所显示的那样，网络核心设备并不在应用层上起作用，而仅在较低层起作用，特别是在网络层及下面层次起作用。

网络应用程序体系结构

应用程序体系结构 (application architecture) 由应用程序研发者设计,规定了如何在各种端系统上组织该应用程序。在选择应用程序体系结构时，应用程序研发者很可能利用现代网络应用程序中所使用的两种主流体系结构之一：

客户-服务器体系结构或对等（ P2P）体系结构。

客户-服务器体系结构（client-server architecture）

有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。一个典型的例子是Web应用程序，其中总是打开的Web服务器服务于来自浏览器（运行在客户主机上）的请求。当Web服务器接收到来自某客户对某对象的请求时，它向该客户发送所请求的对象作为响应。

值得注意的是利用客户-服务器体系结构，客户相互之间不直接通信；例如，在Web应用中两个浏览器并不直接通信。客户-服务器体系结构的另一个特征是该服务器具有固定的、周知的地址，该地址称为IP地址（我们将很快讨论它）。因为该服务器具有固定的、周知的地址，并且因为该服务器总是打开的，客户总是能够通过向该服务器的IP地址发送分组来与其联系。具有客户-服务器体系结构的非常著名的应用程序包括Web、FTP、Telnet和电子邮件。

P2P 体系结构

（P2P architecture）

对位于数据中心的专用服务器有最小的（或者没有）依赖。相反，应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方这些对等方并不为服务提供商所有，相反却为用户控制的桌面机和膝上机所有，大多数对等方驻留在家庭、大学和办公室。因为这种对等方通信不必通过专门的服务器，该体系结构被称为对等方到对等方的。

许多目前流行的、流量密集型应用都是P2P体系结构的。

这些应用包括 文件共享（例如BitTorrent） x对等方协助下载加速器（例如迅雷）、因特网电话和视频会议（例如Skype）。

图中显示了 P2P的体系结构。需要提及的是，某些应用具有混合的体系结构，它结合了客户-服务器和P2P的元素。例如，对于许多即时讯息应用而言，服务器被用于跟踪用户的IP地址，但用户到用户的报文在用户主机之间（无须通过中间服务器）直接发送。例如qq邮箱

P2P体系结构的最引人入胜的特性之一是它们的自扩展性（self-scalability） 例如,在一个P2P文件共享应用中，尽管每个对等方都由于请求文件产生工作负载，但每个对等方通过向其他对等方分发文件也为系统增加服务能力。

P2P体系结构也是有成本效率的,因为它们通常不需要庞大的服务器基础设施和服务器带宽（这与具有数据中心的客户-服务器设计形成鲜明对比）。然而，未来P2P应用由于高度非集中式结构，面临安全性、性能和可靠性等挑战。

进程通信

在构建网络应用程序前，还需要对运行在多个端系统上的程序是如何互相通信的情况有一个基本了解。

用操作系统的术语来说，进行通信的实际上是进程（process）而不是程序。

一个进程可以被认为是运行在端系统中的一个程序。当多个进程运行在相同的端系统上时，它们使用进程间通信机制相互通信。

进程间通信的规则由端系统上的操作系统确定。而这，我们并不特别关注同一台主机上的进程间的通信，而关注运行在不同端系统（可能具有不同的操作系统）上的进程间的通信。

在两个不同端系统上的进程，通过跨越计算机网络交换报文（message）而相互通信。

发送进程生成并向网络中发送报文；接收进程接收这些报文并可能通过回送报文进行响应。

客户和服务器进程

网络应用程序由成对的进程组成，这些进程通过网络相互发送报文。

例如， 在Web应用程序中，一个客户浏览器进程与一台Web服务器进程交换报文。在一个P2P文件共享系统中，文件从一个对等方中的进程传输到另一个对等方中的进程。

对每对通信进程,我们通常将这两个进程之一标识为客户（client）,而另一个进程标识为服务器（serve”。对于Web而言，浏览器是一个客户进程，Web服务器是一台服务器进程。

对于P2P文件共享，下载文件的对等方标识为客户，上载文件的对等方标识为服务器。你或许已经观察到，如在P2P文件共享的某些应用中，一个进程能够既是客户又是服务器。在P2P文件共享系统中，一个进程的确既能上载文件又能下载文件。无论如何，在任何给定的一对进程之间的通信会话场景中，我们仍能将一个进程标识为客户，另一个进程标识为服务器。

我们定义客户和服务器进程如下：在一对进程之间的通信会话场景中，发起通信（ 即在该会话开始时发起与其他进程的联系）的进程被标识为客户，在会话开始时等待联系的进程是服务器

在Web中，一个浏览器进程向一台Web服务器进程发起联系，因此该浏览器进程是客户，而该Web服务器进程是服务器。

在P2P文件共享中， 当对等方A请求对等方B发送一个特定的文件时，在这个特定的通信会话中对等方A是客户，而对等方B是服务器。在不致混淆的情况下，我们有时也使用术语”应用程序的客户端和服务器端”

进程与计算机网络之间的接口

如上所述，多数应用程序是由通信进程对组成，每对中的两个进程互相发送报文。从一个进程向另一个进程发送的报文必须通过下面的网络。

进程通过一个称为套接字（sock,el）的软件接口向网络发送报文和从网络接收报文。进程可类比于一座房子，而它的套接字可以类比于它的门。

当一个进程想向位于另外一台主机上的另一个进程发送报文时，它把报文推出该门（套接字）。

该发送进程假定该门到另外一侧之间有运输的基础设施，该设施将把报文传送到目的进程的门口。

一旦该报文抵达目的主机，它通过接收进程的门（套接字）传递，然后接收进程对该报文进行处理。图2・3显示了两个经过因特网通信的进程之间的套接字通信（图2・3中假定由该进程使用的下面运输层协议是因特网的TCP协议）。如该图所示，套接字是同一台主机内应用层与运输层之间的接口。

由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为应用程序和网络之间的应用程序编程接口（Application Programming Interface, API）

应用程序开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层端几乎没有控制权。

应用程序开发者对于运输层的控制仅限于：① 选择运输层协议；②也许能设定几个运输层参数，如最大缓存和最大报文段长度等（将在第3章中涉及）。一旦应用程序开发者选择了一个运输层协议（如果可供选择的话），则应用程序就建立在由该协议提供的运输层服务之上。

进程寻址

为了向特定目的地发送邮政邮件，目的地需要有一个地址。

类似地，在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址。

为了标识该接收进程，需要定义两种信息：① 主机的地址；② 在目的主机中指定接收进程的标识符。

在因特网中，主机由其IP地址(IP address)标识。我将在后面非常详细地讨论IP地址。此时，我们只要知道IP地址是一个32比特的量且它能够唯一地标识该主机就够了。

除了知道报文发送目的地的主机地址外，发送进程还必须指定运行在接收主机上的接收进程(更具体地说，接收套接字)。

因为一般而言一台主机能够运行许多网络应用,这些信息是需要的。目的地端口号(port number)用于这个目的。已经给流行的应用分配了特定的端口号。

例如， Web服务器用端口号80来标识。邮件服务器进程(使用SMTP协议)用端口号25来标识。

用于所有因特网标准协议的周知端口号的列表能够在http:〃WWW. iana. org处找到。在后续中详细学习端口号

可供应用程序使用的运输服务

前面讲过套接字是应用程序进程和运输层协议之间的接口。

在发送端的应用程序将报文推进该套接字。在该套接字的另一侧，运输层协议负责从接收进程的套接字得到该报文。

包括因特网在内的很多网络提供了不止一种运输层协议。当开发一个应用时，必须选择一种可用的运输层协议。

如何做出这种选择呢？最可能的方式是，通过研究这些可用的运输层协议所提供的服务，选择一个最能为你的应用需求提供恰当服务的协议。这种情况类似于在两个城市间旅行时选择飞机还是火车作为交通工具。

每种运输模式为你提供不同的服务，你必须选择一种或另一种(例如，火车可以直到市区上客和下客，而飞机提供了更短的旅行时间)。

一个运输层协议能够为调用它的应用程序提供什么样的服务呢？我们大体能够从四个方面对应用程序服务要求进行分类： 可靠数据传输、吞吐量、定时和安全性

可靠数据传输

分组在计算机网络中可能丢失。

例如，分组能够使路由器中的缓存溢岀，或者当分组中的某些比特损坏后可能被丢弃。

像电子邮件、文件传输、远程主机访问、Web文档传输以及金融应用等这样的应用，数据丢失可能会造成灾难性的后果(在后一种情况下，无论对银行或对顾客都是如此！)。

因此，为了支持这些应用，必须做一些工作以确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端。

如果一个协议提供了这样的确保数据交付服务，就认为提供了可靠数据传输(reliable血tatransfer)

运输层协议能够潜在地向应用程序提供的一个重要服务是进程到进程的可靠数据传输。当一个运输协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据将能无差错地到达接收进程。

当一个运输层协议不提供可靠数据传输时，由发送进程发送的某些数据可能到达不了接收进程。

这可能能被容忍丢失的应用(loss-tolerant application)所接受，最值得注意的是多媒体应用，如交谈式音频/视频，它们能够承受一定量的数据丢失。在这些多媒体应用中，丢失的数据引起播放的音频/视频出现小干扰，而不是致命的损伤。

吞吐量

在第1章中我们引入了可用吞吐量的概念，在沿着一条网络路径上的两个进程之间的通信会话场景中，可用吞吐量就是发送进程能够向接收进程交付比特的速率。

因为其他会话将共享沿着该网络路径的带宽，并且因为这些会话将会到达和离开，该可用吞吐量将随时间波动。

这些观察导致另一种自然的服务，即运输层协议能够以某种特定的速率提供确60 第2章保的可用吞吐量。

使用这种服务，该应用程序能够请求厂比特/秒的确保吞吐量，并且该运输协议能够确保可用吞吐量总是为至少厂比特/秒。这样的确保吞吐量的服务将对许多应用程序有吸引力。

例如，如果因特网电话应用程序对语音以32kbps的速率进行编码，那么它需要以这个速率向网络发送数据，并以该速率向接收应用程序交付数据。如果运输协议不能提供这种吞吐量，该应用程序或以较低速率进行编码（并且接收足够的吞吐量以维持这种较低的编码速率），或它可能必须放弃发送.这是因为对于这种因特网电话应用而言，接收所需吞吐量的一半是几乎没有或根本没有用处的。具有吞吐量要求的应用程序被称为带宽敏感的应用（bandwidth-sensitive application）

许多当前的多媒体应用是带宽敏感的，尽管某些多媒体应用程序可能采用自适应编码技术对数字语音或视频以与当前可用带宽相匹配的速率进行编码。

带宽敏感的应用具有特定的吞吐量要求，而弹性应用（elastic application）能够根据当时可用的带宽或多或少地利用可供使用的吞吐量。

电子邮件、文件传输以及Web传送都属于弹性应用。当然，吞吐量是越多越好。有一句格言说得好，钱越多越好，人越瘦越美，我们永远不会嫌吞吐量太多的！

定时

运输层协议也能提供定时保证。

如同具有吞吐量保证那样，定时保证能够以多种形式实现。

一个保证的例子如：发送方注入进套接字中的每个比特到达接收方的套接字不迟于100mso这种服务将对交互式实时应用程序有吸引力，如因特网电话、虚拟环境、电话会议和多方游戏，所有这些服务为了有效性而要求数据交付有严格的时间限制

例如，在因特网电话中，较长的时延会导致会话中出现不自然的停顿；在多方游戏和虚拟互动环境中，在做出动作并看到来自环境（如来自位于端到端连接中另一端点的玩家）的响应之间，较长的时延使得它失去真实感。

对于非实时的应用，较低的时延总比较高的时延好，但对端到端的时延没有严格的约束。

安全性

运输协议能够为应用程序提供一种或多种安全性服务。

例如，在发送主机中，运输协议能够加密由发送进程传输的所有数据，在接收主机中，运输层协议能够在将数据交付给接收进程之前解密这些数据。

这种服务将在发送和接收进程之间提供机密性，以防该数据以某种方式在这两个进程之间被观察到。

运输协议还能提供除了机密性以外的其他安全性服务，包括数据完整性和端点鉴别。

因特网提供的运输服务

至此，我们已经考虑了计算机网络能够提供的通用运输服务。

现在我们要更为具体地考察由因特网提供的运输服务类型。

因特网（更一般的是TCP/IP网络）为应用程序提供两个运输层协议：

即UDP和TCP

当你（作为一个软件开发者）为因特网创建一个新的应用时，首先要做出的决定是，选择UDP还是选择TCP。每个协议为调用它们的应用程序提供了不同的服务集合。图2-4显示了某些所选的应用程序的服务要求。

1.TCP服务

TCP服务模型包括 面向连接服务和可靠数据传输服务。当某个应用程序调用TCP作为其运输协议时，该应用程序就能获得来自TCP的这两种服务。

面向连接的服务：

在应用层数据报文开始流动之前，TCP让客户和服务器互相交换运输层控制信息。这个所谓的握手过程提醒客户和服务器，让它们为大量分组的到来做好准备。

在握手阶段后，一个TCP连接（TCP connection）就在两个进程的套接字之间建立了。

这条连接是全双工的，即连接双方的进程可以在此连接上同时进行报文收发。当应用程序结束报文发送时，必须拆除该连接。

在第3章中我们将详细讨论面向连接的服务，并分析它是如何实现的。

可靠的数据传送服务：

通信进程能够依靠TCP,无差错、按适当顺序交付所有发送的数据。当应用程序的一端将字节流传进套接字时，它能够依靠TCP将相同的字节流交付给接收方的套接字，而没有字节的丢失和冗余。

TCP协议还具有 拥塞控制机制，这种服务不一定能为通信进程带来直接好处，但能为因特网带来整体好处。

当发送方和接收方之间的网络出现拥塞时，TCP的拥塞控制机制会抑制发送进程（客户或服务器）。

如我们将在第3章中所见， TCP拥塞控制也试图限制每个TCP连接，使它们达到公平共享网络带宽的目的。

.

2 UDP服务

UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。

UDP是无连接的， 因此在两个进程通信前没有握手过程。

UDP协议提供 一种不可靠数据传送服务，也就是说，当进程将一个报文发送进UDP套接字时，UDP协议并不保证该报文将到达接收进程。不仅如此，到达接收进程的报文也可能是乱序到达的。

UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层（网络层）注入数据。

（然而，值得注意的是实际端到端吞吐量可能小于该速率，这可能是因为中间链路的带宽受限或因为拥塞而造成的。）

3 因特网运输协议所不提供的服务

我们已经从4个方面组织了运输协议服务： 可靠数据传输、吞吐量、定时和安全性。

TCP和UDP提供了这些服务中的哪些呢？

我们已经注意到TCP提供了可靠的端到端数据传送。并且我们也知道TCP在应用层可以很容易地用 SSL来加强以提供安全服务。

但在我们对TCP和UDP的简要描述中，明显地漏掉了对吞吐量或定时保证的讨论，即这些服务目前的因特网运输协议并没有提供。

这是否意味着诸如因特网电话这样的时间敏感应用不能运行在今天的因特网上呢？答案显然是否定的，因为在因特网上运行时间敏感应用已经有多年了。

这些应用经常工作得相当好，因为它们已经被设计成尽最大可能对付这种保证的缺乏。

我们将在第9章中研究几种设计技巧。无论如何，在时延过大或端到端吞吐量受限时，好的设计也是有限制的。总之，今天的因特网通常能够为时间敏感应用提供满意的服务，但它不能提供任何定时或带宽保证。

图2・5指出了一些流行的因特网应用所使用的运输协议。

可以看到，电子邮件、远程终端访问、Web.文件传输都使用了 TCP。

这些应用选择TCP的最主要原因是TCP提供了可靠数据传输服务，确保所有数据最终到达目的地。

因为因特网电话应用（如Skype）通常能够容忍某些丢失但要求达到一定的最小速率才能有效工作，所以因特网电话应用的开发者通常愿意将该应用运行在UDP上，从而设法避开TCP的拥塞控制机制和分组开销。

但因为许多防火墙被配置成阻挡（大多数类型的）UDP流量，所以因特网电话应用通常设计成如果UDP通信失败就使用TCP作为备份

应用层协议

我们刚刚学习了通过把报文发送进套接字实现网络进程间的相互通信。

但是如何构造这些报文？

在这些报文中的各个字段的含义是什么？

进程何时发送这些报文？

这些问题将我们带进应用层协议的范围。

应用层协议（application-layer protocol）

定义了运行在不同端系统上的应用程序进程如何相互传递报文。

特别是应用层协议定义了 ：

交换的报文类型，例如请求报文和响应报文。

各种报文类型的语法，如报文中的各个字段及这些字段是如何描述的。

字段的语义，即这些字段中的信息的含义。

确定一个进程何时以及如何发送报文，对报文进行响应的规则

有些应用层协议是 由RFC文档定义的，因此它们位于公共域中。

例如，Web的应用层协议HTTP （超文本传输协议［RFC 2616］）就作为一个RFC可供使用。

如果浏览器开发者遵从HTTP RFC规则，所开发出的浏览器就能访问任何遵从该文档标准的Web服务器并获取相应Web页面。还有很多别的应用层协议是专用的，有意不为公共域使用。例如,Skype使用了专用的应用层协议。

区分网络应用和应用层协议是很重要的。应用层协议只是网络应用的一部分（尽管从我们的角度看，它是应用非常重要的一部分）。

例子：Web是一种客户-服务器应用，它允许客户按照需求从Web服务器获得文档。该Web应用有很多组成部分,包括文档格式的标准（即HTML）、Web浏览器（如Firefox和Microsoft Internet Explorer）、Web服务器（如Apache、Microsoft服务器程序），以及一个应用层协议。

Web的应用层协议是 HTTP,它定义了在浏览器和Web服务器之间传输的 报文格式和序列。因此，HTTP只是Web应用的一个部分（尽管是重要部分）。

举另外一个例子，因特网电子邮件应用也有很多组成部分，包括能容纳用户邮箱的邮件服务器、允许用户读取和生成邮件的邮件客户程序（如Microsoft Outlook）

定义电子邮件报文结构的标准、定义报文如何在服务器之间以及如何在服务器与邮件客户程序之间传递的应用层协议、定义如何对报文首部的内容进行解释的应用层协议。

用于电子邮件的主要应用层协议就是 SMTP （简单邮件传输协议［RFC5321］）。因此，电子邮件的首要应用层协议SMTP也只是电子邮件应用的一个部分（尽管是重要部分）。

FTP协议

File Transfer Protocol，文件传输协议，用于在网络上进行文件传输的协议，它工作在应用层，使用TCP传输而不是UDP

为什么使用TCP而不是UDP？通过TCP的可靠性连接，为数据传输提供可靠保证

FTP协议的通信双方，一方称为FTP Client，另一方为FTP Server，它们在传输文件前，首先要建立连接，建立连接就必须要知道IP地址和端口号。

FTP与我们已描述的另一种应用不同，它采用两个TCP连接来传输一个文件。

控制连接以通常的客户服务器方式建立。服务器以被动方式打开众所周知的用于FTP的端口（21），等待客户的连接。客户则以主动方式打开TCP端口21，来建立连接。控制连接始终等待客户与服务器之间的通信。该连接将命令从客户传给服务器，并传回服务器的应答。由于命令通常是由用户键入的，所以IP对控制连接的服务类型就是”最大限度地减小迟延”。

每当一个文件在客户与服务器之间传输时，就创建一个数据连接。由于该连接用于传输目的，所以IP对数据连接的服务特点就是”最大限度提高吞吐量”。

使用两个端口的好处

FTP文件传输过程

先建立控制连接（客户端发起）

再建立数据连接

最后文件传输

当数据传输完成后 先断开数据连接

FTP会话结束后断开控制连接

统一的URL

Web 和 HTTP

20世纪90年代以前，因特网的主要使用者登录远程主机，在本地主机和远程主机之间传输文件，收发新闻，收发电子邮件。

尽管这些应用非常有用（并且继续如此），但是因特网基本上不为学术界和研究界之外所知。

到了 20世纪90年代初期，一个主要的新型应用即万维网（WorldWideWeb）登上了舞台［Berners-Lee 1994］

Web是一个引起公众注意的因特网应用，它极大地改变了人们与工作环境内外交流的方式。它将因特网从只是很多数据网之一的地位提升为仅有的一个数据网。

也许对大多数用户来说，最具有吸引力的就是Web的按需操作。当用户需要时，就能得到所想要的内容。

这不同于无线电广播和电视，它们迫使用户只能收听、收看内容提供者提供的节目。

除了可以按需操作以外，Web还有很多让人们喜欢和珍爱的特性。任何人使信息在Web上可用都非常简单，即只需要极低的费用就能成为出版人。超链接和搜索引擎帮助我们在Web站点的海洋里导航。图片和视频刺激着我们的感官。表单、JavaScript. Java小程序和很多其他的装置，使我们可以与Web页面和站点进行交互。

并且，Web及其协议作为平台，为YouTube,基于Web的电子邮件（如Gmail）和大多数移动因特网应用（包括Instagram和谷歌地图）服务。

HTTP 概况

Web的应用层协议是 超文本传输协议（HyperText Transfer Protocol, HTTP）,它是Web的核心，在［RFC 1945］和［RFC 2616］中进行了定义。

HTTP由两个程序实现：一个客户程序和一个服务器程序。

客户程序和服务器程序运行在不同的端系统中，通过 交换HTTP报文进行会话。 HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。在详细解释HTTP之前，应当回顾某些Web术语

Web页面（Webpage）（也叫文档）是由对象组成的。

一个对象（object）只是一个文件，诸如一个HTML文件、一个JPEG图形、一个Java小程序或一个视频片段这样的文件,且它们可通过一个URL地址寻址。多数Web页面含有一个HTML基本文件（base HTMLfile）以及几个引用对象。

例如，如果一个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服务器（Webserver）实现了 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。

如同在上述描述的那样， 客户端的套接字接口是客户进程与TCP连接之间的门， 在服务器端的套接字接口则是服务器进程与TCP连接之间的门。客户向它的套接字接口发送HTTP请求报文并从它的套接字接口接收HTTP响应报文。

类似地， 服务器从它的套接字接口接收HTTP请求报文和向它的套接字接口发送HTTP响应报文。

一旦客户向它的套接字接口发送了一个请求报文，该报文就脱离了客户控制并进入TCP的控制。

TCP为HTTP提供可靠数据传输服务。这意味着，一个客户进程发出的每个HTTP请求报文最终能完整地到达服务器；类似地， 服务器进程发出的每个HTTP响应报文最终能完整地到达客户。

这里我们看到了分层体系结构最大的优点，即HTTP协议不用担心数据丢失，也不关注TCP从网络的数据丢失和乱序故障中恢复的细节。

那是TCP以及协议栈较低层协议的工作。

注意到下列现象很重要：

服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。

假如某个特定的客户在短短的几秒内两次请求同一个对象，服务器并不会因为刚刚为该客户提供了该对象就不再做出反应，而是重新发送该对象，就像服务器已经完全忘记不久之前所做过的事一样。

因为HTTP服务器并不保存关于客户的任何信息，所以我们说HTTP是一个无状态协议(stateless protocol)。

我们同时也注意到Web使用了客户-服务器应用程序体系结构(如2.1节所述)。Web服务器总是打开的，具有一个固定的IP地址，且它服务于可能来自数以百万计的不同浏览器的请求

非持续连接和持续连接

在许多因特网应用程序中，客户和服务器在一个相当长的时间范围内通信，其中客户发出一系列请求并且服务器对每个请求进行响应。

依据应用程序以及该应用程序的使用方式，这一系列请求可以以规则的间隔周期性地或者间断性地一个接一个发出。

当这种客户-服务器的交互是经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

我们看看发生了什么情况：

1） HTTP客户进程在端口号80发起一个到服务器www. someSchool. edu的TCP连接，该端口号是HTTP的默认端口。在客户和服务器上分别有一个套接字与该连接相关联。

2） HTTP客户经它的套接字向该服务器发送一个HTTP请求报文。请求报文中包含了路径名/someDepartment/home. index （后面我们会详细讨论HTTP报文）。

3） HTTP服务器进程经它的套接字接收该请求报文， 从其存储器（RAM或磁盘）中检索出对象 www. someSchool. edu/someDepartment/home. index,在一个 HTTP 响应报文中封装对象，并通过其套接字向客户发送响应报文。

4） HTTP服务器进程通知TCP断开该TCP连接。（但是直到 TCP确认客户已经完整地收到响应报文为止，它才会实际中断连接。）

5） HTTP客户接收响应报文，TCP连接关闭。该报文指岀封装的对象是一个HTML文件，客户从响应报文中提取出该文件，检査该HTML文件，得到对10个JPEG图形的引用。

6） 对每个引用的JPEG图形对象重复前4个步骤。

当浏览器收到Web页面后，向用户显示该页面。两个不同的浏览器也许会以不同的方式解释（即向用户显示）该页面。HTTP与客户如何解释一个Web页面毫无关系。HTTP规范（［RFC 1945］和［RFC2616］）仅定义了在HTTP客户程序与HTTP服务器程序之间的通信协议

上面的步骤举例说明了非持续连接的使用，其中每个TCP连接在服务器发送一个对象后关闭，即该连接并不为其他的对象而持续下来。

值得注意的是 每个TCP连接只传输一个请求报文和一个响应报文。因此在本例中，当用户请求该Web页面时，要产生11个TCP连接。

在上面描述的步骤中，我们有意没有明确客户获得这10个JPEG图形对象是使用10个串行的TCP连接，还是某些JPEG对象使用了一些并行的TCP连接。

事实上，用户能够配置现代浏览器来控制连接的并行度。在默认方式下，大部分浏览器打开5 ~ 10个并行的TCP连接，而每条连接处理一个请求响应事务。

如果用户愿意，最大并行连接数可以设置为1,这样10条连接就会串行建立。我们在下一章会看到，使用并行连接可以缩短响应时间

在继续讨论之前，我们来简单估算一下从客户请求HTML基本文件起到该客户收到整个文件止所花费的时间。

为此，我们给出往返时间（Round Trip Time, RTF）的定义，该时间是指一个短分组从客户到服务器然后再返回客户所花费的时间。

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用于请求和接收一个对象。

在采用HTTP 1.1持续连接的情况下，服务器在发送响应后保持该TCP连接打开。在相同的客户与服务器之间，后续的请求和响应报文能够通过相同的连接进行传送。

特别是，一个完整的Web页面（上例中的HTML基本文件加上10个图形）可以用单个持续TCP连接进行传送。

更有甚者，位于同一台服务器的多个Web页面在从该服务器发送给同一个客户时，可以在单个持续TCP连接上进行。对对象的这些请求可以一个接一个地发出，而不必等待对未决请求（流水线）的回答。

一般来说，如果一条连接经过一定时间间隔（一个可配置的超时间隔）仍未被使用，HTTP服务器就关闭该连接。HTTP的默认模式是使用带流水线的持续连接。

最近，HTTP/2 ［RFC 7540］是在HTTP 1. 1基础上构建的，它允许在 相同连接中多个请求和回答交错，并增加了在该连接中优化HTTP报文请求和回答的机制。

HTTP报文格式

HTTP 规范［RFC 1945； RFC 2616； RFC 7540:包含了对HTTP 报文格式的定义。

HTTP报文有两种：请求报文和响应报文。下面讨论这两种报文。

1.HTTP请求报文

下面提供了一个典型的HTTP请求报文

首先，我们看到该报文是用普通的ASCII文本书写的 其次，我们看到该报文由5行组成，每行由一个回车和换行符结束。

最后一行后再附加一个回车换行符。虽然这个特定的报文仅有5行，但一个请求报文能够具有更多的行或者至少为一行

HTTP请求报文的第一行叫作请求行（request line）,其后继的行叫作首部行（headerline）。

请求行有3个字段：方法字段、URL字段和HTTP版本字段。方法字段可以取几种不同的值，包括GET、POST、HEAD、PUT和DELETEO绝大部分的HTTP请求报文使用GET方法。

当浏览器请求一个对象时，使用GET方法，在URL字段带有请求对象的标识。

现在我们看看本例的首部行。

首部行Host： www. someschool. edu指明了对象所在的主你也许认为该首部行是不必要的，因为在该主机中已经有一条TCP连接存在了。

但该首部行提供的信息是Web代理高速缓存所要求的。

通过包含Connection: close首部行，该浏览器告诉服务器不要麻烦地使用持续连接，它要求服务器在发送完被请求的对象后就关闭这条连接。

User-agent:首部行用来指明用户代理，即向服务器发送请求的浏览器的类型。

这里浏览器类型是Mozilla/5.0,即Firefox浏览器。

这个首部行是有用的，因为服务器可以有效地为不同类型的用户代理实际发送相同对象的不同版本。（每个版本都由相同的URL寻址。）

最后，Accept-language：首部行表示用户想得到该对象的法语版本（如果服务器中有这样的对象的话）；否则，服务器应当发送它的默认版本。Accept-language:首部行仅是HTTP中可用的众多内容协商首部之一。

HTTP响应报文

下面我们提供了一条典型的HTTP响应报文。该响应报文可以是对刚刚讨论的例子中请求报文的响应。

我们仔细看一下这个响应报文。

它有三个部分：一个初始状态行（status line） , 6个首部行（headerline）,然后是实体体（entity body）实体体部分是报文的主要部分，即它包含了所请求的对象本身（表示为data data data data data -）

状态行有3个字段：协议版本字段、状态码和相应状态信息。

在这个例子中，状态行指示服务器正在使用HTTP/1.1,并且一切正常（即服务器已经找到并正在发送所请求的对象

我们现在来看看首部行。

服务器用Connection： close首部行告诉客户，发送完报文后将关闭该TCP连接。

Date：首部行指示服务器产生并发送该响应报文的日期和时间。值得一提的是，这个时间不是指对象创建或者最后修改的时间，而是服务器从它的文件系统中检索到该对象，将该对象插入响应报文，并发送该响应报文的时间。

Server:首部行指示该报文是由一台Apache Web服务器产生的，它类似于HTTP请求报文中的User-agent:首部行。

Last-Modified:首部行指示了对象创建或者最后修改的日期和时间。

Last- Modified:首部行对既可能在本地客户也可能在网络缓存服务器上的对象缓存来说非常重要。我们将很快详细地讨论缓存服务器（也叫代理服务器）。

ContentLength： 首部行指示了被发送对象中的字节数。Content-Type:首部行指示了实体体中的对象是HTML文本。（该对象类型应该正式地由Content-Type:首部行而不是用文件扩展名来指示。）

看过一个例子后，我们再来查看响应报文的通用格式，如图2・9所示。

该通用格式与前面例子中的响应报文相匹配。我们补充说明一下状态码和它们对应的短语。状态码及其相应的短语指示了请求的结果。

一些常见的状态码和相关的短语包括：

200 0K：请求成功，信息在返回的响应报文中。

301 Moved Permanently：请求的对象已经被永久转移了，新的URL定义在响应报文的Location:首部行中。客 户软件将自动获取新的URL。

400 Bad Request: 一个通用差错代码，指示该请求不能被服务器理解。

404 Not Found:被请求的文档不在服务器上。

505 HTTP Version Not Supported:服务器不支持请求报文使用的HTTP协议版本。

你想看一下真实的HTTP响应报文吗？这正是我们高度推荐而且也很容易做到的事。

首先用Telnet登录到你喜欢的Web服务器上，接下来输入一个只有一行的请求报文去请求放在该服务器上的某些对象。例如，假设你看到命令提示，键入：

（在输入最后一行后连续按两次回车。）这就打开一个到主机gaia. cs. umass. edu的80端口的TCP连接，并发送一个HTTP请求报文。

你将会看到一个携带包括本书交互式课后作业的基本HTML文件的响应报文。如果你只是想看一下HTTP协议的报文行，而不是获取对象本身的话，那么可以用HEAD代替GET

浏览器是如何决定在一个请求报文中包含哪些首部行的呢？

Web服务器又是如何决定在一个响应报文中包含哪些首部行呢？

浏览器产生的首部行与很多因素有关，包括浏览器的类型和协议版本（例如，HTTP/1. 0浏览器将不会产生任何1.1版本的首部行）、浏览器的用户配置（如喜好的语言）、浏览器当前是否有一个缓存的但是可能超期的对象版本。Web服务器的表现也类似：在产品、版本和配置上都有差异，所有这些都会影响响应报文中包含的首部行。

用户与服务器的交互：cookie

我们前面提到了 HTTP服务器是无状态的。这简化了服务器的设计，并且允许工程师们去开发可以同时处理数以千计的TCP连接的高性能Web服务器。

然而一个Web站点通常希望能够识别用户，可能是因为服务器希望限制用户的访问，或者因为它希望把内容与用户身份联系起来。

为此，HTTP使用了 cookie。cookie在［RFC 6265 ］中定义，它允许站点对用户进行跟踪。目前大多数商务Web站点都使用了 cookie

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：首部含有该识别码。

当Susan的浏览器收到了该HTTP响应报文时，它会看到该Set-cookie：首部。

该浏览器在它管理的特定cookie文件中添加一行，该行包含服务器的主机名和在Set-cookie:首部中的识别码。值得注意的是该cookie文件已经有了用于eBay的表项，因为Susan过去访问过该站点。

当Susan继续浏览Amazon网站时，每请求一个Web页面，其浏览器就会查询该cookie文件并抽取她对这个网站的识别码，并放到HTTP请求报文中包括识别码的cookie首部行中。

特别是，发往该Amazon服务器的每个HTTP请求报文都包括以下首部行:Cookie: 1678在这种方式下，Amazon服务器可以跟踪Susan在Amazon站点的活动。

尽管AmazonWeb站点不必知道Susan的名字，但它确切地知道用户1678按照什么顺序、在什么时间、访问了哪些页面！ Amazon使用cookie来提供它的购物车服务，即Amazon能够维护Susan希望购买的物品列表，这样在Susan结束会话时可以一起为它们付费。

如果Susan再次访问Amazon站点，比如说一个星期后，她的浏览器会在其请求报文中继续放入首部行cookie： 1678O Amazon将根据Susan过去在Amazon访问的网页向她推荐产品。

如果Susan也在Amazon注册过，即提供了她的全名、电子邮件地址、邮政地址和信用卡账号，则Amazon能在其数据库中包括这些信息，将Susan的名字与识别码相关联（以及她在过去访问过的本站点的所有页面）。

这就解释了 Anrnzon和其他一些电子商务网站实现”点击购物（one-click shopping）的道理，即当Susan在后继的访问中选择购买某个物品时，她不必重新输入姓名、信用卡账号或者地址等信息了。

从上述讨论中我们看到，cookie可以用于标识一个用户。用户首次访问一个站点时，可能需要提供一个用户标识（可能是名字）。

在后继会话中，浏览器向服务器传递一个cookie首部，从而向该服务器标识了用户。因此cookie可以在无状态的HTTP之上建立一个用户会话层。

例如，当用户向一个基于Web的电子邮件系统（如Hotmail）注册时，浏览器向服务器发送cookie信息，允许该服务器在用户与应用程序会话的过程中标识该用户。

尽管cookie常常能简化用户的因特网购物活动，但是它的使用仍具有争议，因为它们被认为是对用户隐私的一种侵害。

如我们刚才所见，结合cookie和用户提供的账户信息,Web站点可以知道许多有关用户的信息，并可能将这些信息卖给第三方。Cookie Central[Cookie Central 2016]包括了对cookie争论的广泛信息。

Web 缓存

Web缓存器（Web cache）也叫代理服务器（proxy server）,它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间,并在存储空间中保存最近请求过的对象的副本。

如图2・11所示，可以配置用户的浏览器，使得用户的所有HTTP请求首先指向Web缓存器。一旦某浏览器被配置，每个对某对象的浏览器请求首先被定向到该Web缓存器。举例来说，假设浏览器正在请 求对象 http :〃www. someschool. edu/campus, gif,将会发生如下情况：

1）浏览器创建一个到Web缓存器客户 初始’服务器图 2-11 客户通过Web缓存器请求对象的TCP连接，并向Web缓存器中的对象发送一个HTTP请求。

2） Web缓存器进行检查，看看本地是否存储了该对象副本。如果有，Web缓存器就向客户浏览器用HTTP响应报文返回该对象。

3） 如果Web缓存器中没有该对象，它就打开一个与该对象的初始服务器（即WWW. someschool. edu）的TCP连接。Web缓存器则在这个缓存器到服务器的TCP连接上发送一个对该对象的HTTP请求。在收到该请求后，初始服务器向该Web缓存器发送具有该对象的HTTP响应。

4） 当Web缓存器接收到该对象时，它在本地存储空间存储一份副本，并向客户的浏览器用HTTP响应报文发送该副本（通过现有的客户浏览器和Web缓存器之间的TCP连接）。

值得注意的是Web缓存器既是服务器又是客户。当它接收浏览器的请求并发回响应时，它是一个服务器。当它向初始服务器发出请求并接收响应时，它是一个客户。Web缓存器通常由ISP购买并安装。例如，一所大学可能在它的校园网上安装一台缓存器，并且将所有校园网上的用户浏览器配置为指向它。或者，一个主要的住宅ISP （例如Comcast）可能在它的网络上安装一台或多台Web缓存器，并且预先配置其配套的浏览器指向这些缓存器

在因特网上部署Web缓存器有两个原因。首先，Web缓存器可以大大减少对客户请求的响应时间，特别是当客户与初始服务器之间的瓶颈带宽远低于客户与Web缓存器之间的瓶颈带宽时更是如此。如果在客户与Web缓存器之间有一个高速连接（情况常常如此），并且如果用户所请求的对象在Web缓存器上，则Web缓存器可以迅速将该对象交付给用户。其次，如我们马上用例子说明的那样，Web缓存器能够大大减少一个机构的接入链路到因特网的通信量1$ 。通过减少通信量，该机构（如一家公司或者一所大学）就不必急于增加带宽，因此降低了费用。此外，Web缓存器能从整体上大大减低因特网上的Web流量，从而改善了所有应用的性能

为了深刻理解缓存器带来的好处，我们考虑在图2・12场景下的一个例子。

该图显示了两个网络，即机构（内部）网络和公共因特网的一部分。

机构网络是一个高速的局域网,它的一台路由器与因特网上的一台路由器通过一条15Mbps的链路连接。

这些初始服务器与因特网相连但位于全世界各地。假设对象的平均长度为1Mb,从机构内的浏览器对这些初始服务器的平均访问速率为每秒15个请求

假设HTTP请求报文小到可以忽略，因而不会在网络中以及接入链路（从机构内部路由器到因特网路由器）上产生什么通信量。

我们还假设在图2・12中从因特网接入链路一侧的路由器转发HTTP请求报文（在一个IP数据报中）开始，到它收到其响应报文（通常在多个1P数据报中）为止的时间平均为2秒。我们非正式地将该持续时延称为”因特网时延”。

总的响应时间，即从浏览器请求一个对象到接收到该对象为止的时间，是局域网时延、接入时延三（即两台路由器之间的时延）和因特网时延之和。

条件GET方法

尽管高速缓存能减少用户感受到的响应时间，但也引入了一个新的问题，即存放在缓存器中的对象副本可能是陈旧的。

换句话说，保存在服务器中的对象自该副本缓存在客户上以后可能已经被修改了。

幸运的是，HTTP协议有一种机制，允许缓存器证实它的对象是最新的。

这种机制就是条件GET （conditional GET）方法。如果：①请1=1 求报文使用GET方法；并且②请求报文中包含一个” If Modified-Since：”首部行。那么，这个HTTP请求报文就是一个条件GET请求报文。为了说明GET方法的操作方式，我们看一个例子。

首先，一个代理缓存器（proxycache）代表一个请求浏览器，向某Web服务器发送一个请求报文:

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

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

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

接下来的第四步，Web服务器向该缓存器发送一个响应报文:

我们看到，作为对该条件GET方法的响应，该Web服务器仍发送一个响应报文，但并没有在该响应报文中包含所请求的对象。包含该对象只会浪费带宽，并增加用户感受到的响应时间，特别是如果该对象很大的时候更是如此。值得注意的是在最后的响应报文中，状态行中为304 Not Modified,它告诉缓存器可以使用该对象，能向请求的浏览器转发它（该代理缓存器）缓存的该对象副本。

因特网中的电子邮件

与普通邮件一样，电子邮件是一种异步通信媒介，即当人们方便时就可以收发邮件,不必与他人的计划进行协调。

与普通邮件相比，电子邮件更为快速并且易于分发，而且价格便宜。现代电子邮件具有许多强大的特性，包括具有附件、超链接、HTML格式文本和图片的报文

在本节中，我们将讨论位于因特网电子邮件的核心地位的应用层协议。在深入讨论这些应用层协议之前，我们先总体上看看因特网电子邮件系统和它的关键组件。

图2・14给出了因特网电子邮件系统的总体情况。从该图中我们可以看到它有3个主要组成部分：用户代理（user agent）、邮件服务器（mail server）和简单邮件传输协议（Simple Mail Transfer Protocol, SMTP）

下面我们结合发送方Alice发电子邮件给接收方Bob的场景，对每个组成部分进行描述。

用户代理允许用户阅读、回复、转发、保存和撰写报文。微软的Outlook和Apple Mail是电子邮件用户代理的例子。

当Alice完成邮件撰写时，她的邮件代理向其邮件服务器发送邮件，此时邮件放在邮件 服务器的外出报文队列中。当Bob要阅读报文时，他的 用户代理在其邮件服务器的邮箱中取得该报文

邮件服务器形成了电子邮件体系结构的核心。每个接收方（如Bob）在其中的某个邮件服务器上有一个邮箱（mailbox）。Bob的邮箱管理和维护着发送给他的报文。

一个典型的邮件发送过程是：从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中。当Bob要在他的邮箱中读取该报文时，包含他邮箱的邮件服务器（使用用户名和口令）来鉴别Bob0 Alice的邮箱也必须能处理Bob的邮件服务器的故障。

如果Alice的服务器不能将邮件交付给Bob的服务器,Alice的邮件服务器在一个报文队列（message queue）中保持该报文并在以后尝试再次发送。通常每30分钟左右进行一次尝试；如果几天后仍不能成功，服务器就删除该报文并以电子邮件的形式通知发送方（Alice）

SMTP是因特网电子邮件中主要的应用层协议。它使用TCP可靠数据传输服务，从发送方的邮件服务器向接收方的邮件服务器发送邮件。像大多数应用层协议一样，SMTP也有两个部分：运行在发送方邮件服务器的客户端和运行在接收方邮件服务器的服务器端。每台邮件服务器上既运行SMTP的客户端也运行SMTP的服务器端。当一个邮件服务器向其他邮件服务器发送邮件时，它就表现为SMTP的客户；当邮件服务器从其他邮件服务器上接收邮件时，它就表现为一个SMTP的服务器

SMTP

SMTP是因特网电子邮件的核心。

如前所述,SMTP用于从发送方的邮件服务器发送报文到接收方的邮件服务器。

SMTP问世的时间比HTTP要长得多（初始的SMTP协议的RFC可追溯到1982年，而SMTP在此之前很长一段时间就已经出现了）。

尽管电子邮件应用在因特网上的独特地位可以证明SMTP有着众多非常岀色的性质，但它所具有的某种陈旧特征表明它仍然是一种继承的技术。

例如，它限制所有邮件报文的体部分（不只是其首部）只能采用简单的7比特ASCII表示。在20世纪80年代早期，这种限制是明智的，因为当时传输能力不足，没有人会通过电子邮件发送大的附件或是大的图片、声音或者视频文件。然而,在今天的多媒体时代，7位ASCII的限制的确有点痛苦，即在用SMTP传送邮件之前,需要将二进制多媒体数据编码为ASCII码，并且在使用SMTP传输后要求将相应的ASCII码邮件解码还原为多媒体数据。

使用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方便的时候，他调用用户代理阅读该报文。图2-15总结了上述这个情况

观察到下述现象是重要的：SMTP 一般不使用中间邮件服务器发送邮件，即使这两个邮件服务器位于地球的两端也是这样。

假设Alice的邮件服务器在中国香港，而Bob的服务器在美国圣路易斯，那么这个TCP连接也是从香港服务器到圣路易斯服务器之间的直接相连。

特别是，如果Bob的邮件服务器没有开机，该报文会保留在Alice的邮件服务器上并等待进行新的尝试，这意味着邮件并不在中间的某个邮件服务器存留。

我们现在仔细观察一下，SMTP是如何将一个报文从发送邮件服务器传送到接收邮件服务器的。我们将看到，SMTP与人类面对面交往的行为方式有许多类似性。

首先，客户SMTP （运行在发送邮件服务器主机上）在25号端口建立一个到服务器SMTP （运行在接收邮件服务器主机上）的TCP连接。

如果服务器没有开机，客户会在稍后继续尝试连接。一旦连接建立，服务器和客户执行某些应用层的握手，就像人们在互相交流前先进行自我介绍一样。SMTP的客户和服务器在传输信息前先相互介绍。

在SMTP握手的阶段，SMTP客户指示发送方的邮件地址（产生报文的那个人）和接收方的邮件地址。一旦该SMTP客户和服务器彼此介绍之后，客户发送该报文。SMTP能依赖TCP提供的可靠数据传输无差错地将邮件投递到接收服务器。该客户如果有另外的报文要发送到该服务器，就在该相同的TCP连接上重复这种处理；否则,它指示TCP关闭连接

与HTTP的对比

我们简要地比较一下SMTP和HTTP0这两个协议都用于从一台主机向另一台主机传送文件：

HTTP从Web服务器向Web客户（通常是一个浏览器）传送文件（也称为对象）；

SMTP从一个邮件服务器向另一个邮件服务器传送文件（即电子邮件报文）。

当进行文件传送时，持续的HTTP和SMTP都使用持续连接。因此，这两个协议有一些共同特征。

然而，两者之间也有一些重要的区别。

首先， HTTP主要是一个拉协议（pull protocol）,即在方便的时候，某些人在Web服务器上装载信息，用户使用HTTP从该服务器拉取这些信息。 特别是TCP连接是由想接收文件的机器发起的。

另一方面， SMTP基本上是一个推协议（push protocol）,即发送邮件服务器把文件推向接收邮件服务器。

特别是， 这个TCP连接是由要发送该文件的机器发起的。

第二个区别就是我们前面间接地提到过的，SMTP要求每个报文（包括它们的体）采用7比特ASCII码格式。如果某报文包含了非7比特ASCII字符（如具有重音的法文字符）或二进制数据（如图形文件），则该报文必须按照7比特ASCII码进行编码。HTTP数据则不受这种限制。

第三个重要区别是如何处理一个既包含文本又包含图形（也可能是其他媒体类型）的文档。

HTTP把每个对象封装到它自己的HTTP响应报文中,而SMTP则把所有报文对象放在一个报文之中。

邮件访问协议

一旦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。

目前有一些流行的 邮件访问协议，包括第三版的邮局协议（PostOffice Protocol—Version 3 , POP3）、因特网邮件访问协议（Internet Mail Access Protocol, IMAP）以及 HTTP

图2 16总结了应用于因特网电子邮件的一些协议：

SMTP用来将邮件从发送方的邮件服务器传输到接收方的邮件服务器；

SMTP也用来将邮件从发送方的用户代理传送到发送方的邮件服务器。

POP3这样的邮件访问协议用来将邮件从接收方的邮件服务器传送到接收方的用户代理

1. POP3

POP3是一个极为简单的邮件访问协议，由RFC 1939进行定义。文档RFC 1939简短且可读性强。因为该协议非常简单，故其功能相当有限。

当用户代理（客户）打开了一个到邮件服务器（服务器）端口 110上的TCP连接后，POP3就开始工作了。随着建立TCP连接，POP3按照三个阶段进行工作： 特许（authorization）、事务处理以及更新。

在第一个阶段即特许阶段，用户代理发送（以明文形式）用户名和口令以鉴别用户。

在第二个阶段即事务处理阶段，用户代理取回报文；同时在这个阶段用户代理还能进行如下操作，对报文做删除标记，取消报文删除标记，以及获取邮件的统计信息。

在第三个阶段即更新阶段，它出现在客户发出了 quit命令之后，目的是结束该POP3会话；这时，该邮件服务器删除那些被标记为删除的报文。

在POP3的事务处理过程中，用户代理发出一些命令，服务器对每个命令做出回答。回答可能有两种：

+0K （有时后面还跟有服务器到客户的数据），被服务器用来指示前面的命令是正常的；

-ERR,被服务器用来指示前面的命令出现了某些差错。特许阶段有两个主要的命令：user < user name >和pass < password >

如果你的命令拼写错了，该POP3服务器将返回一个- ERR报文。

现在我们来看一下事务处理过程。使用POP3的用户代理通常被用户配置为”下载并删除”或者”下载并保留”方式。POP3用户代理发岀的命令序列取决于用户代理程序被配置为这两种工作方式的哪一种。使用下载并删除方式，用户代理发出list、”tr和dele命令。

举例来说，假设用户在他（她）的邮箱里有两个报文。在下面的对话中,C：（代表客户）是用户代理，S：（代表服务器）是邮件服务器。事务处理过程将类似于如下过程:

用户代理首先请求邮件服务器列出所有存储的报文的长度。接着用户代理从邮件服务器取回并删除每封邮件。

注意到在特许阶段以后，用户代理仅使用四个命令list、retr. dele 和quit,这些命令的语法定义在RFC 1939中。

在处理quit命令后，POP3服务器进入更新阶段，从用户的邮箱中删除邮件1和2。使用下载并删除方式存在的问题是，邮件接收方Bob可能是移动的，可能希望从多个不同的机器访问他的邮件报文，如从办公室的PC、家里的PC或他的便携机来访问邮件。

下载并删除方式将对Bob的邮件报文根据这3台机器进行划分，特别是如果Bob最先是在他办公室的PC上收取了一条邮件，那么晚上当他在家里时，通过他的便携机将不能再收取该邮件。

使用下载并保留方式，用户代理下载某邮件后，该邮件仍保留在邮件服务器上。这时，Bob就能通过不同的机器重新读取这些邮件；他能在工作时收取一封报文，而在工作回家后再次访问它。

在用户代理与邮件服务器之间的POP3会话期间，该POP3服务器保留了一些状态信息；特别是记录了哪些用户报文被标记为删除了。然而，POP3服务器并不在POP3会话过程中携带状态信息。会话中不包括状态信息大大简化了 POP3服务的实现。

2. IMAP

使用POP3访问时，一旦Bob将邮件下载到本地主机后，他就能建立邮件文件夹,并将下载的邮件放入该文件夹中。然后Bob可以删除报文，在文件夹之间移动报文,并查询报文（通过发送方的名字或报文主题）。

但是这种文件夹和报文存放在本地主机上的方式，会给移动用户带来问题，因为他更喜欢使用一个在远程服务器上的层次文件夹，这样他可以从任何一台机器上对所有报文进行访问。使用POP3是不可能做到这一点的， POP3协议没有给用户提供任何创建远程文件夹并为报文指派文件夹的方法

为了解决这个或其他一些问题，由RFC 3501定义的因特网邮件访问协议（IMAP）应运而生。和POP3 —样，IMAP是一个邮件访问协议，但是它比POP3具有更多的特色，不过也比POP3复杂得多。（因此客户和服务器端的实现也都复杂得多。

1MAP服务器把每个报文与一个文件夹联系起来；当报文第一次到达服务器时，它与收件人的INBOX文件夹相关联。收件人则能够把邮件移到一个新的、用户创建的文件夹中，阅读邮件，删除邮件等。

IMAP协议为用户提供了创建文件夹以及将邮件从一个文件夹移动到另一个文件夹的命令。

IMAP还为用户提供了在远程文件夹中查询邮件的命令，按指定条件去查询匹配的邮件。

值得注意的是，与POP3不同， IMAP服务器维护了 IMAP会话的用户状态信息，例如，文件夹的名字以及哪些报文与哪些文件夹相关联

IMAP的另一个重要特性是 它具有允许用户代理获取报文某些部分的命令。例如，一个用户代理可以只读取一个报文的报文首部，或只是一个多部分MIME报文的一部分。用户代理和其邮件服务器之间使用低带宽连接（如一个低速调制解调器链路）的时候，个特性非常有用。使用这种低带宽连接时，用户可能并不想取回他邮箱中的所有邮件，其要避免可能包含如音频或视频片断的大邮件。

3 基于Web的电子邮件

今天越来越多的用户使用他们的Web浏览器收发电子邮件。20世纪90年代中期Hotmail引入了基于Web的接入。今天, 谷歌、雅虎以及几乎所有重要的大学或者公司也提供了基于Web的电子邮件。

使用这种FKlf 服务，用户代理就是普通的浏览器，用户和他远程邮箱之间的通信则通过HTTP进行。当一个收件人（如Bob）,想从他的邮箱中访问一个报文时，该电子邮件报文从Bob的邮件服务器发送到他的浏览器，使用的是HTTP而不是POP3或者IMAP协议。

当发件人（如Alice）要发送一封电子邮件报文时，该电子邮件报文从Alice的浏览器发送到她的邮件服务器，使用的是HTTP而不是SMTP。

然而，Alice的邮件服务器在与其他的邮件服务器之间发送和接收邮件时，仍然使用的是SMTP

DNS：因特网的目录服务

人类能以很多方式来标识。例如，我们能够通过出生证书上的名字来标识；能够通过社会保险号码来标识。尽管这些标识办法都可以用来识别一个人，但是在特定环境下，某种识别方法可能比另一种方法更为适合。

例如，IRS（美国那个声名狼藉的税务征收机构）的计算机更喜欢使用定长的社会保险号码而不是出生证书上的姓名。

另一方面，普通人乐于使用更好记的出生证书上的姓名而不是社会保险号码。（毫无疑问，你能想象人们之间以这种方式说话吗？如”你好，我叫132-67-9875o请找一下我的丈夫178-87-1146\）

因特网上的主机和人类一样，可以使用多种方式进行标识。主机的一种标识方法是用它的主机名 （hostname）, www. facebook, com、www. google, com、gaia. cs. umass. edu 以及cis. poly, edu等，这些名字便于记忆也乐于被人们接受。

然而，主机名几乎没有提供（即使有也很少）关于主机在因特网中位置的信息。（一个名为WWW. eurecom. fr的主机以国家码.It结束，告诉我们该主机很可能在法 ,仅此而已。）况且，因为主机名可能由不定长的字母数字组成，路由器难以处理。由于这些原因，主机也可以使用所谓IP地址（IP address）进行标识。

一个IP地址由4个字节组成，并有着严格的层次结构。例如121.7.106. 83这样一个IP地址，其中的每个字节都被句点分隔开来，表示了 0~255的十进制数字。我们说IP地址具有层次结构，是因为当我们从左至右扫描它时，我们会得到越来越具体的关于主机位于因特网何处的信息（即在众多网络的哪个网络里）。类似地，当我们从下向上查看邮政地址时，我们能够获得该地址位于何处的越来越具体的信息

DNS提供的服务

我们刚刚看到了识别主机有两种方式，通过主机名或者IP地址。人们喜欢便于记忆的主机名标识方式，而路由器则喜欢定长的、有着层次结构的IP地址。为了折中这些不同的偏好，我们需要一种能进行主机名到IP地址转换的目录服务。这就是域名系统（Domain Name System, DNS）的主要任务。

DNS是：①一个由分层的DNS服务器（DNSserver）实现的分布式数据库；②一个使得主机能够查询分布式数据库的应用层协议。DNS 服务器通常是运行 BIND （ Berkeley Internet Name Domain）软件［BIND 2012 ］的UNIX机器。DNS协议运行在UDP之上，使用53号端口。

DNS通常是由其他应用层协议所使用的，包括HTTP、SMTP和FTP,将用户提供的主机名解析为IP地址。

举一个例子，考虑运行在某用户主机上的一个浏览器（即一个HTTP客户）请求URL www. someschool. edu/index. html页面时会发生什么现象。为了使用户的一主机能够将一个HTTP请求报文发送到Web服务器www. someschool. edu,该用户主机必须获得www.someschool. edu的IP地址。其做法如下。

1） 同一台用户主机上运行着DNS应用的客户端。

2） 浏览器从上述URL中抽取岀主机名www.someschool.edu,并将这台主机名传给DNS应用的客户端。

3） DNS客户向DNS服务器发送一个包含主机名的请求。

4） DNS客户最终会收到一份回答报文，其中含有对应于该主机名的IP地址。

5） 一旦浏览器接收到来自DNS的该IP地址，它能够向位于该IP地址80端口的HTTP服务器进程发起一个TCP连接。

从这个例子中，我们可以看到DNS给使用它的因特网应用带来了额外的时延，有时还相当可观。幸运的是，如我们下面讨论的那样，想获得的IP地址通常就缓存在一个附近的” DNS服务器中，这有助于减少DNS的网络流量和DNS的平均时延。

除了进行主机名到IP地址的转换外，DNS还提供了一些重要的服务：

• 主机别名（host aliasing） 有着复杂主机名的主机能拥有一个或者多个别名。

例如，一台名为relay 1. west-coast, enterprise, com的主机，可能还有两个别名为enterprise. com 和 www. enterprise. com 在这种’情况下,relay 1. west- coasL enterprise, com也称为规范主机名（canonical hostname）

主机别名（当存在时）比主机规范名更加容易记忆。应用程序可以调用DNS来获得主机别名对应的规范主机名以及主机的IP地址。

• 邮件服务器别名（mail server* aliasing）

显而易见，人们也非常希望电子邮件地址好记忆。例如，如果Bob在雅虎邮件上有一个账户，Bob的邮件地址就像bob@ yahoo.com这样简单。然而, 雅虎邮件服务器的主机名可能更为复杂，不像yahoo. com那样简单好记（例如，规范主机名可能像relay1. west- coast hotmail. com那样）。

电子邮件应用程序可以调用DNS,对提供的主机名别名进行解析，以获得该主机的规范主机名及其IP地址。

事实上，MX记录（参见后面）允许一个公司的邮件服务器和Web服务器使用相同（别名化的）的主机名；例如，一个公司的Web服务器和邮件服务器都能叫作enterprise. com

负载分配（load distribution）

DNS也用于在冗余的服务器（如冗余的Web服务器等）之间进行负载分配。繁忙的站点（如cnn. com）被冗余分布在多台服务器上,每台服务器均运行在不同的端系统上，每个都有着不同的IP地址。

由于这些冗余的Web服务器，一个IP地址集合因此与同一个规范主机名相联系。DNS数据库中存储着这些IP地址集合。当客户对映射到某地址集合的名字发出一个DNS请求时，该服务器用IP地址的整个集合进行响应，但在每个回答中循环这些地址次序。

因为客户通常总是向IP地址排在最前面的服务器发送HTTP请求报文，所以DNS就在所有这些冗余的Web服务器之间循环分配了负载。DNS的循环同样可以用于邮件服务器，因此，多个邮件服务器可以具有相同的别名。一些内容分发公司如Akamai也以更加复杂的方式使用DNS ［ Dilley 2002］,以提供Web内容分发

DNS工作机理概述

下面给岀一个DNS工作过程的总体概括，我们的讨论将集中在主机名到［P地址转换服务方面。

假设运行在用户主机上的某些应用程序（如Web浏览器或邮件阅读器）需要将主机名转换为IP地址。这些应用程序将调用DNS的客户端，并指明需要被转换的主机名（在很多基于UNIX的机器上，应用程序为了执行这种转换需要调用函数gethostbyname（）。

用户主机上的DNS接收到后，向网络中发送一个DNS查询报文。所有的DNS请求和回答报文使用UDP数据报经端口 53发送。经过若干毫秒到若干秒的时延后，用户主机上的DNS接收到一个提供所希望映射的DNS回答报文。这个映射结果则被传递到调用DNS的应用程序。

因此，从用户主机上调用应用程序的角度看，DNS是一个提供简单、直接的转换服务的黑盒子。但事实上，实现这个服务的黑盒子非常复杂，它由分布于全球的大量DNS服务器以及定义了 DNS服务器与查询主机通信方式的应用层协议组成。

DNS的一种简单设计是在因特网上只使用一个DNS服务器，该服务器包含所有的映射。在这种集中式设计中，客户直接将所有查询直接发往单一的DNS服务器，同时该DNS服务器直接对所有的查询客户做出响应。

尽管这种设计的简单性非常具有吸引力，但它不适用于当今的因特网，因为因特网有着数量巨大（并持续增长）的主机。这种集中式设计的问题包括:

单点故障（a single point of failure）如果该DNS服务器崩溃，整个因特网随之瘫痪！

通信容量（traffic volume）。单个DNS服务器不得不处理所有的DNS査询（用于为上亿台主机产生的所有HTTP请求报文和电子邮件报文服务）

远距离的集中式数据库(distant centralized database) 单个DNS服务器不可能”邻近”所有查询客户。如果我们将单台DNS服务器放在纽约市，那么所有来自澳大利亚的查询必须传播到地球的另一边，中间也许还要经过低速和拥塞的链路。这将导致严重的时延。

维护(maintenance)单个DNS服务器将不得不为所有的因特网主机保留记录。这不仅将使这个中央数据库庞大，而且它还不得不为解决每个新添加的主机而频繁更新。

总的来说，在单一 DNS服务器上运行集中式数据库完全没有可扩展能力。因此，DNS采用了分布式的设计方案。事实上，DNS是一个在因特网上实现分布式数据库的精彩范例

1.分布式、层次数据库

为了处理扩展性问题，DNS使用了大量的DNS服务器，它们以层次方式组织，并且分布在全世界范围内。

没有一台DNS服务器拥有因特网上所有主机的映射。相反,这些映射分布在所有的DNS服务器上。

大致说来，有3种类型的DNS服务器： 根DNS服务器、顶级域(Top Level Domain, TLD) DNS服务器和权威DNS服务器。

这些服务器以图2-17中所示的层次结构组织起来。

为了理解这3种类型的DNS服务器交互的方式，假定一个DNS客户要决定主机名www. amazon, com的IP地址。

粗略说来，将发生下列事件。客户首先与根服务器之一联系，它将返回顶级域名 com的TLD服务器的IP地址。该客户则与这些TLD服务器之一联系，它将为 amazon, com 返回权威服务器的IP地址。

最后，该客户与amazon, com权威服务器之一联系，它为主机名www. amazon, com返回其IP地址。我们将很快更为详细地考察DNS查找过程。不过我们先仔细看一下这3种类型的DNS服务器

根DNS服务器。

有400多个根名字服务器遍及全世界。这些根名字服务器由13个不同的组织管理。根名字服务器的全部清单连同管理它们的组织及其IP地址可以在［Root Servers 2016］中找到。根名字服务器提供TLD服务器的IP地址。

顶级域(DNS)服务器。

对于每个顶级域(如com、org、net、edu和gov)和所有家的顶级域(如uk、fr、ca和jp),都有TLD服务器(或服务器集群)。

VerisignGlobal Registry Services公司维护com顶级域的TLD服务器，Educause公司维护edu顶级域的TLD服务器。支持TLD的网络基础设施可能是大而复杂的，［Osterweil2012］对Verisign网络进行了很好的概述。TLD服务器提供了权威DNS服务器的IP地址。

权威DNS服务器。

在因特网上具有公共可访问主机（如Web服务器和邮件服务器）的每个组织机构必须提供公共可访问的DNS记录，这些记录将这些主机的名字映射为IP地址。

一个组织机构的权威DNS服务器收藏了这些DNS记录。一个组织机构能够选择实现它自己的权威DNS服务器以保存这些记录；另一种方法是，该组织能够支付费用，让这些记录存储在某个服务提供商的一个权威DNS服务器中。多数大学和大公司实现和维护它们自己基本和辅助（备份）的权威DNS服务器

根、TLD和权威DNS服务器都处在该DNS服务器的层次结构中，如图2・17所示。还有另一类重要的DNS服务器，称为本地DNS服务器（local DNS server）。

严格说来，一个本地DNS服务器并不属于该服务器的层次结构，但它对DNS层次结构是至关重要的。

本地域名服务器

每个ISP （如一个居民区的1SP或一个机构的ISP）都有一台本地DNS服务器（也叫默认名字服务器）。

当主机与某个ISP连接时，该ISP提供一台主机的IP地址，该主机具有一台或多台其本地DNS服务器的IP地址。

通过访问Windows或UNIX的网络状态窗口，用户能够容易地确定他的本地DNS服务器的IP地址。

我们来看一个简单的例子，假设主机cse. nyu. edu 想知道主机 gaia. cs. umass. edu的IP地址。

同时假设纽约大学（NYU）的cse. nyu. edu主机的本地DNS服务器为dns. nyu. edu, 并且 gaia. cs. umass. edu 的权威DNS服务器为dns. umass. eduo

如图2 18所示，主机cse. nyu. edu首先向它的本地DNS服务器dns. nyu. edu发送一个DNS查询报文。

该查询报文含有被转换的主机名gaia. cs. umass. eduo

本地DNS服务器将该报文转发到根DNS服务器。

该根DNS服务器注意到其edu前缀并向本地DNS服务器返回负责edu的TLD的IP地址列表。

该本地DNS服务器则再次向这些TLD服务器之一发送查询报文。该TLD服务器注意到umass. edu前缀，并用权威DNS服务器的IP地址进行响应，该权威DNS服务器是负责马萨诸塞大学的dns. umass. eduo最后，本地DNS服务器直接向dns. umass. edu重发查询报文,dns. umass. edu用gaia. cs. umass. edu的IP地址进行响应。注意到在本例中，为了获得一台主机名的映射，共发送了 8份DNS报文：4份查询报文和4份回答报文！我们将很快明白利用DNS缓存减少这种査询流量的方法。

我们前面的例子假设了 TLD服务器知道用于主机的权威DNS服务器的IP地址。一般而言，这种假设并不总是正确的。相反，TLD服务器只是知道中间的某个DNS服务器，该中间DNS服务器依次才能知道用于该主机的权威DNS服务器。例如，再次假设马萨诸塞大学有一台用于本大学的DNS服务器，它称为dns. umass. eduo同时假设该大学的每个系都有自己的DNS服务器，每个系的DNS服务器是本系所有主机的权威服务器。在这种情况下，当中间DNS服务器dns. umass. edu收到了对某主机的请求时，该主机名是以cs. umass.edu结尾，它向dns. nyu. edu返回dns. cs. umass. edu的IP地址，后者是所有以cs. umass. edu结尾的主机的权威服务器。本地DNS服务器dns. nyu. edu则向权威DNS服务器发送查询，该权威DNS服务器向本地DNS服务器返回所希望的映射，该本地服务器依次向请求主机返回该映射。在这个例子中，共发送了 10份DNS报文！

DNS缓存

至此我们的讨论一直忽略了 DNS系统的一个非常重要特色：DNS缓存(DNScaching)

实际上，为了改善时延性能并减少在因特网上到处传输的DNS报文数量，DNS广泛使用了缓存技术。

DNS缓存的原理非常简单。在一个请求链中，当某DNS服务器接收一个DNS回答(例如，包含某主机名到IP地址的映射)时，它能将映射缓存在本地存储器中。

例如，在图2・18中，每当本地DNS服务器dns. nyu. edu从某个DNS服务器接收到一个回答，它能够缓存包含在该回答中的任何信息。如果在DNS服务器中缓存了一台主机名/IP地址对，另一个对相同主机名的查询到达该DNS服务器时，该DNS服务器就能够提供所要求的IP地址，即使它不是该主机名的权威服务器。

由于主机和主机名与IP地址间的映射并不是永久的，DNS服务器在一段时间后(通常设置为两天)将丢弃缓存的信息。

举一个例子，假定主机apricot, nyu. edu向dns. nyu. edu查询主机名cnn. com的IP地址。此后，假定过了几个小时，纽约大学的另外一台主机如kiwi. nyu. edu也向dns. nyu. edu查询相同的主机名。因为有了缓存，该本地DNS服务器可以立即返回cnn. com的IP地址，而不必查询任何其他DNS服务器。本地DNS服务器也能够缓存TLD服务器的IP地址，因而允许本地DNS绕过查询链中的根DNS服务器。事实上，因为缓存，除了少数DNS查询以外，根服务器被绕过了。

DNS记录和报文

共同实现DNS分布式数据库的所有DNS服务器存储了资源记录(Resource Record,RR), RR提供了主机名到IP地址的映射。每个DNS回答报文包含了一条或多条资源记录。

资源记录是一个包含了下列字段的4元组(Name, Valuer Type TTL) TTL是该记录的生存时间，它决定了资源记录应当从缓存中删除的时间。在下面给岀的记录例子中，我们忽略掉TTL字段。Name和Value的值取决于Type：

如果一台DNS服务器是用于某特定主机名的权威DNS服务器，那么该DNS服务器会有一条包含用于该主机名的类型A记录(即使该DNS服务器不是其权威DNS服务器，它也可能在缓存中包含有一条类型A记录)。

如果服务器不是用于某主机名的权威服务器,那么该服务器将包含一条类型NS记录，该记录对应于包含主机名的域；它还将包括一条类型A记录，该记录提供了在NS记录的Value字段中的DNS服务器的IP地址。

举例来说，假设一台edu TLD服务器不是主机gaia. cs. umass. edu的权威DNS服务器，则该服务器将包含一条包括主机cs. umass. edu的域记录，如 (umass. edu, dns. umass. edu, NS)；

该edu TLD服务器还将包含一条类型A记录,如(dns. umass. edu, 128. 119. 40. Ill A)该记录将名字dns. umass. edu映射为一个IP地址。

1. DNS报文

在本节前面，我们提到了 DNS查询和回答报文。DNS只有这两种报文，并且，查询和回答报文有着相同的格式，如图2・20所示。DNS报文中各字段的语义如下：

2.在DNS数据库中插入记录

上面的讨论只是关注如何从DNS数据库中取数据。你可能想知道这些数据最初是怎么进入数据库中的。我们在一个特定的例子中看看这是如何完成的。

假定你刚刚创建一个称为网络乌托邦（Network Utopia）的令人兴奋的新创业公司。你必定要做的第一件事是在注册登记机构注册域名networkutopia. como 注册登记机构（registrar）是一个商业实体,它验证该域名的唯一性，将该域名输入DNS数据库（如下面所讨论的那样），对提供的服务收取少量费用。

1999年前，唯一的注册登记机构是Nework Solution,它独家经营对于com. net和org域名的注册。但是现在有许多注册登记机构竞争客户，因特网名字和地址分配机构向各种注册登记机构授权。

在http:〃www. intemic. net上可以找到授权的注册登记机构的列表。当你向某些注册登记机构注册域名networkutopia, com时，需要向该机构提供你的基本和辅助权威DNS服务器的名字和IP地址。

假定该名字和1P地址是dnsl. networkutopia, com和 dns2. networkutopia, com 及 212. 212. 212. 1 和 212. 212. 212. 2O 对这两个权威 DNS 服务器的每一个，该注册登记机构确保将一个类型NS和一个类型A的记录输入TLD com服务益。特别是对于用于networkutopia, com的基本权威服务器，该注册登记机构将下列两条资源记录插入该DNS系统中：

你还必须确保用于Web服务器www. networkutopia, com的类型A资源记录和用于邮件服务器mail, networkutopia, com的类型MX资源记录被输入你的权威DNS服务器中。

（直到最近，每台DNS服务器中的内容都是静态配置的，例如来自系统管理员创建的配置文件。最近，在DNS协议中添加了一个更新（UPDATE）选项，允许通过DNS报文对数据库中的内容进行动态添加或者删除。

一旦完成所有这些步骤，人们将能够访问你的Web站点，并向你公司的雇员发送电子邮件。我们通过验证该说法的正确性来总结DNS的讨论。这种验证也有助于充实我们已经学到的DNS知识。

假定在澳大利亚的Alice要观看www. networkutopia, com的Web页面。如前面所讨论，她的主机将首先向其本地DNS服务器发送请求。

该本地服务器接着则联系一个TLD com服务器。（如果TLD com服务器的地址没有被缓存，该本地DNS服务器也将必须与根DNS服务器相联系。）

该TLD服务器包含前面列出的类型NS和类型A资源记录，因为注册登记机构将这些资源记录插入所有的TLD com服务器。该TLD com服务器向Alice的本地DNS服务器发送一个回答，该回答包含了这两条资源记录。

该本地DNS服务器则向212. 212. 212. 1发送一个DNS査询,请求对应于www. networkutopia, com的类型A记录。该记录提供了所希望的Web服务器的IP地址，如212.212.71.4,本地DNS服务器将该地址回传给Alice的主机。Alice的浏览器此时能够向主机212. 212. 71. 4发起一个TCP连接，并在该连接上发送一个HTTP请求。

DNS域名解析过程

DNS安全性

我们已经看到DNS是因特网基础设施的一个至关重要的组件，对于包括Web、电子邮件等的许多重要的服务，没有它都不能正常工作。因此，我们自然要问，DNS怎么能够被攻击呢？ DNS是一个易受攻击的目标吗？它是将会被淘汰的服务吗？大多数因特网应用会随同它一起无法工作吗？ -想到的第一种针对DNS服务的攻击是分布式拒绝服务（DDoS）带宽洪泛攻击。

例如，某攻击者能够试图向每个DNS根服务器发送大量的分组，使得大多数合法DNS请求得不到回答。这种对DNS根服务器的DDoS大规模攻击实际发生在2002年10月21日。

在这次攻击中，该攻击者利用一个僵尸网络向13个DNS根服务器中的每个都发送了大批的ICMP ping报文负载。

幸运的是，这种大规模攻击所带来的损害很小，对用户的因特网体验几乎没有或根本没有影响。攻击者的确成功地将大量的分组指向了根服务器，但许多DNS根服务器受到了分组过滤器的保护，配置的分组过滤器阻挡了所有指向根服务器的ICMP 报文。这些被保护的服务器因此未受伤害并且与平常一样发挥着作用。

此外，大多数本地DNS服务器缓存了顶级域名服务器的IP地址，使得这些请求过程通常绕过了 DNS根服务器）对DNS的潜在更为有效的DDoS攻击将是向顶级域名服务器（例如向所有处理.com域的顶级域名服务器）发送大量的DNS请求。

过滤指向DNS服务器的DNS请求将更为困难，并且顶级域名服务器不像根服务器那样容易绕过。但是这种攻击的严重性通过本地DNS服务器中的缓存技术可将部分地被缓解。DNS能够潜在地以其他方式被攻击。在中间人攻击中，攻击者截获来自主机的请求并返回伪造的回答。在DNS毒害攻击中，攻击者向一台DNS服务器发送伪造的回答,诱使服务器在它的缓存中接收伪造的记录。这些攻击中的任一种，都能够将毫无疑虑的Web用户重定向到攻击者的Web站点。

然而，这些攻击难以实现，因为它们要求截获分组或扼制住服务器［Skoudis 2006 ］。总而言之，DNS自身已经显示了对抗攻击的令人惊讶的健壮性。至今为止，还没有一个攻击已经成功地妨碍了 DNS服务°

P2P文件分发

在目前为止本章中描述的应用（包括Web、电子邮件和DNS）都采用了客户-服务器体系结构，极大地依赖于总是打开的基础设施服务器。

使用P2P体系结构，对总是打开的基础设施服务器有最小的（或者没有）依赖。与之相反，成对间歇连接的主机（称为对等方）彼此直接通信。这些对等方并不为服务提供商所拥有，而是受用户控制的桌面计算机和膝上计算机。

在本节中我们将研究一个非常自然的P2P应用，即从单一服务器向大量主机（称为对应用层 ）分发一个大文件。该文件也许是一个新版的Linux操作系统，对于现有操作系统或应用程序的一个软件补丁，一个MP3音乐文件，或一个MPEG视频文件。

在客户-服务器文件分发中，该服务器必须向每个对等方发送该文件的一个副本，即服务器承受了极大的负担，并且消耗了大量的服务器带宽。

在P2P文件分发中，每个对等方能够向任何其他对等方重新分发它已经收到的该文件的任何部分，从而在分发过程中协助该服务器。

到2016年止，最为流行的P2P文件分发协议是BitTorrento该应用程序最初由Bram Cohen所研发，现在有许多不同的独立且符合BitTorrent协议的BitTorrent客户，就像有许多符合HTTP协议的Web浏览器客户一样。

我们首先考察在文件分发环境中的P2P体系结构的自扩展性。然后我们更为详细地描述BitTorrent,突出它的最为重要的特性和特色。

P2P体系结构的扩展性

为了将客户-服务器体系结构与P2P体系结构进行比较，阐述P2P的内在自扩展性,我们现在考虑一个用于两种体系结构类型的简单定量模型，将一个文件分发给一个固定对等方集合。

小结

在本章中，我们学习了网络应用的概念和实现两个方面。我们学习了被因特网应用普遍采用的客户-服务器模式，并且看到了该模式在HTTP、SMTP、POP3和DNS等协议中的使用。我们已经更为详细地学习了这些重要的应用层协议以及与之对应的相关应用(Web、文件传输、电子邮件和DNS)

我们描述了 TCP和UDP为调用它们的应用提供的服务模型。当我们在2. 7节中开发运行在TCP和UDP之上的简单应用程序时，我们对这些服务模型进行了更加深入的观察。然而，我们几乎没有介绍TCP和UDP是如何提供这种服务模型的。例如,我们知道TCP提供了一种可靠数据服务，但我们未说它是如何做到这一点的。在下一章中我们将不仅关注运输协议是什么，而且还关注它如何工作以及为什么要这么做。

Original: https://www.cnblogs.com/spring-ioc/p/16337793.html
Author: 你问人生何
Title: 计算机网络—应用层