一、应用层协议原理

1. 网络应用程序体系结构

应用程序体系结构明显不同于网络的体系结构。

• 网络体系结构是固定的，并为应用程序提供了特定的服务集合。
• 应用程序体系结构由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序。

应用程序体系结构：

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

客户-服务器体系结构

有一个总是打开的主机称为服务器，服务于来自许多其他称为客户的主机的请求。

特征：

• 客户之间不直接通信。
• 服务器具有固定的、周知的 IP 地址。
  • 客户总是能够通过向该服务器的 IP 地址发送分组来与其联系。

该结构的典型应用：

• Web
• FTP
• Telnet
• 电子邮件

在客户-服务器应用中，常常会出现一台单独的服务器主机处理不过来他所有客户请求的情况。常需要配备大量主机的数据中心来创建强大的虚拟服务器。

P2P 体系结构

特征：

• 对位于数据中心的专用服务器有最小的依赖。
• 应用程序在间断连接的主机对之间使用直接通信。
  • 这些 主机对 称为 对等方
• 自扩展性
  • 每个对等方都由于请求产生工作负载。
  • 每个对等方也通过向其他对等方分发文件，从而为系统增加服务能力。

给结构的典型应用：

• 文件共享
• 对等方协助下载加速器
• 因特网电话
• 视频会议

未来 P2P 应用由于高度非集中式结构，面临安全性，性能和可靠性等挑战。

混合体系结构

如即时讯息应用。

• 服务器用于跟踪用户的 IP 地址。
• 用户到用户的报文在用户主机之间直接发送。

2. 进程通信

进行通信的实际上是 进程 而不是程序。
一个进程可以被认为是运行在端系统中的一个程序。

相同端系统的进程之间的通信：

• 使用进程间通信机制相互通信。进程间通信的规则由端系统上的操作系统确定。

不同端系统（可能具有不同的操作系统）上的进程之间的通信：

• 通过跨越计算机网络交换报文（message） 相互通信。

2.1 客户和服务器进程

网络应用程序由成对的进程组成。
⭐ 在一对进程之间的通信会话场景中，

• 发起通信（即在该会话开始时发起与其他进程的联系）的进程被标识为客户。
• 在会话开始时等待联系的进程是服务器。

对于 Web 而言：浏览器是一个客户进程，Web 服务器是一台服务器进程。
对于 P2P 文件共享：下载文件的对等方标识为客户，上传文件的对等方标识为服务器。

• 一个进程能够既是客户又是服务器。

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

进程通过称为 套接字（socket） 的软件接口向网络发送报文和从网络接收报文。
套接字是同一台主机内的应用层和运输层之间的接口。
是应用程序和网络之间的应用程序编程接口（API, Application Programming Interface）。

• 应用程序开发者可以控制套接字在应用层端的一切。
• 但是对该套接字的运输层端几乎没有控制权。对运输层的控制权仅限于：
  1. 选择运输层协议
  2. 也许能设定几个运输层参数，如最大缓存和最大报文段长度。

2.3 进程寻址

接收进程需要有一个地址。标识接收进程需要定义两种信息：

• 主机的地址，由 IP 地址 标识。
  • IP 地址是一个 32 bit 的量且能够唯一地标识该主机。
• 在目的主机中指定接收进程（套接字）的标识符。由目的地 端口号 标识。
  • Web 服务器用端口号 80 来标识。
  • 邮件服务器进程（SMTP 协议） 用端口号 25 来标识。

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

运输层协议为应用程序提供的服务：

3.1 可靠数据传输

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

• 分组使路由器中的缓存溢出。
• 分组中的某些比特损坏后可能被丢弃。

可靠数据传输：如果协议提供了确保数据正确、完全地交付的服务，则认为提供了可靠数据传输。

• 运输层协议潜在地向应用程序提供的一个重要服务是 进程到进程的可靠数据传输。

容忍丢失的应用：如多媒体应用。

• 丢失的数据引起播放的音频/视频出现小干扰，而不是致命的损伤。

3.2 吞吐量

在沿着一条网络路径上的两个进程之间的通信会话场景中，
可用吞吐量：发送进程能够向接收进程交付比特的速率。

• 因为其他会话将共享沿着该网络路径的带宽，因此可用吞吐量会随时间波动。
• 运输层协议能够以某种特定的速率提供确保的可用吞吐量。

①带宽敏感的应用：具有吞吐量要求的应用程序。

• 如多媒体应用。
• 某些多媒体应用可能采用自适应编码技术对 数字语音或视频 以与 当前可用带宽 相匹配的速率 进行编码。

②弹性应用：不具有吞吐量要求，根据当时可用的带宽或多或少地利用可供使用的吞吐量。

• 如 电子邮件、文件传输 以及 Web 传送

3.3 定时

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

• 如发送方注入套接字中的每个比特 到达 接收方的套接字 不迟于 100 ms。

这种服务对 交互式实时应用程序 有吸引力。

• 如因特网电话、虚拟环境、电话会议和多方游戏。

3.4 安全性

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

• 机密性
  • 发送主机中，运输协议能够加密由发送进程传输的所有数据。
  • 接收主机中，运输层协议能够在将数据交付给接收进程之前解密这些数据。
• 数据完整性
• 端点鉴别

4. 因特网提供的运输服务

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

每个协议为调用它们的应用程序提供了不同的服务集合。

4.1 TCP 服务

• 面向连接服务

  • 在应用层数据报文开始流动之前， TCP 让客户和服务器互相交换运输层控制信息（握手）。
  • 在握手阶段后，一个 TCP 连接就在两个进程的套接字之间建立了。
  • 连接为 全双工 的。连接双方的进程可以在此连接上同时进行报文收发。
  • 应用程序结束报文发送时，必须拆除该连接。

• 可靠数据传输服务

  • 通信进程能够依靠 TCP，无差错、无丢失、无冗余、按适当顺序 交付所发送的数据。

• 拥塞控制

  • 当发送方与接收方之间的网络出现拥塞时，TCP 的拥塞控制机制会抑制发送进程（客户或服务器）。
  • TCP拥塞控制试图限制每个 TCP 连接，使他们达到公平共享网络带宽的目的。

使用 TCP 协议的因特网应用：

• 电子邮件
• 远程终端访问
• Web
• 文件传输

TCP 安全

TCP 和 UDP 都没有提供任何加密机制。

• 发送进程传进其套接字的数据，与经网络传送到目的进程的数据相同。
• 明文发送的数据可能在任何中间链路被嗅探和发现。

安全套接字层（Secure Sockets Layer, SSL）：TCP 的加强版本。

• SSL 加强后的 TCP 能够做传统 TCP 所能做的一切，并提供了关键的进程到进程的安全性服务。
• 包括 加密、数据完整性和端点鉴别 。

SSL 是在应用层上实现的。

• 不是与 TCP 和 UDP 在相同层次上的第三种因特网运输协议，而是一种对 TCP 的加强。
• 如果一个应用程序要使用 SSL 的服务，需要在该应用程序的客户端和服务器端包括 SSL 代码（利用现有的、高度优化的库和类）。

SSL 有自己的套接字 API。

1. 应用使用 SSL 时，发送进程首先向 SSL 套接字 传递明文数据 。
2. 发送主机中的 SSL 则加密该数据并传递给 TCP 套接字。
3. 加密的数据经因特网传送到接收进程中的 TCP 套接字
4. TCP 套接字将加密数据传递给 SSL，由其进行解密。
5. SSL 通过 SSL 套接字将明文数据传递给接收进程。

4.2 UDP 服务

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

• 无连接
  • 两个进程在通信前没有握手过程。
• 提供不可靠传输服务
  • 报文发送进 UDP 套接字，UDP 协议并不保证该报文将到达接收进程。
  • 到达接收进程的报文也可能是乱序的。

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

• 端到端吞吐量可能小于该速率，可能是因为中间链路的带宽受限 / 拥塞 造成的。

使用 UDP 协议的应用：

• 因特网电话应用
  • 避开 TCP 的拥塞控制机制 和 分组开销。
  • 许多防火墙被配置为阻挡 UDP 流量，因此因特网电话应用通常设计成如果 UDP 通信失败就使用 TCP 作为备份。

① 使用 UDP，事务可以在一次往返时间（RTT）内完成，

• 客户端将事务请求发送到 UDP 套接字，服务器将应答发送回客户端的 UDP 套接字。

② 对于 TCP，至少需要两个 RTT。

• 一个用于设置 TCP 连接
• 一个用于客户发送请求，和服务器发送回复

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

目前的因特网运输协议并没有提供对 吞吐量 或 定时 的保证服务。
不过今天的因特网通常能够为事件敏感应用提供满意的服务。

5. 应用层协议

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

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

① 由 RFC 文档定义的应用层协议，位于公共域中。如 HTTP 超文本传输协议。
② 专用的应用层协议，不为公共域使用。如 Skype 使用了专用的应用层协议。

应用层协议只是网络应用的一部分。
如 Web 是一种 客户-服务器应用，它允许客户按照需求从 Web 服务器获得文档。组成部分有：

• 文档格式的标准（HTML）
• Web 浏览器
• Web 服务器
• 应用层协议 HTTP。定义了在浏览器和 Web 服务器之间传输的报文格式和序列。

如因特网电子邮件应用的组成部分有

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

5种重要的应用层应用：

• Web（HTTP）
• 文件传输
• 电子邮件
  • 使用了多个应用层协议。
• 目录服务
  • DNS 为因特网提供目录服务。是核心的网络功能（网络名字到网络地址的转换）
  • 大多数用户是通过其他的应用间接使用它。
• 流式视频和 P2P

二、Web 和 HTTP

1. HTTP 概况

HTTP（HyperText Transfer Protocol） 超文本传输协议
由 客户程序 和 服务器程序 实现。

• Web 使用 客户-服务器 应用程序体系结构，Web 服务器总是打开的，具有一个固定的 IP 地址。

两个程序运行在不同的端系统中，通过 交换 HTTP 报文 进行会话。

HTTP 定义了这些 报文的结构 以及 客户和服务器进行报文交换的方式。

① Web 页面（文档） 含有一个 HTML 基本文件 以及 几个引用对象。

• HTML 基本文件通过对象的 URL 地址引用页面中的其他对象。

② 对象 是一个文件，且可通过一个 URL 地址寻址。
③ URL 地址 由 存放对象的服务器主机名 和 对象的路径名组成。
④ Web 浏览器 实现了 HTTP 的客户端。
⑤ Web 服务器 实现了 HTTP 的服务器端，用于存储 Web 对象。

HTTP 使用 TCP 作为它的支撑运输协议。TCP 提供可靠数据传输服务。

• HTTP 协议不用担心数据丢失
• 也不关注 TCP 从网络的数据丢失和乱序故障中恢复的细节。

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

2. 非持续连接和持续连续

非持续连接：每个 请求 / 响应对是经一个单独的 TCP 连接发送。
持续连接：所有的请求及其响应经相同的 TCP 连接发送。

HTTP 既能够使用非持续连接，也能够使用持续连接。

• 默认情况下使用持续连接。

2.1 采用非持续连接的 HTTP

• HTTP 客户进程在端口号 80 发起一个到服务器的 TCP 连接。
• HTTP 客户经它的套接字向该服务器发送一个 HTTP 请求报文。
• HTTP 服务器进程经它的套接字接收请求报文，从其存储盘中检索出对象，在一个 HTTP 响应报文中封装对象，并通过其套接字向客户发送响应报文。
• HTTP 服务器进程通知 TCP 断开该 TCP 连接。
  • 直到 TCP 确认客户已经完整地收到响应报文为止，它才会实际中断连接。
• HTTP 客户接收响应报文， TCP 连接关闭。

浏览器收到 Web 页面后，向用户显示。HTTP 与客户如何解释一个 Web 页面毫无关系。

每个TCP 连接只传输一个请求报文和一个响应报文。

用户能够配置现代浏览器来控制连接的并行度。

• 默认方式下，大部分浏览器打开 5 ~ 10个并行的 TCP 连接，每条连接处理一个请求响应事务。
• 最大并行连接数设置为 1，这样连接就会串行建立。
• 使用并行连接可以缩短响应时间。

往返时间（Round-Trip Time, RTT）：该时间是指一个短分组从客户到服务器然后再返回客户所花费的时间。包括

• 分组传播时延
• 分组在中间路由器和交换机上的排队时延
• 分组处理时延。

三次握手：

• 客户向服务器发送一个小 TCP 报文段。
• 服务器用一个小 TCP 报文段做出确认和响应。
• 客户向服务器返回确认。

三次握手的前两个部分耗费的时间占用一个 RTT。

客户结合三次握手的第三部分（确认）向该 TCP 连接发送一个 HTTP 请求报文。服务器接收到请求报文，在该 TCP 连接上发送 HTML 文件。

该 HTTP 请求/响应用去了另一个 RTT。

因此粗略地讲，总的响应时间就是 两个 RTT 加上服务器传输 HTML 文件 的时间。

非持续连接的缺点：

1. 必须为每一个请求的对象建立和维护一个全新的连接。
   • 对于每个连接，在客户和服务器中都要 分配 TCP 缓冲区 和 保持 TCP 变量。给服务器带来了严重的负担。
2. 每一个对象经受 2 倍 RTT 的交付时延。
   • 一个 RTT 用于创建 TCP，一个用于请求和接收一个对象。

2.2 采用持续连接的 HTTP

在采用 HTTP 1.1 持续连接的情况下，服务器在发送响应后保持该 TCP 连接打开。
对对象的请求可以一个接一个地发出，而不必对待对未决请求的回答。

一般来说，如果一条连接经过一定时间间隔（一个可配置的超时间隔）仍未被使用，HTTP 服务器就关闭该连接。

HTTP 的默认模式是使用带流水线的持续连接。

HTTP/2 在 HTTP 1.1 基础上构建，

• 允许在相同连接中多个请求和回答交错。
• 并增加了在该连接中优化 HTTP 报文请求和回答的机制。

3. HTTP 报文格式

HTTP 报文有两种： 请求报文 和 响应报文。

3.1 HTTP 请求报文

• 请求行：HTTP 请求报文的第一行
  • 方法字段。可以取 GET、POST、HEAD、PUT 和 DELETE
  • URL 字段。
  • HTTP 版本字段。
• 首部行（请求头）：后续行。提供的信息是 Web 代理高速缓存所要求的。
  • Host 指明对象所在的主机
  • Connection：close 浏览器告诉服务器不使用持续连接。在发送完请求的对象后就关闭这条连接。
  • User-agent 指明用户代理。即向服务器发送请求的浏览器的类型。
    • 服务器可以为不同类型的用户代理实际发送相同对象的不同版本。
  • Accept-language 用户希望得到对象的语言版本。
    • 如果没有这样的对象，服务器应当发送它的默认版本。
• 实体体（请求体）：在首部行（和附加的回车和换行）后。
  • 使用 GET 方法时，请求体为空。在 URL 中包含输入的数据。
  • 使用 POST 方法才使用该请求体。

HEAD 方法：类似于 GET 方法。

• 服务器收到一个使用 HEAD 方法的请求时，将会用一个 HTTP 报文进行响应，但是并不返回请求对象。
• 常用于调试跟踪。

PUT 方法：允许用户 / 应用程序 上传对象到指定的 Web 服务器上的指定路径。

DELETE 方法：允许用户 / 应用程序 删除 Web 服务器上的对象。

3.2 HTTP 响应报文

• 初始状态行：
  • 协议版本字段
  • 状态码
  • 响应状态信息
• 首部行：
  • Connection：close 服务器告诉客户，发送完报文后将关闭该 TCP 连接。
  • Date：指示服务器产生并发送该响应报文的日期和时间。
  • Server： 指示是产生的报文的服务器类型。类似于请求报文中的 User-agent
  • Last-Modified：指示了对象创建或最后修改的日期和时间。
  • Content-Length：被发送对象中的字节数。
  • Content-Type：响应体中的对象的类型。
• 响应体：包含了请求的对象本身。

常见的状态码：

• 200 OK：请求成功
• 301 Moved Permanently： 请求的对象已经被永久转移了。
  • 新的 URL 定义在响应报文的 Location 首部 中
  • 客户将自动获取新的 URL。
• 400 Bad Request： 通用差错代码，指示该请求不能被服务器理解。
• 404 Not Found：被请求的文档不在服务器上。
• 505 HTTP Version Not Supported：服务器不支持请求报文所使用的 HTTP 协议版本。

如果只想获取 HTTP 协议的报文行，而不是获取对象本身。那么可以用 HEAD 代替 GET。

浏览器产生的请求头与很多因素有关：

• 浏览器的类型和协议版本。
  • HTTP/1.0 浏览器将不会产生任何 1.1 版本的首部行
• 浏览器的用户配置。 如喜好语言。
• 浏览器当前是否有一个缓存的但是可能过期的对象版本。

响应报文中的响应头的影响因素：产品、版本和配置。

4. 用户与服务器的交互：cookie

HTTP 使用 cookie 用于将内容与用户身份联系起来。
cookie 可以用于标识一个用户。

cookie 技术的 4 个组件：

• HTTP 响应报文中的一个 cookie 头部
• HTTP 请求报文中的一个 cookie 头部
• 用户端系统中保留有一个 cookie 文件，由用户的浏览器进行管理。
• 位于 Web 站点的一个后端数据库

cookie 的工作过程

用户首次登录网站，Web 站点将产生一个唯一识别码，以此为索引在后端数据库中产生一个表项。

服务器用一个包含 Set-cookie 头部 的响应报文对浏览器进行响应。
在 Set-cookie 头部中含有唯一识别码。

浏览器收到 HTTP 响应报文时，根据 Set-cookie 头部，在它管理的特定 cookie 文件中添加一行，该行包含服务器的主机名和 Set-cookie 头部中的识别码。

用户后续请求该网站的 Web 服务器，浏览器都会查询 cookie 文件并选取用户对这个网站的 cookie，并放到 HTTP 请求报文的 cookie 头部中。

cookie 可以在无状态的 HTTP 之上建立一个用户会话层。
允许服务器在用户与应用程序会话的过程中标识该用户。

5. Web 缓存

Web 缓存器，也叫代理服务器。
是能够代表初始 Web 服务器来满足 HTTP 请求的网络实体。

Web 缓存器有自己的磁盘存储空间，在其中保存最近请求过的对象的副本。
使得用户的所有 HTTP 请求首先指向 Web 缓存器。

• 浏览器创建一个到 Web 缓存器的 TCP 连接，并向 Web 缓存器中的对象发送一个 HTTP 请求。
• Web 缓存器进行检查，看看本地是否存储了该对象副本。
  • 如有，则向客户浏览器用 HTTP 响应报文返回该对象。
  • 没有，则打开一个与该对象的初始服务器的 TCP 连接。发送一个对该对象的 HTTP 请求。
  • 收到请求后，初始服务器向该 Web 缓存器发送具有该对象的 HTTP 响应。
  • Web 缓存器接收到该对象时，在本地存储空间存储一份副本。
• Web 缓存器 向 客户的浏览器 用 HTTP 响应报文发送该副本（通过现有的客户浏览器和 Web 缓存器之间的 TCP 连接）。
  • Web 缓存器既是服务器又是客户。

Web 缓存器通常由 ISP 购买并安装。

在因特网上部署Web 缓存器的两个原因：

1. Web 缓存器可以大大减少对客户请求的响应时间。
2. Web 缓存器能够大大减少一个机构的接入链路到因特网的通信量。

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

Web 缓存器使用 内容分发网络（Content Distribution Network, CDN） 发挥越来越重要的作用。

6. 条件 GET 方法

高速缓存能减少用户感受到的响应时间，新的问题是 存放在缓存器中的对象副本可能是陈旧的。 保存在服务器中的对象自该副本缓存在客户上以后可能已经被修改了。

条件 GET 方法：HTTP 协议 允许缓存器证实它的对象是最新的 一种机制。

• 请求报文使用 GET 方法。
• 请求报文中包含一个 If-Modified-Since 首部行。

缓存器在将对象转发到请求的浏览器的同时，也在本地缓存了该对象，以及对象的最后修改日期（Last-Modified）。

If-Modified-Since 首部行的值正好等于之前服务器发送响应报文中的 Last-Modified。

条件 GET 报文 告诉服务器，仅当自指定日期之后该对象被修改过，才发送该对象。

如果对象没有被修改过，服务器会向缓存器发送一个响应报文：

• 在该报文中不包含所请求的对象。
• 状态行中为 304 Not Modified，告诉缓存器可以使用该对象，能向请求的浏览器转发缓存的该对象副本。
  

三、 因特网中的电子邮件

因特网电子邮件系统的三个组成部分：

• 用户代理 user agent
• 邮件服务器 mai server
• 简单邮件传输协议（Simple Mail Transfer Protocol，SMTP）

用户在用户代理上阅读、恢复、转发、保存和撰写报文。

发送方的邮件代理向邮件服务器发送邮件，此时邮件放在邮件服务器的外出报文队列中。

• 如果收件方邮件服务器存在故障，发送方将无法交付邮件。
• 发送方的邮件服务器在一个 报文队列 中保持该报文并在以后尝试再次发送。
• 如果几天后仍不能成功，服务器就删除该报文并以电子邮件的形式通知发送方。

当收件方要阅读报文时，他的用户代理在其邮件服务器的邮箱中取得该报文。

SMTP 是因特网电子邮件中的主要的应用层协议。
它使用 TCP 可靠数据传输服务。
从发送方的 邮件服务器 向接收方的 邮件服务器 发送邮件。

SMTP 的两个组成部分：

• 运行在发送方邮件服务器的客户端
• 运行在接收方邮件服务器的服务器端

每台邮件服务器上既运行 SMTP 的客户端也允许 SMTP 的服务器端。

3.1 SMTP

SMTP 限制所有邮件报文的体部分（不只是其首部）只能采用简单的 7 比特 ASCII 表示。

• 需要将二进制多媒体数据编码为 ASCII 码
• 并且在使用 SMTP 传输后要求将相应的 ASCII 码邮件解码还原为多媒体数据

SMTP 的基本操作：

• 发送方调用他的邮件代理程序并提供收件方的邮件地址，撰写报文，然后指示用户代理发送该报文。
• 发送方的用户代理将报文发送到自己的邮件服务器。在那里该报文被放在报文队列中。
• 运行在发送方邮件服务器上的 SMTP 客户端 发现了报文队列中的这个报文，就在 25 号端口 创建一个到运行在收件方邮件服务器上的 SMTP 服务器的 TCP 连接。
• 经过一些 初始 SMTP 握手后，SMTP 客户通过该 TCP 连接发送报文。
  • 在握手阶段， SMTP 客户指示 发送方的邮件地址 和 接收方的邮件地址。
  • 如果客户有另外的报文要发送到该服务器，就在该相同的 TCP 连接上重复这种操作。否则，指示 TCP 关闭连接。
• 在接收方的邮件服务器上， SMTP 的服务器端 接收该报文。邮件服务器将该报文放入 接收方的邮箱。

SMTP 一般不使用 中间邮件服务器 发送邮件。

• 如果收件方的邮件服务器没有开机，则该报文会保留在 发送方的邮件服务器上并等待新的尝试。

SMTP 命令：用于 SMTP 握手。

• HELO
• MAIL FROM
• RCPT TO
• DATA
• QUIT

每个报文以 CRLF.CRLF 结束。

SMTP 用的是持续连接。 如果发送邮件服务器 有几个报文发往同一个接收服务器，它可以通过同一个 TCP 连接发送这些所有的报文。

• 对每个报文，客户用一个新的 MAIL FROM： 开始
• 用一个独立的句点指示该邮件的结束
• 当且仅当所有邮件发送完后才发送 QUIT

3.2 与 HTTP 的对比

共同点：

• 两个协议都用于从一台主机向另一台主机传送文件。
• 持续的 HTTP 和 SMTP 都使用持续连接。

重要的区别：

• HTTP 主要是一个 拉协议，SMTP 主要是一个 推协议
  • 用户使用 HTTP 从该服务器拉取这些信息。TCP 连接是由想接收文件的机器发起的。
  • 发送邮件服务器把文件推向接收邮件服务器。TCP 连接由要发送该文件的机器发起。
• SMTP 要求每个报文采用 7 比特 ASCII 码格式。HTTP 数据则不受这种限制。
• 如何处理一个既包含文本又包含图形（或其他媒体类型）的文档。
  • SMTP 把所有报文对象放在一个报文之中。
  • HTTP 把每个对象封装到它自己的 HTTP 响应报文中。

3.3 邮件报文格式

• 报文首部
  • 每个首部必须含有一个 From 头部 和一个 To 头部
  • 可能含有一个 Subject 头部以及其他可选的头部
• 在报文首部之后，紧接着一个空白行
• 报文体：以 ASCII 格式表示

这些头部不同于 SMTP 命令。

• 那些命令是 SMTP 握手协议的一部分
• 这些头部则是邮件报文自身的一部分。

3.4 邮件访问协议

今天，邮件访问使用了一种 客户-服务器 体系结构。
SMTP 被设计成将电子邮件从一台主机推到另一台主机。

通常 发件方的用户代理 与 收件方的邮件服务器之间并没有一个直接的 SMTP 对话。

• 发件方 的用户代理 用 SMTP 将电子邮件报文推入她的邮件服务器。
• 邮件服务器再用 SMTP 将邮件中继到收件方的邮件服务器。

收件方的用户代理不能使用 SMTP 得到报文。 因为取报文是一个拉操作。

可以通过引入一个特殊的 邮件访问协议 来解决。该协议将 收件方的邮件服务器上的报文 传送给他的 本地 PC。

流行的邮件访问协议：

• POP3 第三版的邮局协议（Post Office Protocol-Version 3）
• IMAP 因特网邮件访问协议（Internet Mail Access Protocol）
• HTTP

①SMTP 用来将邮件从发送方的邮件服务器传输到 接收方的邮件服务器。或将邮件从发送方的 用户代理 传输到 发送方的邮件服务器。

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

1. POP3

POP3 是一个极为简单的邮件访问协议。

当用户代理打开了一个到邮件服务器端口 110 上的 TCP 连接后， POP3就开始工作了。

POP3 按照三个阶段进行工作：

1. 特许 authorization
   • 用户代理发送（明文形式的）用户名和口令以鉴别用户。
   • 两个主要命令
     • user <user name>
     • pass <password>
2. 事务处理
   • 用户代理取回报文
     • 先请求邮件服务器列出所有存储的报文的长度。
     • 接着用户代理从服务器取回（并删除）每封邮件。
   • 用户代理还可对报文做删除标记，取消报文删除标记，以及获取邮件的统计信息。
   • 在该过程中，用户代理发出命令，服务器会对每个命令做出回答。
     • +OK 命令正常
     • -ERR 只是前面的命令出现了某些差错
   • 用户代理通常被用户配置为 【下载并删除】 或 【下载并保留】 方式
3. 更新
   • 出现在客户发出 quit 命令 之后，目的是结束该 POP3 会话。
   • 此时邮件服务器删除那些被标记为删除的报文。

在特许阶段以后，用户代理仅使用四个命令 list、retr、dele、quit。

在用户代理与邮件服务器之间的 POP3 会话期间，POP3 服务器保留了一些状态信息。特别是记录了哪些用户报文被标记为删除了。

POP3服务器 并不在 POP3 会话过程中携带状态信息。

• POP3 访问的报文与文件夹存放在本地主机上。
• 没有给用户提供任何创建远程文件夹并为报文指派文件夹的方法。

2. IMAP

IMAP 是一个邮件访问协议，比 POP3 有更多的特色，也更复杂。

• 将每个报文与一个文件夹联系起来。
  • 报文第一次到达服务器时，与收件人的 INBOX 文件夹相关联。
  • 收件人能够移动文件至新的、用户创建的文件夹。
• 提供了用户在远程文件夹中查询邮件的命令，按指定条件查询匹配的命令。
• IMAP 服务器维护了 IMAP 会话的用户状态信息。
  • 如文件夹的名字 以及 那些报文与哪些文件夹相关联。
• 具有允许用户代理获取报文某些部分的命令。
  • 一个用户代理可以只读取一个报文的首部
  • 或一个多部分 MIME 报文的一部分。

3. 基于 Web 的电子邮件

用户代理是普通浏览器。

用户和他远程邮箱之间的通信由 HTTP 进行。

• 收件人使用 HTTP 协议 从邮件服务器获取报文到浏览器。
• 发件人使用 HTTP 协议 从浏览器发送报文至邮件服务器。
• 发件人的邮件服务器 在与其他的邮件服务器之间发送和接收邮件时，仍然使用 SMTP 协议。

四、DNS: 因特网的目录服务

主机的标识方法：

• 主机名 hostname
  • 没有提供主机在因特网中的位置信息。
  • 主机名可能由不定长的字母数字组成，路由器难以处理。
• IP 地址
  • IP 地址由 4 个 字节组成。由句点隔开，每个字节表示 0 ~ 255 的十进制数字。
  • IP 地址具有层次结构，从左往右，可以得到越来越具体的关于主机在互联网中的位置信息

4.1 DNS 提供的服务

用户一般记忆主机名，而路由器喜欢定长的，有层次结构的 IP 地址。

域名系统（Domain Name System，DNS）：能进行主机名到 IP 地址转换的目录服务。

• 一个由分层的 DNS 服务器 实现的分布式数据库。
• 一个使得主机能够查询分布式数据库的应用层协议。

DNS 协议运行在 UDP 之上，使用 53 号端口。

DNS 协议是应用层协议：

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

DNS 不同于 Web 应用、文件传输应用以及电子邮件应用：

• DNS 不是直接和用户打交道的应用
• DNS 为因特网上的用户应用程序以及其他软件提供一种核心功能，采用了位于 网络边缘 的客户和服务器，将主机名转换为其背后的 IP 地址。

DNS 通常是由其他应用层协议所使用，包括 HTTP、SMTP 和 FTP。

用户请求 URL 页面时的流程：

• 同一台用户主机上运行着 DNS 应用的客户端。
• 浏览器从上述 URL 中抽取出主机名，并将主机名传给 DNS 应用的客户端。
• DNS 客户向 DNS 服务器 发送一个包含主机名的请求。
• DNS 客户最终会收到一份回答报文，其中含有对应于该主机名的 IP 地址。
• 一旦浏览器接收到了来自 DNS 的该 IP 地址，它能够向位于该 IP 地址 80 端口的 HTTP 服务器进程发起一个 TCP 连接。

DNS 给使用它的因特网应用带来了额外的时延。

• 想获得的 IP 地址通常就缓存在一个“附近的”DNS 服务器中，这有助于减少 DNS 的网络流量 和 DNS 的平均时延。

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

1. 主机别名：有着复杂主机名的主机能拥有一个或多个别名。
   • 主机别名一般比 规范主机名 更容易记忆。
   • 应用程序可以调用 DNS 来获得主机别名对应的规范主机名以及主机的 IP 地址。
2. 邮件服务器别名：邮件服务器的规范主机名一般比 @后的主机名别名（如@yahoo.com）复杂。
   • 电子邮件应用程序可以调用 DNS， 对提供的主机名别名进行解析，以获得该主机的规范主机名及其 IP 地址。
   • MX 记录允许一个公司的邮件服务器与 Web 服务器使用相同的主机名。
3. 负载分配： DNS 也用于在冗余的服务器之间进行负载分配。繁忙的站点被冗余分布在多台服务器上，每台服务器均运行在不同的端系统上，有着不同的 IP 地址。
   • 一个规范主机名 会与 一个 IP 地址集合 相联系。DNS 数据库中存储着这些 IP 地址集合。
   • 服务器会使用 IP 地址的整个集合 进行响应 DNS 请求。
   • 但在每个回答中 循环这些地址次序。因为客户通常总是向 IP 地址排在最前面的服务器发送 HTTP 请求报文。

4.2 DNS 工作机理概述

所有 DNS 请求和 回答报文使用 UDP 数据经端口 53 发送。

DNS 由分布于全球的大量 DNS 服务器以及定义了 DNS 服务器与查询主机通信方式的应用层协议组成。

集中式 DNS 设计的问题：在因特网上只使用一个 DNS 服务器

• 单点故障：DNS 服务器崩溃，因特网将瘫痪。
• 通信容量：单个 DNS 服务器要处理所有的 DNS 查询。
• 远距离的集中式数据库：会导致严重的时延。
• 维护：单个 DNS 服务器为所有的因特网主机保留记录。会使中央数据库庞大。而且还必须为解决每个新添加的主机而频繁更新。

总的来说，单一 DNS 服务器上运行集中式数据库 完全没有可扩展能力。
因此 DNS 采用了 分布式 的设计方案。

1. 分布式、层次数据库

大量的 DNS 服务器以层次方式组织。没有一台 DNS 服务器拥有因特网上所有主机的映射。

有 3 种类型的 DNS 服务器：

• 根 DNS 服务器：提供 TLD 服务器的 IP 地址。
• 顶级域（Top-Level Domain，TLD）DNS 服务器：提供权威 DNS 服务器的 IP 地址。
  • 每个顶级域（com、org、net、edu和 gov） 和所有国家的顶级域都有 TLD 服务器（或服务器集群）。
• 权威 DNS 服务器：
  • 在因特网上具有公共可访问主机的每个组织机构必须提供公共可访问的 DNS 记录。
  • 一个组织机构能够选择实现自己的权威 DNS 服务器以保存这些记录。
  • 或支付费用，让记录存储在某个服务提供商的一个权威 DNS 服务器中。
• 本地 DNS 服务器：
  • 本地服务器并不属于该服务器的层次结构，但至关重要。
  • 本地 DNS 服务器起着代理的作用，并将请求转发到 DNS 服务器层次结构中。
  • 每个 ISP 都有一台本地 DNS 服务器。（默认名字服务器）
  • 当主机与某个 ISP 连接时，该 ISP 提供一台主机的 IP 地址，该主机具有一台或多台其本地 DNS 服务器的 IP 地址。（通常通过 DHCP）
  • 本地 DNS 服务器通常与 主机 相隔不超过几台路由器。

假定一个 DNS 客户要主机名 www.amazon.com 的 IP 地址。

1. 客户首先与 根服务器 之一联系，它将返回顶级域名 com 的 TLD 服务器的 IP 地址。
2. 客户与这些 TLD 服务器 之一联系，将返回 amazon.com 的 权威服务器的 IP 地址。
3. 客户与 amazon.com 权威服务器 之一联系，返回主机名 www.amazon.com 的 IP 地址。

主机 cse.nyu.edu 想知道主机 gaia.cs.umass.adu 的 IP 地址。

• 主机 cse.nyu.adu 首先向它的本地 DNS 服务器 dns.nyu.edu 发送一个 DNS 查询报文。
• 本地 DNS 服务器将该报文转发到根 DNS 服务器。
• 该根 DNS 服务器注意到其 edu 前缀并向本地 DNS 服务器 返回 负责 edu 的 TLD 的 IP 地址列表。
• 本地 DNS 服务器再次向这些 TLD 服务器之一发送查询报文。
• TLD 服务器注意到 umass.edu 前缀，并用权威 DNS 服务器的 IP 地址进行响应。
• 本地DNS 服务器直接向 dns.umass.adu 重发查询报文，权威 DNS 服务器用 gaia.cs.umass.adu 的 IP 地址进行响应。

TLD 服务器并不总是知道主机的 权威 DNS 服务器的 IP 地址。

• 可能只是知道中间的某个 DNS 服务器，通过该服务器依次才能知道权威 DNS 服务器。

DNS 查询方式：

• 递归查询
  • 从 cse.nyu.edu 到 dns.nyu.edu 发出的查询是递归查询。
• 迭代查询
  • 后续查询都是迭代查询，因为所有的回答都是直接返回给 dns.nyu.edu。

任何 DNS 查询既可以是迭代的也能是递归的。
实践中，从请求主机到 DNS 服务器的查询是递归的，其余的查询是迭代的。

2. DNS 缓存

DNS 广泛使用了缓存技术。

• 改善时延性能。
• 减少在因特网上到处传输的 DNS 报文数量。

DNS 缓存原理：

• 在一个请求链中，当某 DNS 服务器接收一个 DNS 回答，包含某主机名到 IP 地址的映射。它能将映射缓存在本地存储器中。
• 如果在 DNS 服务器中缓存了一台 主机名/IP地址对，另一个对相同主机名的查询到达该 DNS 服务器时，该 DNS 服务器就能够提供所要求的 IP 地址，即使它不是该主机名的权威服务器。

主机和主机名与 IP 地址之间的映射并不是永久的。

• DNS 服务器在一段时间后将丢弃缓存的信息。

本地 DNS 服务器也能够缓存 TLD 服务器的 IP 地址

• 因而允许本地 DNS 绕过查询链中的 根 DNS 服务器。
• 除了少数 DNS 查询以外，根服务器都被绕过了。

4.3 DNS 记录和报文

资源记录（Resource Record, RR）：提供主机名到 IP 地址的映射。

共同实现 DNS 分布式数据库的所有 DNS 服务器存储了资源记录。

每个 DNS 回答报文包含了一条或多条资源记录。

资源记录是一个包含 （Name，Value，Type，TTL） 字段的 4 元组。

• TTL：该记录的生存时间。决定了资源记录应当从缓存中删除的时间。
• Name 和 Value 的值取决于 Type ：
  • Type = A。
    • Name 为主机名。
    • Value 是主机名对应的 IP 地址。
    • 类型为 A 的资源记录提供了标准的 主机名到 IP 地址的映射。
  • Type = NS。
    • Name 是个域（如 foo.com）
    • Value 是个知道如何获得该域中主机 IP 地址的 权威 DNS 服务器的主机名。
  • Type = CNAME
    • Value 是 别名为 Name 的主机对应的规范主机名。
    • 该记录能够向查询的主机提供一个主机名对应的规范主机名。
    • 如（foo.com, relay1.bar.foo.com, CNAME）
  • Type = MX
    • Value 是 别名为 Name 的邮件服务器对应的规范主机名。
    • 如 （foo.com, mail.bar.foo.com, MX）。
    • 使用 MX 记录，一个公司的邮件服务器和其他服务器可以使用相同的别名。

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

如果服务器不是用于某主机名的权威服务器。

• 将包含一条类型 NS 记录，该记录对应于包含主机名的域。
• 还将包括一条类型 A 记录，提供在 NS 记录的 Value 字段中的 DNS 服务器的 IP 地址。

1. DNS 报文

DNS 报文只有 查询 和 回答 两种类型。有着相同的格式。

① 前 12 个字节是首部区域。

• 第一个字段（标识符）是一个 16 bit 的数，用于标识该查询。会被复制到对查询的回答报文中。以便让客户匹配发送的请求和接收的回答。
• 标志字段中含有若干标志。
  • 1 bit 的 “查询/回答”标志位 指出报文是查询报文（0）还是回答报文（1）。
  • 1 bit 的 “权威的”标志位 被置在回答报文。表示 DNS 服务器是所请求名字的权威 DNS 服务器。
  • 1 bit 的 “希望递归”标志位 在查询报文中，在 DNS 服务器没有某记录时，希望它执行递归查询。
  • 1 bit 的 “递归可用”标志位 在回答报文中，表示该 DNS 服务器支持递归查询。
• 首部中还有 4 个有关数量的字段。指出了在首部后的 4 类数据区域出现的数量。

② 问题区域包含正在进行的查询信息。 该区域包括：

• 名字字段，包含正在被查询的主机名字。
• 类型字段，指出有关该名字的正被询问的问题类型。
  • 如 主机地址是与一个名字相关联（A）
  • 还是与某个邮件服务器相关联（MX）

③ 回答区域记录了来自 DNS 服务器的回答。

• 包含了对最初请求的名字的 资源记录。
• 可以包含多条 RR，因此一个主机名可以有多个 IP 地址。

④ 权威区域 包含了其他权威服务器的记录。

⑤ 附加区域 包含了其他有帮助的记录。

• 对于一个 MX 请求的 回答报文的回答区域包含一条 资源记录，提供邮件服务器的规范主机名。
• 附加区域则会包含一个类型 A 记录，提供用于该邮件服务器的规范主机名的 IP 地址。

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

注册登记机构：一个商业实体，验证域名的唯一性，并将该域名输入 DNS 数据库。

因特网名字和地址分配机构（ICANN）向各种注册登记机构授权。

注册域名需要向机构提供 基本和辅助权威 DNS 服务器 的名字和 IP 地址。

对两个权威 DNS 服务器的每一个，注册登记机构确保将一个 类型 NS 和一个 类型 A 的记录输入 TLD com 服务器。

每台 DNS 服务器中的内容都是静态配置的。

最近，在 DNS 协议中添加了一个 更新 选项，允许通过 DNS 报文对数据库中的内容进行动态添加或者删除。

3. DNS 的脆弱性

针对 DNS 服务的攻击：

1. 分布式拒绝服务（DDoS）带宽洪泛攻击。
   • 攻击则向每个 DNS 根服务器 发送大量的分组。使得大多数合法 DNS 请求得不到回答。
     • 许多 DNS 根服务器 都受到了分组过滤器的保护。
     • 此外，大多数本地 DNS 服务器缓存了 顶级域名TLD服务器的 IP 地址，使得这些请求过程通常绕过了 DNS 根服务器。
   • 向顶级域名服务器发送大量的 DNS 请求。
     • 过滤指向 DNS 服务器的 DNS 请求将更为困难
     • 且顶级域名服务器不像根服务器那样容易绕过。
     • 通过 本地 DNS 服务器中的缓存技术可以缓解。
2. 中间人攻击，攻击者截获来自主机的请求并返回伪造的回答。
3. DNS 毒害攻击，攻击者向一台 DNS 服务器发送伪造的回答，诱使服务器在它的缓存中接收伪造的记录。
   • 都会将 Web 用户重定向至攻击者的 Web 站点。
   • 但难以实现，因为要求截获分组或遏制住服务器。

DNS 自身已经显示了对抗攻击的令人惊讶的健壮性。

(未完)