计算机网络自顶向下第二章应用层

应用层协议原理

网络应用的体系架构

可能的应用架构：

1. 客户-服务器模式（C/S:client/server）
2. 对等模式(P2P:Peer To Peer)
3. 混合体：客户-服务器和对等体系结构

客户-服务器（C/S）体系结构

服务器:

1. 一直运行
2. 固定的IP地址和周知的端口号（约定）
3. 扩展性：服务器场
4. 数据中心进行扩展，一个数据中心能够有数十万台服务器， 它们必须要供电和维护。
5. 扩展性差

客户端:

1. 主动与服务器通信
2. 与互联网有间歇性的连接
3. 可能是动态IP地址
4. 不直接与其它客户端通信

对等体（P2P）体系结构

对位于数据中心的专用服务器有最小的( 或者没有） 依赖

特点：

1. （几乎）没有一直运行的服务器
2. 任意端系统之间可以进行通信
3. 每一个节点既是客户端又是服务器
4. 自扩展性-新peer节点带来新的服务能力，当然也带来新的服务请求
5. 参与的主机间歇性连接且可以改变IP地址
6. 难以管理
7. 例子: Gnutella，迅雷

C/S和P2P体系结构的混合体

Napster
文件搜索：集中C/S

• 主机在中心服务器上注册其资源
• 主机向中心服务器查询资源位置

文件传输：P2P

• 任意Peer节点之间

即时通信
在线检测：集中C/S

• 当用户上线时，向中心服务器注册其IP地址
• 用户与中心服务器联系，以找到其在线好友的位置

两个用户之间聊天：P2P

进程通信

进程：在主机上运行的应用程序

1. 在同一个主机内，使用进程间通信机制通信（操作系统定义）
2. 在两个不同端系统上的进程， 通过跨越计算机网络交换报文（ message) 而相互通信。发送进程生成并向网络中发送报文； 接收进程接收这些报文并可能通过回送报文进行响应
3. 借助传输层提供的服务

客户和服务器进程

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

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

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

套接字是同一台主机内应用层与运输层之间的接口。 由于该套接字是建立网络应用程序的可编程接口， 因此套接字也称为应用程序和网络之间的应用程序编程接口（ Application Programming Interface， API )。 应用程序开发者可以控制套接字在应用层端的一切， 但是对该套接字的运输层端几乎没有控制权。 应用程序开发者对于运输层的控制仅限于： ①选择运输层协议； ②也许能设定几个运输层参数， 如最大缓存和最大报文段长度等（ 将在第 3 章中涉及）。 一旦应用程序开发者选择了一个运输层协议（ 如果可供选择的话） ， 则应用程序就建立在由该协议提供的运输层服务之上。

进程寻址

为了向特定目的地发送邮政邮件， 目的地需要有一个地址。 类似地， 在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组， 接收进程需要有一个地址。 为了标识该接收进程， 需要定义两种信息： ①主机的地址； ②在目的主机中指定接收进程的标识符。

主机由其 IP 地址 ( IP address) 标识 。流行的应用分配特定的端口号。

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

可靠数据传输

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

当一个运输层协议不提供可靠数据传输时， 由发送进程发送的某些数据可能到达不了接收进程。 这可能能被容忍丢失的应用（ loss- tolerant application) 所接受， 最值得注意的是多媒体应用， 如交谈式音频/视频， 它们能够承受一定量的数据丢失。

吞吐量

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

有吞吐量要求的应用程序被称为带宽敏感的应用 ( bandwidth-sensitive application) 。带宽敏感的应用具有特定的吞吐量要求， 而弹性应用 ( elastic application ) 能够根据当时可用的带宽或多或少地利用可供使用的吞吐量。

定时

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

安全性

运输协议能够为应用程序提供一种或多种安全性服务。 例如， 在发送主机中， 运输协议能够加密由发送进程传输的所有数据， 在接收主机中， 运输层协议能够在将数据交付给接收进程之前解密这些数据。

因特网提供的运输服务

TCP服务

1. 可靠的传输服务，通信进程能够依靠 TCP， 无差错、 按适当顺序交付所有发送的数据。 当应用程序的一端将字节流传进套接字时， 它能够依靠 TCP 将相同的字节流交付给接收方的套接字， 而没有字节的丢失和冗余。
2. 流量控制：发送方不会淹没接受方
3. 拥塞控制：当网络出现拥塞时，能抑制发送方。这种服务不一定能为通信进程带来直接好处， 但能为因特网带来整体好处。
4. 不能提供的服务：时间保证、最小吞吐保证和安全
5. 面向连接：要求在客户端进程和服务器进程之间建立连接 。TCP 让客户和服务器互相交换运输层控制信息。 这个所谓的握手过程提醒客户和服务器， 让它们为大量分组的到来做好准备。

UDP 服务

1. 不可靠数据传输
2. 不提供的服务：可靠，流量控制、拥塞控制、时间、带宽保证、建立连接

UDP存在的必要性

1. 能够区分不同的进程，而IP服务不能。在IP提供的主机到主机端到端功能的基础上，区分了主机的应用进程
2. 无需建立连接，省去了建立连接时间，适合事务性的应用
3. 不做可靠性的工作，例如检错重发，适合那些对实时性要求比较高而对正确性要求不高的应用。因为为了实现可靠性（准确性、保序等），必须付出时间代价（检错重发）
4. 没有拥塞控制和流量控制，应用能够按照设定的速度发送数据。而在TCP上面的应用，应用发送数据的速度和主机向网络发送的实际速度是不一致的，因为有流量控制和拥塞控制

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

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

无论 TCP 还是 UDP 都没有提供任何加密机制， 这就是说发送进程传进其套接字的数据， 与经网络传送到目的进程的数据相同。 因此， 举例来说如果某发送进程以明文方式（ 即没有加密） 发送了一个口令进入它的套接字， 该明文口令将经过发送方与接收方之间的所有链路传送， 这就可能在任何中间链路被嗅探和发现。 因为隐私和其他安全问题对许多应用而言已经成为至关重要的问题， 所以因特网界已经研制了 TCP 的加强版本， 称为安全套接字层（ Secure Sockets Layer， SSL)。 用 SSL 加强后的 TCP 不仅能够做传统的 TCP 所能做的一切， 而且提供了关键的进程到进程的安全性服务， 包括加密、 数据完整性和端点鉴别。 我们强调 SSL 不是与 TCP 和 UDP 在相同层次上的第三种因特网运输协议， 而是一种对 TCP 的加强， 这种强化是在应用层上实现的。 特别是， 如果一个应用程序要使用 SSL 的服务， 它需要在该应用程序的客户端和服务器端包括 SSL 代码( 利用现有的、 高度优化的库和类）。 SSL 有它自己的套接字 API, 这类似于传统的 TCP套接字 API。 当一个应用使用 SSL 时， 发送进程向 SSL 套接字传递明文数据； 在发送主机中的 SSL 则加密该数据并将加密的数据传递给 TCP 套接字。 加密的数据经因特网传送到接收进程中的 TCP 套接字。 该接收套接字将加密数据传递给 SSL, 由其进行解密。 最后， SSL 通过它的 SSL 套接字将明文数据传递给接收进程。 我们将在第 8 章中更为详细地讨论 SSL。

应用层协议

应用层协议定义了：

• 交换的报文类型， 例如请求报文和响应报文。
• 各种报文类型的语法， 如报文中的各个字段及这些字段是如何描述的。
• 字段的语义， 即这些字段中的信息的含义。
• 确定一个进程何时以及如何发送报文， 对报文进行响应的规则。

有些应用层协议是由 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 也只是电子邮件应用的一个部分( 尽管是重要部分）。

Web 和 HTTP

HTTP 概况

Web 的应用层协议是超文本传输协议（ HyperText Transfer Protocol， HTTP), 它是 Web的核心， 在 [ RFC 1945] 和 [ RFC 2616] 中进行了定义。 客户程序和服务器程序运行在不同的端系统中， 通过交换HTTP 报文进行会话。 HTTP 定义了这些报文的结构以及客户和服务器进行报文交换的方式。

HTTP 定义了 Web 客户向 Web 服务器请求 Web 页面的方式， 以及服务器向客户传送 Web 页面的方式。 当用户请求一个 Web 页面 （ 如点击一个超链接） 时， 浏览器向服务器发出对该页面中所包含对象的HTTP请求报文， 服务器接收到请求并用包含这些对象的 HTTP 响应报文进行相应。

HTTP 使用 TCP 作为它的支撑运输协议（ 而不是在 UDP 上运行）。 HTTP 客户首先发起一个与服务器的 TCP 连接。 一旦连接建立， 该浏览器和服务器进程就可以通过套接字接口访问 TCP。这里我们看到了分层体系结构最大的优点， 即 HTTP 协议不用担心数据丢失， 也不关注 TCP 从网络的数据丢失和乱序故障中恢复的细节。 那是 TCP 以及协议栈较低层协议的工作。

注意到下列现象很重要： 服务器向客户发送被请求的文件， 而不存储任何关于该客户的状态信息。 假如某个特定的客户在短短的几秒内两次请求同一个对象， 服务器并不会因为刚刚为该客户提供了该对象就不再做出反应， 而是重新发送该对象， 就像服务器已经完全忘记不久之前所做过的事一样。 因为 HTTP 服务器并不保存关于客户的任何信息， 所以我们说 HTTP 是一个无状态协议（ stateless protocol )。 我们同时也注意到 Web 使用了客户- 服务器应用程序体系结构 （ 如 2.1 节所述）。 Web 服务器总是打开的， 具有一个固定的IP 地址， 且它服务于可能来自数以百万计的不同浏览器的请求。

非持续连接和持续连接

采用非持续连接的 HTTP

我们看看在非持续连接情况下， 从服务器向客户传送一个 Web 页面的步骤。 假设该页面含有一个 HTML 基本文件和 10 个 JPEG 图形， 并且这 11 个对象位于同一台服务器上。 进—步假设该 HTML 文件的 URL 为： http:/www.someSchool.edu/someDepartment/home.index。

上面的步骤举例说明了非持续连接的使用， 其中每个 TCP 连接在服务器发送一个对象后关闭， 即该连接并不为其他的对象而持续下来。 值得注意的是每个 TCP 连接只传输一个请求报文和一个响应报文。 因此在本例中， 当用户请求该 Web 页面时， 要产生 11 个 TCP 连接。

往返时间（ Round-Trip Time, RTT) 的定义，该时间是指一个短分组从客户到服务器然后再返回客户所花费的时间。 RTT 包括分组传 播时延、 分组在中间路由器和交换机上的排 队时延以及分组处理时延。现在考虑当用户点击超链接时会发生什么现象。这引起浏览器在它和 Web 服务器之间发起一个 TCP 连接； 这涉及一次 “ 三次握手” 过程，即客户向服务器发送一个小 TCP 报文段， 服务器用一个小 TCP 报文段做出确认和响应，最后， 客户向服务器返回确认。 三次握手中前两个部分所耗费的时间占用了一个 RTT。 完成了三次握手的前两个部分后， 客户结合三次握手的第三部分（ 确认） 向该 TCP 连接发送一个 HTTP 请求报文。 一旦该请求报文到达服务器， 服务器就在该 TCP 连接上发送HTML文件。 该 HTTP 请求/响应用去了另一个 RTT。 因此， 粗略地讲， 总的响应时间就是两个 RTT 加上服务器传输 HTML 文件的时间。

采用持续连接的 HTTP

在采用 HTTP 1.1 持续连接的情况下， 服务器在发送响应后保持该 TCP 连接打开。 在相同的客户与服务器之间， 后续的请求和响应报文能够通过相同的连接进行传送。 特别是， 一个完整的 Web 页面 （ 上例中的 HTML 基本文件加上 10 个图形） 可以用单个持续TCP 连接进行传送。

HTTP报文格式

HTTP请求报文

HTTP报文传过来都是一堆的0x ASCII码，诸如“41 63 63 65 70 74” 对应的是“accept” 单词的十六进制ASCII码。

这些十六进制的数字经过浏览器或者专用工具比如wireshark的翻译，可以得到HTTP的报文结构。

HTTP的请求报文包括：请求行(request line)、请求头部(header)、空行 和 请求数据(request data) 四个部分组成。

请求行包括： 请求方法，URL(包括参数信息)，协议版本这些信息（GET /admin_ui/rdx/core/images/close.png HTTP/1.1）

请求头部(Header)是一个个的key-value值，比如Accept-Encoding: gzip, deflate，，User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)
空行(CR+LF)：请求报文用空行表示header和请求数据的分隔

请求数据：GET方法没有携带数据， POST方法会携带一个body

HTTP相应报文

HTTP的响应报文包括：状态行，响应头，空行，数据(响应体)

状态行包括：HTTP版本号，状态码和状态值组成。

响应头类似请求头，是一系列key-value值

• Cache-Control: private
• Content-Encoding: gzip
• Server: BWS/1.1
• Set-Cookie: delPer=0; path=/; domain=.baidu.com

空白行：同上，响应报文也用空白行来分隔header和数据

响应体：响应的data，本例中是一段HTML

我们补充说明一下状态码和它们对应的短语。 状态码及其相应的短语指示了请求的结果。 一些常见的状态码和相关的短语包括：
• 200 0K： 请求成功， 信息在返回的响应报文中。
• 301 Moved Permanently： 请求的对象已经被永久转移了， 新的 URL 定义在响应报文的 Location: 首部行中。 客户软件将自动获取新的 URL。
• 400 Bad Request： —个通用差错代码， 指示该请求不能被服务器理解。
• 404 Not Found： 被请求的文档不在服务器上。
• 505 HTTP Version Not Supported： 服务器不支持请求报文使用的 HTTP 协议版本。

用户与服务器的交互： cookie

4个组成部分：

1)在HTTP响应报文中有一个cookie的首部行
2)在HTTP请求报文含有一个cookie的首部行
3)在用户端系统中保留有一个cookie文件，由用户的浏览器管理
4)在Web站点有一个后端数据库

例子：
Susan总是用同一个PC使用Internet Explore上网。她第一次访问了一个使用了Cookie的电子商务网站。。当最初的HTTP请求到达服务器时，该Web站点产生一个唯一的ID，并以此作为索引在它的后端数据库中产生一个项 。

服务器通过该头部告知客户端保存 Cookie 信息。。该浏览器在它管理的特定 cookie 文件中添加一行， 该行包含服务器的主机名和在 Set- cookie: 首部中的识别码。 现在，对该服务器发起的每一次新请求，浏览器都会将之前保存的Cookie信息通过 Cookie 请求头部再发送给服务器。

Web 缓存

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

举例来说， 假设浏览器正在 请求对象 http://www.someschool.edu, 将会发生如下情况：

1. 浏览器创建一个到 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 缓存器， 并且预先配置其配套的浏览器指向这些缓存器。

条 件 GET 方 法

FTP

文件传输协议（File Transfer Protocol，FTP）是用于在网络上进行文件传输的一套标准协议，它工作在 OSI 模型的第七层， TCP 模型的第四层， 即应用层， 使用 TCP 传输而不是 UDP， 客户在和服务器建立连接前要经过一个“三次握手”的过程， 保证客户与服务器之间的连接是可靠的， 而且是面向连接， 为数据传输提供可靠保证。

该协议是Internet文件传送的基础，它由一系列规格说明文档组成，目标是提高文件的共享性，提供非直接使用远程计算机，使存储介质对用户透明 和可靠高效地传送数据。简单的说，FTP就是完成两台计算机之间的拷贝，从远程计算机拷贝文件至自己的计算机上，称之为“下载 （download）”文件。若将文件从自己计算机中拷贝至远程计算机上，则称之为“上载（upload）”文件。

FTP服务器和客户端

用户通过一个客户机程序连接至在远程计算机上运行的服务器程序。依照 FTP 协议提供服务，进行文件传送的计算机就是 FTP 服务器，而连接FTP服务器，遵循FTP协议与服务器传送文件的电脑就是FTP客户端。用户要连上 FTP 服务器，就要用到 FPT 的客户端软件，通常 Windows自带“ftp”命令，这是一个命令行的 FTP 客户程序，另外常用的 FTP 客户程序还有 CuteFTP、Ws_FTP、Flashfxp、LeapFTP、流星雨-猫眼等。

匿名FTP

要连上 FTP 服务器（即“登陆”），必须要有该 FTP 服务器授权的帐号，也就是说你只有在有了一个用户标识和一个口令后才能登陆FTP服务器，享受FTP服务器提供的服务。

互连网中有很大一部分 FTP 服务器被称为“匿名”（Anonymous）FTP 服务器。这类服务器的目的是向公众提供文件拷贝服务，不要求用户事先在该服务器进行登记注册，也不用取得FTP服务器的授权。Anonymous（匿名文 件传输）能够使用户与远程主机建立连接并以匿名身份从远程主机上拷贝文件，而不必是该远程主机的注册用户。用户使用特殊的用户名“anonymous”登 陆FTP服务，就可访问远程主机上公开的文件。许多系统要求用户将Emai1地址作为口令，以便更好地对访问进行跟综。匿名FTP一直是Internet 上获取信息资源的最主要方式，在Internet成千上万的匿名FTP主机中存储着无以计数的文件，这些文件包含了各种各样的信息，数据和软件。

FTP的传输模式

FTP的传输有两种方式：ASCII传输模式和二进制数据传输模式。

1．ASCII传输方式：假定用户正在拷贝的文件包含的简单ASCII码文本，如果在远程机器上运行的不是UNIX，当文件传输时ftp通常会自动 地调整文件的内容以便于把文件解释成另外那台计算机存储文本文件的格式。但是常常有这样的情况，用户正在传输的文件包含的不是文本文件，它们可能是程序， 数据库，字处理文件或者压缩文件（尽管字处理文件包含的大部分是文本，其中也包含有指示页尺寸，字库等信息的非打印符）。在拷贝任何非文本文件之前，用 binary 命令告诉ftp逐字拷贝，不要对这些文件进行处理，这也是下面要讲的二进制传输。

2．二进制传输模式：在二进制传输中，保存文件的位序，以便原始和拷贝的是逐位一一对应的。即使目的地机器上包含位序列的文件是没意义的。例 如，macintosh以二进制方式传送可执行文件到Windows系统，在对方系统上，此文件不能执行。如果你在ASCII方式下传输二进制文件，即使 不需要也仍会转译。这会使传输稍微变慢 ，也会损坏数据，使文件变得不能用。（在大多数计算机上，ASCII方式一般假设每一字符的第一有效位无意义，因为ASCII字符组合不使用它。如果你传 输二进制文件，所有的位都是重要的。）如果你知道这两台机器是同样的，则二进制方式对文本文件和数据文件都是有效的。

FTP的工作方式

PORT（主动）方式的连接过程是：客户端向服务器的FTP端口（默认是21）发送连接请求，服务器接受连接，建立一条命令链路。 当需要传送数据时， 客户端在命令链路上用PORT命令告诉服务器：“我打开了X端口，你过来连接我”。于是服务器从20端口向客户端的X端口发送连接请求，建立 一条数据链路来传送数据。

　　PASV（被动）方式的连接过程是：客户端向服务器的FTP端口（默认是21）发送连接请求，服务器接受连接，建立一条命令链路。 当需要传送数据时， 服务器在命令链路上用PASV命令告诉客户端：“我打开了X端口，你过来连接我”。于是客户端向服务器的X端口发送连接请求，建立一条数据链 路来传送数据。

主动模式传送数据时是“服务器”连接到“客户端”的端口；

被动模式传送数据是“客户端”连接到“服务器”的端口。

主动模式需要客户端必须开放端口给服务器，很多客户端都是在防火墙内，开放端口给FTP服务器访问比较困难

被动模式只需要服务器端开放端口给客户端连接就行了。

FTP服务器一般都支持主动和被动模式，连接采用何种模式是有FTP客户端软件决定。

EMAIL

3个主要组成部分： 用户代理 （ user agent)、 邮件服务器 （ mail server) 和简单邮件传输协议（ Simple Mail Transfer Protocol, SMTP)。

用户代理

1. 又名 “邮件阅读器”
2. 撰写、编辑和阅读邮件
3. 如Outlook、Foxmail
4. 输出和输入邮件保存在服务器上

邮件服务器

1. 邮箱中管理和维护发送给用户的邮件
2. 输出报文队列保持待发送邮件报文
3. 邮件服务器之间的SMTP协议：发送email报文。
4. 客户：发送方邮件服务器。服务器：接收端邮件服务器

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

SMTP

为了描述 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 客户（ C) 和 SMTP 服务器（ S) 之间交换报文文本的例子。 客户的主机名为 crepes,fr， 服务器的主机名为 hamburger,edu。 以 C: 开 头 的 ASCII 码文本行正是客户交给其 TCP 套接字的那些行， 以 S: 开 头 的 ASCII 码则是服务器发送给其TCP 套接字的那些行。 一旦创建了 TCP 连接， 就开始了下列过程。

在上例中， 客户从邮件服务器 crepes,fr 向邮件服务器 hamburger,edu 发送了一个报文( “ D o you like ketchup? How about pickles?”）。 作为对话的一部分， 该客户发送了 5 条命令： HEL0 ( 是 HELLO 的缩写） 、 MAIL FROM 、 RCPT T0、 DATA 以及 QUIT。 这些命令都是自解释的。 该客户通过发送一个只包含一个句点的行， 向服务器指示该报文结束了。( 按照 ASCII 码的表示方法， 每个报文以 CRLF.CRLF 结束， 其中的 CR 和 LF 分别表示回车和换行。 ） 服务器对每条命令做出回答， 其中每个回答含有一个回答码和一些（ 可选的） 英文解释。 我们在这里指出 SMTP 用的是持续连接： 如果发送邮件服务器有几个报文发往同一个接收邮件服务器， 它可以通过同一个 TCP 连接发送这些所有的报文。 对每个报文， 该客户用一个新的 MAIL FROM: crepes,fr 开始， 用一个独立的句点指示该邮件的结束， 并且仅当所有邮件发送完后才发送 QUIT。

与 HTTP 的对比

1. 首先， HTTP 主要是一个拉协议 （ pull protocol ),即在方便的时候， 某些人在 Web 服务器上装载信息， 用户使用 HTTP 从该服务器拉取这些信息。 特别是 TCP 连接是由想接收文件的机器发起的。 另一方面， SMTP 基本上是一个推协议 ( push protocol) , 即发送邮件服务器把文件推向接收邮件服务器。 特别是， 这个 TCP连接是由要发送该文件的机器发起的。
2. SMTP 要求每个报文（ 包括它们的体） 采用 7 比特 ASCII 码格式。 如果某报文包含了非 7 比特 ASCII 字符（ 如具有重音的法文字符） 或二进制数据 （ 如图形文件） ， 则该报文必须按照7 比特 ASCII 码进行编码。 HTTP 数据则不受这种限制。
3. 第三个重要区别是如何处理一个既包含文本又包含图形 （ 也可能是其他媒体类型） 的文档。 如我们在 2. 2 节知道的那样， HTTP 把每个对象封装到它自己的 HTTP 响应报文中，而 SMTP 则把所有报文对象放在一个报文之中。

邮件报文格式

首部行和该报文的体用空行（ 即回车换行）进行分隔。 RFC 5322 定义了邮件首部行和它们的语义解释的精确格式。 如同 HTTP 协议，每个首部行包含了可读的文本， 是由关键词后跟冒号及其值组成的。 某些关键词是必需的， 另一些则是可选的。 每个首部必须含有一个 From: 首部行和一个 To: 首部行； 一个首部也许包含一个 Subject: 首部行以及其他可选的首部行。 重要的是注意到下列事实.• 这些首部行不同于我们在 2. 3.1 节所学到的 SMTP 命令（ 即使那里包含了某些相同的词汇，如 from 和 to)。 那节中的命令是 SMTP 握手协议的一部分； 本节中考察的首部行则是邮件报文自身的一部分。

邮件访问协议

前面讲过邮件服务器管理用户的邮箱， 并且运行 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。

POP3

当用户代理（ 客户） 打开了一个到邮件服务器 （ 服务器） 端口 110 上的 TCP 连接后， POP3 就开始工作了。 随着建立 TCP连接，POP3 按照三个阶段进行工作： 特许（ authorization )、 事务处理以及更新。 在第一个阶段即特许阶段， 用户代理发送（ 以明文形式） 用户名和口令以鉴别用户。 在第二个阶段即事务处理阶段， 用户代理取回报文； 同时在这个阶段用户代理还能进行如下操作， 对报文做删除标记， 取消报文删除标记， 以及获取邮件的统计信息。 在第三个阶段即更新阶段， 它出现在客户发岀了 quit 命令之后， 目的是结束该 POP3 会话； 这时， 该邮件服务器删除那些被标记为删除的报文

• 先前的例子使用 “下载并删除”模式。如果改变客户机，Bob不能阅读邮件
• 下载并保留”：不同客户机上为报文的拷贝，能继续阅读邮件
• POP3在会话中是无状态的 。在用户代理与邮件服务器之间的 POP3 会话期间， 该 POP3 服务器保留了一些状态信息； 特别是记录了哪些用户报文被标记为删除了。 然而， POP3 服务器并不在 POP3 会话过程中携带状态信息。

IMAP

使用一个在远程服务器上的层次文件夹 ， 这样他可以从任何一台机器上对所有报文进行访问。 使用 POP3 是不可能做到这一点的， POP3 协议没有给用户提供任何创建远程文件夹并为报文指派文件夹的方法。 POP3只能将报文存入本地文件夹。

IMAP 服务器把每个报文与一个文件夹联系起来； 当报文第一次到达服务器时， 它与收件人的 INBOX 文件夹相关联。 收件人则能够把邮件移到一个新的 、 用户创建的文件夹中， 阅读邮件， 删除邮件等。 IMAP 协议为用户提供了创建文件夹以及将邮件从一个文件夹移动到另一个文件夹的命令。 IMAP 还为用户提供了在远程文件夹中查询邮件的命令， 按指定条件去査询匹配的邮件。 值得注意的是， 与 POP3 不同，IMAP 服务器维护了 IMAP 会话的用户状态信息， 例如， 文件夹的名字以及哪些报文与哪些文件夹相关联。

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

基于 Web 的电子邮件

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

DNS： 因特网的目录服务

DNS提供的服务

域名系统( Domain Name System, DNS) 是：1.一个由分层的DNS服务器实现的分布式数据库；2. 一个使主机能够查询分布式数据库的应用协议。
DNS协议运行在UDP上，使用53号端口。

与http，FTP，SMTP协议一样，DNS协议是应用层协议，其原因在于：

1. 使用客户-服务器模式运行在通信的端系统之间；
2. 在通信的端系统之间通过下面的端到段运输协议来传送DNS报文。

考虑当某个用户主机上的一个浏览器（即一个HTTP客户请求URLwww.someschool.edu/index.html 页面时会发生什么现象。为了使主机能够请求报文发送到web服务器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连接。

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

• 主机别名 ( host aliasing)Q 有着复杂主机名的主机能拥有一个或者多个别名。
• 邮件服务器别名
• 负 载 分 配（ load distribution )。 DNS 也用于在冗余的服务器（ 如冗余的 Web 服务器等） 之间进行负载分配。 繁忙的站点（ 如 crm.com) 被冗余分布在多台服务器上，每台服务器均运行在不同的端系统上， 每个都有着不同的 IP 地址。

DNS的工作机理概念

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

分布式、层次数据库

为了处理扩展性问题，DNS使用了大量DNS服务器，他们以层次方式组织并且分布在全世界范围内。大致来说有3中类型的DNS服务器：根DNS服务器、顶级域（TLD）DNS服务器和权威DNS服务器。

为了处理扩展性问题，DNS服务器采用层次式组织，并且分布在全世界范围内；大致来说，存在三种DNS服务器：根DNS服务器、顶级域（Top Level Domain, TLD）DNS服务器和权威DNS服务器。举例说明，假定一个 DNS 客户要获取主机名 www.amazon.com 的 IP 地址。客户首先与根服务器之一联系，它将返回顶级域名 com 的 TLD 服务器的 IP地址。 该客户与这些 TLD 服务器之一联系，它将为 amazon.com 返回权威服务器的 IP 地址。最后，客户与amazon.com 权威服务器之一联系，返回其 IP 地址。

• 根DNS服务器：因特网上有13个根DNS服务器，大部分分布在北美洲。
• 顶级域DNS服务器：负责顶级域名，如com，org，net，edu，gov以及各个国家的顶级域名的转换。
• 权威DNS服务器：组织的域名解析服务器，提供内部服务器的解析服务

除了上面三种DNS服务器，还有一种不在DNS层次结构之中，但是很重要的DNS，是本地DNS服务器。本地DNS服务器通常邻近其所在网络的其他主机。当主机发出DNS请求时，该请求被发往本地DNS服务器，它起着代理的作用，并将请求转发到DNS服务器层次结构中。

DNS查询有两种，一种是递归查询一种是迭代查询；实践中，查询通常满足这样的模式：从请求主机到本地DNS服务器的查询是递归的，其余查询是迭代的。

递归查询：

个人感觉，递归就是A问B，B一定会回给A一个具体的ip地址，至于B怎么得到这个ip，你不用管，因为B会抛给后面的继续递归。而迭代就是Ａ问Ｂ，Ｂ然后就叫A去问别人而不是回给A一个具体的ip。

DNS缓存

DNS缓存实际上是为了改善时延性能并且减少在因特网上传输的DNS报文数量而引入的。DNS缓存原理十分简单，每当DNS服务器发出请求后收到回答时，就将回答的内容缓存在它自己的主机空间上。这样，如果有相同的请求到达时，就不需要再去发出请求，直接使用缓存即可；因为有了缓存，本地DNS就可以直接提供一些经常被访问的主机名所对应的IP地址，而不需要询问根DNS服务器了。需要注意的是，缓存不可避免的一个问题：有效时间。如果缓存过时而未得到更新，那么就会导致一些请求失败。

DNS记录和报文

资源记录（RR）是一个包含了下列字段的4元组（Name，Value，Type，TTL）
TTL是该记录的生存时间，它决定了资源记录应当从缓存中删除的时间。Name和Value的值取决于Type：

DNS报文有两种，即查询报文和回答报文，并且两种报文有着相同的结构：

• 前12字节为首部区域。标识符是一个用来标记该查询的16比特数。该标志符会被复制到相应的回答报文里，以便匹配请求和回答；
• 标志字段有若干标志，用来指出报文的类型（请求还是响应）、查询类型（递归还是迭代）、是否是所请求名字的权威DNS服务器、以及4个有关数量的字段，用来指示4类数据区域出现的数量；
• 问题区域包含了正在进行的查询信息，包括名字字段、查询类型；
• 回答区域包含了对最初请求的名字的资源记录，回答报文的回答区域可以包含多条RR，因此一个主机名能有多个IP地址；
• 权威区域包含了其他权威服务器的信息；
• 附加区域包含了其它有帮助的记录，比如在对于一个MX类型的请求回答报文里，回答区域里指出了邮件服务器的规范主机名，而附加区域里就有可能包含一个类型为A的关于该规范主机名的的IP地址；

向DNS数据库中插入数据

需要在注册登记机构完成这一任务，当你注册一个域名时，需要向该机构提供你的基本和辅助DNS服务器的名字和IP地址；该注册机构将确保一个类型为NS和类型为A的记录输入对应的顶级域名服务器；这样就完成了插入数据。

P2P文件分发

P2P 体系结构的扩展性

BitTorrent
BitTorrent 是一种用于文件分发的流行P2P协议；用BitTorrent的术语来说，参与一个特定文件分发的所有对等方的集合被称为一个洪流（torrent）；在一个洪流中的对等方彼此下载等长度的文件块；当一个对等方下载文件块的时候，也向其他对等方发送了多个块；一旦某对等方获得了完整文件，就可以自私地离开洪流或者大公无私地留下来继续向其他对等方发送文件。

每个洪流都有一个追踪器（tracker），当一个对等方加入某洪流时，它向追踪器注册自己，并周期性地通知追踪器它仍在该洪流中。以这种方式，追踪器跟踪参与在洪流中的对等方。

举例说明：Alice加入某洪流时，会在追踪器里进行注册，周期性通知追踪器它仍在洪流中。我们称所有与Alice成功的创建了一个TCP链接的对等方成为邻近对等方。洪流随机从参与对等方的结合中选择一个子集，将他们的IP地址发给Alice，Alice维护这张对等方列表，试图与所有对等方建立并行的TCP连接。Alice周期询问每个邻近对等方（连上的）他们有的文件块列表，她随时知道邻居有哪些文件块。

在决定请求哪些块的过程中 ， Alice 使用一种称为最稀缺优先（rarest Erst）的技术。这种技术的思路是，针对她没有的块在她的邻居中决定最稀缺的块（数量最少的块），并首先请求那些最稀缺的块。这样，最稀缺块得到更为迅速的重新分发，其目标是均衡每个块在洪流中的副本数量。

Alice优先从像她传时速度最快的邻居（4个，每10s修改一次）那里获取文件块。每过30s，Alice也要随机选择另外一个对等方Bob，向他发送块。若Alice是Bob最快的前四快，Bob也是Alice的前4快，则Bob和Alice互相发送数据。每过30s换一个新的对象，互相交换数据（一报还一报），为了使对等方能够找到彼此协调的速率上传。

P2P文件共享

两大问题：

• 如何定位所需资源
• 如何处理对等方的加入与离开

可能的方案

• 集中
• 分散
• 半分散

课后习题

R1.列出 5 种非专用的因特网应用以及它们所使用的应用层协议。

答： 网络： HTTP；文件传输： FTP；远程登录： Telnet；电子邮件： SMTP； 比特流文件共享：BitTorrent 协议

R2.网络体系结构与应用程序体系结构之间有什么区别？

答： 网络体系结构是指将通信过程组织成层（例如，五层互联网体系结构）。 另一方面，应用程序体系结构由应用程序开发人员设计，并广泛规定应用程序的结构(例如客户机-服务器或 P2P)

R3.对两进程之间的通信会话而言，哪一个是客户？哪一个是服务器？

答： 发起通信的进程是客户端；等待联系的进程是服务器。

R5.运行在一台主机上的一个进程，使用什么信息来表示运行在另一台主机上的进程？

答： 目的主机的 IP 地址和目的进程中套接字的端口号。

R6.假定你想尽快地处理从远程客户到服务器的事务，你想用 UDP 还是 TCP？为什么。

答： 你会用 UDP。 用 UDP，事务可以在一次往返时间(RTT)内完成——客户端将事务请求发送到 UDP 套接字中，服务器将回复发送回客户端的 UDP 套接字。 对于 TCP，至少需要两个 RTT-一个用于设置 TCP 连接，另一个用于客户端发送请求，以及服务器发送回应答。

R10.握手协议的作用是什么？

答： 如果两个通信实体在相互发送数据之前首先交换控制数据包，则协议使用握手。 SMTP 在应用层使用握手，而 HTTP 不使用握手。

R11.为什么 HTTP、 SMTP、 POP3 都运行在 TCP 上，而不是 UDP 上？

答： 与这些协议相关的应用程序要求以正确的顺序接收所有应用程序数据，并且不存在间隔。TCP 提供此服务，而 UDP 不提供。

R12.考虑一个电子商务网站需要保留每一个客户的购买记录，描述使用 cookie 来完成该功能

答： 当用户第一次访问该站点时，服务器创建一个唯一的标识号，在其后端数据库中创建一个条目，并将此标识号返回为 cookie 号。 此 cookie 编号存储在用户主机上，并由浏览器管理。在随后的每次访问（和购买）期间，浏览器将 cookie 号码发送回站点。 因此，站点知道这个用户（更准确地说，这个浏览器）何时访问站点。

R13.描述 WEB 缓存器是如何减少接收被请求对象的时延的， WEB 缓存器将减少一个用户请求的所有对象或只是其中的某些对象的时延吗？为什么？

答： Web 缓存可以使用户“更接近”所需的内容， 这是因为用户主机连接的同一个局域网。 Web缓存可以减少所有对象的延迟，即使是未缓存的对象，因为缓存减少了链接上的流量。【标准答案说的很模糊，个人版本： 首先， WEB 缓存器通常在局域网上，即一些离用户主机比较近的地方， 可以将 HTTP 请求的一部分返回内容下载到缓存器自身中，当有用户请求该部分内容时就可以将缓存器中的内容返回给用户而不必再去访问目的服务器，如果访问的是未缓存过的内容就向服务器请求内容，而总的来说由于收束了多个用户的请求为向服务器的一次请求， 总是能减少网络上的流量】

R18.从用户的角度来看， POP3 中下载并删除模式和下载并保留模式有什么区别吗？

答： 下载并删除模式中，用户从 POP 服务器检索其消息后，消息将被删除。 这给访客用户带
来了一个问题，他们将无法在不同的机器(办公 PC、家庭 PC 等)上访问消息。 在下载并保留模
式中，用户检索消息后不会删除消息。 这也可能不方便，因为每次用户把存储的消息转存到新
设备时，所有未删除的消息都将被转移到新设备（包括非常旧的消息）。

R21.在 BitTorrent 中，假定 Alice 向 Bob 提供一个 30 秒间隔的文件块吞吐量。 Bob 必须进行回
报，在相同的间隔中向 Alice 提供文件块吗？为什么。

答： Bob 也不需要向 Alice 提供块。 Alice 必须在 Bob 的前 4 个邻居中， Bob 才能向她发送块；
即使 Alice 在 30 秒的间隔内向 Bob 提供块，这也可能不会发生。【BitTorrent 是极其复杂的协议，
书中只说了核心思想，就是一个用户需要不断发送并可能会被随机发送数据，与自己产生流量
最高的四位则自己可以选择性向对方发送，题目中问的是 Bob 必须给 Alice 发送吗？故答案是
不一定，因为 Alice 如果不在 Bob 前 4 位顶流中则 Bob 到 Alice 这条链路是不通的】

R23.覆盖网络是什么？它包括路由器吗？在覆盖网络中边是什么？

答： P2P 文件共享系统中的覆盖网络由参与文件共享系统的节点和节点之间的逻辑链路组成。
如果 A 和 B 之间有半永久 TCP 连接，则从节点 A 到节点 B 之间有一个逻辑链路(图论术语中的
“边”)。 覆盖网络不包括路由器。

R24.CDN 通常采用两种不同的服务器放置方法，请列举并描述它们。

答： 一种服务器放置理念被称为 Enter Deep，它通过在世界各地的访问 ISP 中部署服务器集群，
深入到 ISP 的访问网络中。 目标是减少终端用户和 CDN 服务器之间的延迟和提高吞吐量。 另
一种理念是 Bring Home，它通过在较少的站点上构建大型 CDN 服务器集群，并将这些服务器
集群通常放置在 IXP(Internet Exchange Point)中。 与 Enter Deep 的设计理念相比， Bring Home
的设计通常导致较低的维护和管理成本。

R26.在 2.7 节中描述的 UDP 服务其仅需要一个套接字，而 TCP 服务器需要两个套接字。为什
么？如果 TCP 服务器支持 n 个并行链接，每条连接来自不同的客户主机，那么 TCP 服务器将
需要多少个套接字？

答： 使用 UDP 服务器，没有欢迎套接字，来自不同客户端的所有数据都通过这个套接字进入服
务器。 对于 TCP 服务器，有一个欢迎套接字，每次客户端启动到服务器的连接时，都会创建
一个新的套接字。 因此，为了支持 n 个同时连接，服务器将需要 n+1 个套接字。

R27.在 2.7 中描述的运行在 TCP 之上的客户-服务器应用程序，服务器程序为什么必须先于客户
程序运行？对于运行在 UDP 之上的客户-服务器应用程序，客户程序为什么可以先于服务器程
序运行？

答： 对于 TCP 应用程序，一旦客户端被执行，它就尝试启动与服务器的 TCP 连接。 如果 TCP
服务器没有运行，那么客户端将无法进行连接。 对于 UDP 应用程序，客户端在执行时不会立
即启动连接(或尝试与 UDP 服务器通信)。【TCP 程序一打开就开始向服务器发消息申请建立连
接，而 UDP 程序打开后可以先做本地的操作，当然如果不开服务器， UDP 程序发送的消息也
是收不到的】

P1.判断题
a.假设用户请求由一些文本和三幅图组成的 Web 页面，对于这个页面，客户将发送一个
请求报文并接收四个响应报文。

答：错误。【请求与响应必定成对】

b.两个不同的 Web 页面（如 www.mit.edu/research.html 和 www.mit.edu/students.html）可
以通过同一个持续性链接发送。

答：正确。【根路径相同，是一个主机中的不同文件】

c.在浏览器和初始服务器之间使用非持续性链接的话，一个 TCP 报文段是可能携带两个
不同的 HTTP 服务请求报文的。

答： 错误。

d.在 HTTP 响应报文中的 Date：首部指出了该响应中对象最后一次修改的时间。

答：错误。

e.HTTP 响应报文绝不会具有空的报文体。

答：错误。【HTTP 调用 TCP，必定有确认报文段，如果没有消息回复则无法捎带确认，
就会发送一个空内容的报文用于确认】

P3.考虑要获取指定 URL 的 Web 文档的 HTTP 客户，该 HTTP 服务器的 IP 地址未知。在该情况
下除了使用 HTTP 外还需要用到什么运输层和应用层协议？

答：应用层： HTTP、 DNS；运输层： TCP（为了运行 HTTP）、 UDP（为了运行 DNS）。

P8.【P115】

答： 首先第 7 题的答案是 2RTT0+RTT1+…+RTTn【因为一个 RTT 就是一个往返的时延，因此访
问 DNS 的时延是 1~n 各 1 个，接着 HTTP 采取 TCP 连接，需要在第一个 RTT 内建立连接，第
二个 RTT 内发送请求并接收应答，故有两个 RTT0】
a. 18RTT0+RTT1+…+RTTn【其他部分与第七题一样，然后客户发送一个 HTTP 请求，得
到基本 HTML 文件后，经过解析这个 HTML 文件得到 8 个图像的地址，再继续同样的 HTTP 请
求 8 次，即在第七题基础上多了 8 个图像的建立连接、请求响应，注意非持续性连接在发送响
应后， TCP 连接就立刻断开了，需要继续发送则需要重新申请建立连接】
b. 6RTT0+RTT1+…+RTTn【客户仍需先请求建立 TCP 连接、发送数据请求并接受 HTML
基本文件，消耗 2 个 RTT0，接着解析 HTML 文件后同时申请建立 5 个 TCP 连接，消耗 1 个
RTT0，请求并接收 5 个图像，消耗 1 个 RTT0，还余下 3 个 RTT0 仍需申请建立 3 个 TCP 连接、
请求并接收 3 个图像】
c. （非流水线） 10RTT0+RTT1+…+RTT【n 持续性链接即 a 省掉后续 8 次申请 TCP 的 RTT0】
（流水线） 3RTT0+RTT1+…+RTTn【这些请求可以一个接着一个地发出，而不必等待对未决条件地回答】

P9.考虑图2-12，其中有一个机构的网络和因特网相连。假定对象的平均长度为850kb，从这个机构网的浏览器外部服务器的平均请求率是每秒16个请求。还假定从接入链路的因特网一侧的路由器转发一个HTTP请求开始，到接收到其响应的平均时间是3s（参2.2.5节）。将总的平均响应时间建模为平均接入时延（即从因特网路由器到机构路由器的时延）和平均因特网时延之和。对于平均接入时延，使用Δ/（1-Δβ），式中Δ是跨越访问链路发送一个对象所需的平均时间，β是对象对该访问链路的平均到达率。a. 求出总的响应时间。b. 现在假定在这个机构的局域网中安装了缓存，假定命中率为0.4，求出总的响应时间。

a）在链路速率为R上传输⼤⼩为L的对象的时间是L/R ，平均时间是对象的平均⼤⼩除以R：

Δ = (850, 000bits)/(15, 000, 000bits/sec) = 0.0567sec

链路上的流量强度由βΔ =（16个请求/秒）* （0.0567秒/请求）=0.907表⽰。因此，平均接入延迟为（0.0567秒）/（1-0.907）≈ 0.6秒 。因此，总的平均响应时间为: 0.6秒 + 3秒 = 3.6秒

b）由于0.4 的请求在机构⽹络中得到满⾜，接⼊链路上的业务强度降低了 。因此，平均接入延迟为 （0.0567秒）/(1-0.6 * 0.907）=0.124秒。如果请求由缓存命中 (发⽣概率为0.4)，则响应时间⼤约为零；如果缓存未命中，平均响应时间为0.124秒+3秒=3.124秒(60%的时间)。因此，平均响应时间为(0.4) * (0秒)+(0.6) * (3.124秒)=1.87秒。因 此，平均响应时间从3.6秒缩短到1.87秒。

P11.【P116 另第 10 题有较复杂的情况，但不影响第 11 题解答】

a)是的，因为 Bob 有更多的连接，他可以获得更大份额的链路带宽。 b)是的， 但鲍勃仍然需要执行并行下载， 否则他将获得比其他四个用户更少的带宽。

P13.SMTP 中的 MAIL FROM 与该邮件报文自身中的“From：“之间有什么不同？

答： ①MAIL FROM——在 SMTP 中， 是来自 SMTP 客户端的消息，该消息能识别发送邮件到
SMTP 服务器的发送者身份。 ②From： ——在邮件消息本身不是 SMTP 消息，而是邮件消息正
文中的一行。

P28.在一台主机上安装编译 TCPClient 和 UDPClient 的 Python 程序，在另一台主机上安装编译
TCPServer 和 UDPServer 的程序。

a.假设在运行 TCPServer 之前运行 TCPClient，将会发生什么现象？为什么？
答： 如果首先运行 TCPClient， 那么客户端将尝试与不存在的服务器进程进行 TCP 连接。
无法进行 TCP 连接。
b.假设在运行 UDPServer 之前运行 UDPClient，将会发生什么现象？为什么？
答： UDPClient 没有与服务器建立 TCP 连接。 因此，如果首先运行 UDPClient，然后运
行 UDPServer，然后在键盘上键入一些输入，那么一切都会正常工作。
c.如果你对客户端和服务器使用了不同的端口，将会发生什么现象？
答： 如果使用不同的端口号，那么客户端将尝试与错误的进程或不存在的进程建立 TCP
连接。 将会发生错误。

P30.你能配置浏览器以打开对某 Web 站点的多个并行链接吗？有大量的并行 TCP 连接的优点
和缺点是什么？

答： 是的，可以配置许多浏览器来打开到 Web 站点的多个同时连接。 优点是可能会更快地下
载该文件。 缺点是可能会占用带宽，从而大大减缓共享相同物理链接的其他用户的下载速度。