《计算机网络自顶向下方法》笔记 (1) 应用层

应用层

应用层是网络应用程序及它们的应用层协议存留的地方，位于应用层的信息分组称为报文（message）。

2.2 Web 和 HTTP

HTTP概况

Web 的应用层协议是超文本传输协议（HTTP），HTTP 运行在服务端和客户端中，两者通过交换 HTTP 报文进行会话。服务器提供 Web 界面，通常含有一个 HTML 基本文件及其通过 URL 引用的几个对象，其中 URL 由存放对象的服务器主机名和对象的路径名组成。

HTTP 运行在 TCP 协议上，端口号为 80。HTTP 客户向服务器发起 TCP 连接，连接建立后，两者即可通过套接字接口互相发送 HTTP 报文。一旦报文通过套接字接口，就完全进入了 TCP 的控制。

HTTP 不保存关于客户的任何信息，是一个无状态协议。服务器将独立处理从客户端发送而来的每个 HTTP 报文，即使是同一个用户在短时间内对同一个对象的重复请求。

非持续连接和持续连接

一对客户的请求及服务器对其的响应，我们称之为一个请求响应事务；一个请求响应事务所花费的大致时间，我们称之为往返时间（RTT）。考虑一系列请求响应事务：

若每个请求响应事务都使用各自的 TCP 连接，称为非持续连接，这意味着一个 TCP 连接将在一个请求响应事务完成后即拆除；若所有请求响应事务使用同一个 TCP 连接，称为持续连接，这意味着一个 TCP 连接将保持一段时间，在这段时间内，所有请求响应事务都经由该连接完成，若该连接经过一定时间间隔（可配置的超时间隔）未被使用，HTTP 服务器就关闭该连接。

非持续连接的缺点：一是必须为每个请求的对象建立并维护一个全新的连接，建立每个连接都需要消耗资源，这为服务器带来了沉重的负担；二是必须为每个请求的对象耗费 2 RTT 的时延，一个用于创建 TCP 连接，另一个用于请求和接收一个对象。

非持续连接可以采用并行连接优化。客户端打开多个并行的 TCP 连接，每个连接都处理一个请求响应事务。

持续连接可以采用流水线优化。非流水线的客户端必须串行执行每个请求响应事务，而采用流水线的客户端能够接连发送多个请求，而不必等待上一个请求的响应到达。

各个版本时延比较

假定客户端发送一个请求，服务器响应以一个附有八个小对象的 HTTP 文件，计算各个版本的时延。

串行非持续连接：一个 HTTP 基本文件耗时 2 RTT，八个小对象耗时 16 RTT，共计 18 RTT

并行非持续连接：假定采用五个并行连接，一个 HTTP 基本文件耗时 2 RTT，八个小对象分两批请求，耗时 4 RTT，共计 6 RTT

非流水线持续连接：一个 HTTP 基本文件耗时 2 RTT，此时 TCP 连接已建立好，接下来八个小对象均可利用该连接进行请求，每次请求和接收耗费 1 RTT，八个对象耗时 8 RTT，共计 10 RTT

流水线持续连接：一个 HTTP 基本文件耗时 2 RTT，八个小对象的请求并行处理，耗费 1 RTT，共计 3 RTT

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

HTTP 报文格式

1. HTTP 请求报文

一个典型的 HTTP 请求报文如下所示：

第一行是请求行，从左到右由空格分隔的依次是方法字段、URL 字段和 HTTP 版本字段。方法字段常见为 GET 和 POST，也有 HEAD、PUT 和 DELETE 等。URL 字段指明请求对象的路径名。版本字段指明使用的版本，一般是 HTTP/1.1 版本。

往下是首部行，一直到空行（CRLF）为止，由若干个键值对构成，指明该请求的一些附加信息。

最后是实体体，通常在使用 POST 方法提交表当时使用实体体，在使用 GET 方法时实体体通常为空。

2. HTTP 响应报文

一个典型的 HTTP 响应报文如下所示：

第一行是状态行，从左到右依次是协议版本字段、状态码和相应状态信息。往下是首部行，一直到空行为止。最后是实体体，包含了所请求的对象的内容。

用户与服务器的交互：cookie

HTTP 是无状态的，这简化了服务器的设计，并提供了提高性能的空间。然而，服务器通常希望识别发送报文的用户，为此，HTTP 采用了 cookie。

cookie 用于标识一个用户的过程：用户首次访问一个站点时，服务器的 HTTP 响应报文的首部行中包含一个 cookie，用户的浏览器保存并管理该 cookie。当用户再次向该站点发送 HTTP 请求报文时，浏览器将该 cookie 添加至报文的首部行中，服务器接收到请求报文后，查看首部行中的 cookie 字段，并与站点的后端数据库进行比对，因此识别出用户。cookie 在一段时间后会过期，在过期前，用户都可凭 cookie 标识自己的身份。

这样，cookie 就在无状态的 HTTP 之上建立了一个用户会话层。

Web 缓存

Web 代理服务器具有磁盘存储空间，并在存储空间中保存最近请求过的对象的副本，以此代理用户的 HTTP 请求。

使用代理服务器，客户端首先与代理服务器建立 TCP 连接，并向代理服务器发送 HTTP 请求。代理服务器检查存储空间中是否存有该请求的对象的副本，若有，则向客户返回请求的对象；若无，代理服务器将与该请求的初始服务器建立 TCP 连接，并发送 HTTP 请求，待初始服务器的响应报文到达后，代理服务器在存储空间中保存对象的副本，并向客户发送该副本。在此过程中，代理服务器既是服务器又是客户。

注意到，请求报文的 URL 字段只标识了对象的路径而没有主机的名称，而一个完整的对象应由主机名和对象路径来标识，那么代理服务器如何知道初始服务器呢？解决的方案是在请求报文中加上一个 “Host” 首部行，以该行的值作为主机名，与对象路径拼接起来，来判断是否备份了该对象的副本。

Web 代理服务器的优势：

1. 大大减少客户请求的响应时间，特别是当客户与初始服务器之间的瓶颈带宽远低于客户与代理服务器之间时；
2. 大大减少一个机构的接入链路到因特网的通信量；
3. 大大减少因特网整体的 Web 流量，从而改善了所有应用的性能。

条件 GET 方法

代理服务器的对象副本可能是过时的，为此，HTTP 提供了条件 GET 方法，以判断代理服务器备份的副本是否是最新的。

服务器的响应报文的首部行中，通常含有一个 “Last-Modified” 首部行，以标识对象的最后修改日期。代理服务器在存储对象的副本时，也会存储该最后修改日期。使用条件 GET 方法，代理服务器只要在请求报文中使用 GET 方法，并加上一个 “If-Modified-Since” 首部行，值为存储的对象最后修改日期。服务器在接收到该请求报文时，检查 “If-Modified-Since” 首部行中的时间。若在指定时间后对象被修改过，才发送该对象，否则服务器发送一个响应报文（并没有包含该对象），表明代理服务器持有的对象副本是最新的，可以使用。

2.3 文件传输协议：FTP

FTP 是文件传输协议，基于 TCP 协议，在 FTP 用户代理与远程主机之间运行，会话期间保留用户的状态信息。

FTP 协议使用两个并行的 TCP 连接，一个是控制连接（端口号为 21），用于在两主机之间传输控制信息，另一个是数据连接（端口号为 20），用于在两主机之间传输数据文件，其中，控制连接贯穿整个用户会话期间，而数据连接只在需要进行文件传输时按需建立。因为 FTP 协议使用一个独立的控制连接，所以称其控制信息是带外传送的，而 HTTP 显然是带内的。

FTP 的命令由 4 个大写的 7 比特长度的 ASCII 字符组成，如 USER、PASS 等。

2.4 因特网中的电子邮件

简单邮件传输协议 SMTP

电子邮箱由用户代理、邮件服务器和简单邮件传输协议（SMTP）组成，每个用户在某个邮件服务器上有一个邮箱。

邮件发送的过程是，从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中。如果发送方的邮箱所在的邮件服务器不能将邮件交付给接收方的邮件服务器，那么发送方的服务器会在一个报文队列中保持该报文并在以后尝试再次发送。

用户代理与邮件服务器之间、邮件服务器与邮件服务器之间都是通过 TCP 建立连接，其中邮件服务器的端口号为 25。SMTP 采用持续连接，如果发送服务器有几个报文发往同一个接收服务器，可以使用同一个 TCP 连接。

SMTP 与 HTTP 的相同点：持续的 HTTP 和 SMTP 都使用持续连接。

SMTP 与 HTTP 的不同点：

1. SMTP 基本是一个推协议，HTTP 主要是一个拉协议；
2. SMTP 要求每个报文（包括它们的体）使用 7 比特 ASCII 码格式，HTTP 不受格式限制；
3. SMTP 把所有报文对象放在一个报文中，HTTP 把每个对象封装到它自己的 HTTP 响应报文中。

邮件访问协议

SMTP 是一个推协议，所以不能用来从邮件服务器取报文。常见的邮件访问协议有 POP3、IMAP 和 HTTP。

1. POP3

POP3 按照三个阶段进行工作：特许、事务处理和更新。特许阶段，用户代理发送用户名和口令以鉴别用户；事务处理阶段，用户代理取回报文，通常有下载并删除和下载并保留两种方式，采用下载并保留，用户就能够在不同机器上读取邮件。

虽然在 POP3 会话期间，可能有某些邮件报文被标记为删除，但 POP3 是个无状态协议。

2. IMAP

POP3 是无状态协议，所以它不能将邮件指派到不同文件夹上，而维护了用户状态信息的 IMAP 协议可以。另外，IMAP 允许用户代理获取报文组件，如只读取一个报文的报文首部。

3. HTTP

HTTP 是个拉协议，所以同样能够胜任。此时，用户代理就是普通的浏览器，用户和他远程邮箱之间的通信通过 HTTP 运行，而邮件服务器之间仍然采用 SMTP。

2.5 DNS：因特网的目录服务

DNS 提供的服务

主机有两种标识方式，主机名或 IP 地址，显然人类喜欢主机名而路由器喜欢 IP 地址。为了解决这个冲突，互联网提供了一种能进行主机名到 IP 地址转换的目录服务：域名系统（DNS）。DNS 包括一个由分层的 DNS 服务器实现的分布式数据库，与一个使得主机能够查询分布式数据库的应用层协议组成，该协议运行在 UDP 上，端口号为 53。

DNS 将用户提供的主机名解析为 IP 地址，该服务通常提供给其他应用层协议，比如 HTTP、SMTP 和 FTP。用户视角下 DNS 服务过程为，首先用户主机上的 DNS 客户端将待解析的主机名发送给 DNS 服务器，等待 DNS 服务器返回包含相应的 IP 地址的报文，然后利用该 IP 地址进行后续操作。可以看到，DNS 引入了额外的时延。

DNS 除了域名解析外，还提供别的服务：

1. 主机别名。规范主机名通常较为复杂，使用较为简单的主机别名能够方便记忆，DNS 为规范主机名、主机别名与 IP 地址之间进行转换。
2. 邮件服务器别名。邮件服务器名也很复杂，使用较为简单的邮件服务器别名能够方便记忆。
3. 负载分配。繁忙的站点被冗余分布在多台服务器上，每台服务器均运行在不同的端系统上，有着不同的 IP 地址，因此，一个规范主机名就与一个 IP 地址集合相联系。DNS 服务器可以循环使用 IP 地址集合中的地址，来响应 DNS 解析请求，以分摊负载。

DNS 工作机理概述

如果因特网上仅使用一个 DNS 服务器，那么，在这种集中式设计中，可能会出现例如单点故障、通信容量过大、远距离时延过大、维护困难等问题，毫无扩展能力可言。为了处理扩展性问题，DNS 使用了大量的 DNS 服务器，以层次结构组织分布在世界各地。没有一台 DNS 服务器拥有因特网上所有主机的映射。

DNS 的层次结构，自顶向下依次是根 DNS 服务器、顶级域 DNS 服务器、权威 DNS 服务器。根服务器有 13 个；顶级域服务器负责顶级域名，如 com；权威服务器是因特网上具有公共可访问主机的组织机构提供的。

同时，还有与 Web 缓存类似的 DNS 缓存，也就是本地 DNS 服务器。本地 DNS 服务器代理用户的 DNS 请求，若请求的域名，在本地已有缓存，则向用户返回相应的 IP 地址，否则本地服务器将采用递归查询或迭代查询方式进行查询。实践中，从请求主机到本地 DNS 服务器的查询是递归的，其余的是迭代的。

本地 DNS 服务器缓存接收到的域名解析信息，并在一定时间后丢弃缓存的信息，因为主机名与 IP 地址的映射并不是永久的。有了 DNS 缓存，改善了时延性能，并减少了在因特网到处传输的 DNS 报文数量。

DNS 记录

DNS 服务器存储了资源记录，即包含了 (Name, Value, Type, TTL) 字段的四元组。对于不同的 Type，各个字段（除了 TTL，表示该记录的生存时间）有不同的含义：

• Type = A，则 Name 是主机名，Value 是该主机名对于的 IP 地址。
• Type = NS，则 Name 是个域，而 Value 是个知道如何获得该域中主机 IP 地址的权威 DNS 服务器的主机名。
• Type = CNAME，则 Value 是别名为 Name 的主机对应的规范主机名。
• Type = MX，则 Value 是个别名为 Name 的邮件服务器的规范主机名。

如果一台 DNS 服务器是用于某特定主机名的权威 DNS 服务器，那么该 DNS 服务器会有一条包含该主机名的类型 A 记录（缓存有该映射的本地服务器也可能有类型 A 的记录），否则该服务器将包含一条类型 NS 记录（Value 对应于包含主机名的域）与一条类型 A 记录（Value 对应于在 NS 记录的 Value 字段中的 DNS 服务器的 IP 地址）。

2.6 P2P 应用

続く