#应用层

#考点定位

• 所属大纲章节：客户服务器（C/S）模型与 P2P 模型；DNS 域名系统；FTP 文件传输协议；电子邮件（SMTP、POP3/IMAP、MIME）；WWW 与 HTTP 协议；DHCP（常与网络层结合出题）
• 常见题型：选择题（C/S 与 P2P 辨析、DNS 服务器职能与查询方式、FTP 端口与两大特点、邮件协议路径判断、HTTP 方法/状态码/持久连接、Cookie 与条件 GET）；计算题（HTTP 页面加载时间：非持久/持久非流水线/流水线；P2P 与 C/S 最小分发时间对比）
• 考查频率：高。HTTP 时间计算与 DNS 流程是 408 计网的"招牌计算题"，协议端口/协议辨析类选择题几乎每年出现

工程直觉迁移：你每天都在用 HTTP、DNS、DHCP，本章的任务是把工程直觉协议化、计算化——重点是精确到端口号、精确到 RTT 数的应试颗粒度。前置知识：TCP 建连与 RTT 见传输层；IP 地址、子网与广播地址见网络层；分层与服务概念见计算机网络体系结构。

#一、应用层模型：C/S 与 P2P

应用层协议只规定应用进程间通信的规则（报文类型、语法、语义、时序），底层运输层用 TCP 或 UDP（如何选见传输层）。从体系结构看，应用层只有两种基本模型。

#1. 客户服务器（C/S）模型

客户（Client）：服务请求方。主动发起通信，不需要特殊硬件与复杂操作系统。

服务器（Server）：服务提供方。被动等待客户请求，通常需要强大硬件与全天候运行。这里"服务器"指的是进程——一台主机可同时运行客户进程与服务器进程。

#2. P2P（对等）模型

不区分服务请求方与提供方，每个结点（对等方 peer）既是客户又是服务器，通信直接在对等方之间进行，无需始终在线的服务器中转。

#3. 对比（选择题高频）

注意：现实中大量系统是混合形态（如 BT 仍有 Tracker 服务器负责索引，即时通信登录用 C/S、消息传输用 P2P）。考试按"理想模型"辨析即可。

#二、DNS 域名系统

#1. 为什么需要 DNS

IP 地址难记，域名（如 www.uestc.edu.cn）便于人类使用。DNS 是一个分布式、层次化的联机数据库系统，完成"域名 → IP 地址"的映射解析，运行于 UDP 之上，端口 53（服务器端）。为什么用 UDP：DNS 查询单次数据量小，一问一答，UDP 无建连开销更快（区域传送例外，见下）。

DNS 同时还是一个分布式数据库，还提供别名、邮件服务器、负载均衡（同一域名返回多个 IP 轮询）等服务。DNS 采用 C/S 模型，但其解析任务由成千上万台服务器分担。

#2. 层次结构与三类域名服务器

域名空间是树形层次结构：根 → 顶级域（TLD）→ 二级域 → …… 每个域名从叶子写到根，各级以 . 分隔（末尾根的 . 通常省略）。

• 顶级域：国家顶级域 cn、us、jp；通用顶级域 com、net、org、edu、gov；基础结构域 arpa（反向解析）
• 二级域及以下：由相应机构自行分配，如 edu.cn 下的 uestc

服务器按层次分工（选择题核心，职能必须一一对应）：

区（zone）概念：DNS 树被划分成许多不重叠的区，每个区有权限服务器。abc.com 与 xyz.abc.com 可以分属两个区，也可以同属一个区——区 ≠ 层。

#3. 递归查询与迭代查询

两个关键定义（主机/本地服务器两跳分开记）：

• 递归查询：被查询者若不知道答案，必须代替请求者继续向下追问，直到拿到最终答案再逐级返回。"你要答案，我帮你跑腿到底"
• 迭代查询：被查询者只给出它所知的最佳答案（可能是最终答案，也可能是"下一个该问谁"），后续追问由请求者自己进行。"我只告诉你去问谁"

组合惯例（408 标准说法）：主机 → 本地域名服务器采用递归查询（主机把任务完全交给本地服务器）；本地域名服务器 → 根/TLD/权限服务器通常采用迭代查询（本地服务器自己逐级问）。

#4. 域名解析完整流程（分步 + 逐跳迭代示例）

设主机 m.abc.com 要解析 www.xyz.com.cn，本地服务器缓存未命中：

1. 主机运行 DNS 客户端，生成查询报文（UDP，目的端口 53），发往本地域名服务器——此跳为递归查询（"请给我最终答案"）
2. 本地域名服务器缓存未命中，代替主机发起后续查询——以下各跳为迭代查询
3. 本地服务器 → 根域名服务器：根不知道 www.xyz.com.cn，但知道 cn 由哪些 TLD 服务器管，返回 cn TLD 服务器地址
4. 本地服务器 → cn 顶级域名服务器：TLD 知道 com.cn 区域授权给了谁，返回权限服务器地址
5. 本地服务器 → 权限域名服务器（管 xyz.com.cn 区）：权限服务器持有权威记录，返回最终 IP 地址
6. 本地服务器把结果返回主机，并写入自身缓存；主机也缓存
7. 主机获得 IP，随后即可发起 TCP 连接访问该服务器

迭代逐跳要点：每一跳被问的服务器只答"我不知道，但去问它"（返回 NS 记录与地址），只有最终权限服务器给出 IP。若全程采用递归（题目可如此设定），则每级服务器代为向下追问，请求沿树下降再逐级原路返回。

缓存机制：任何服务器收到回答都可缓存映射，并设置 TTL（生存时间）过期作废；缓存命中则解析直接在本地完成，不再向外查询。若待查域名"不存在的记录"， 否定回答也可缓存。

#5. DNS 报文与资源记录（RR）

DNS 只有两种报文：查询报文与回答报文，格式相同（12 字节首部 + 4 个字段段）。

资源记录四元组：(Name, Value, Type, TTL)，类型表（选择题高频）：

#6. 补充考点

• 反向解析：IP → 域名，借助 in-addr.arpa 域与 PTR 记录
• 区域传送：主/辅权限服务器之间同步区数据，用 TCP（数据量大、要求可靠）——易与"DNS 用 UDP"混考
• DNS 使用的运输层协议：查询用 UDP 53，区域传送用 TCP 53

#三、FTP 文件传输协议

#1. 两大特点（必背）

（1）使用两个并行的 TCP 连接——控制连接与数据连接分离：

• 控制连接：端口 21。会话期间始终打开，传送客户端的命令（用户名、口令、get/put 等）与服务器应答。控制信息以 7 位 ASCII 格式带外传送
• 数据连接：端口 20（主动模式）。仅在有文件传输或目录列表时临时建立，传完即关闭

"带外"（out-of-band）控制：控制信息走专用的控制连接，不与数据混在同一连接里。

#2. 主动模式与被动模式

被动模式用于客户端位于 NAT/防火墙之后、服务器无法主动连入的场景。考试中"FTP 数据连接端口 20"指主动模式。

#3. 其他要点

• FTP 使用 C/S 模型；传输文件时不改变格式（不像 SMTP 可能编码转换），可传任意文件
• 匿名 FTP：用户名 anonymous，口令任意（惯例填邮箱）
• 简单文件传送协议 TFTP：基于 UDP 69，无认证、代码小（无盘启动场景），选择题易与 FTP 端口互扰

#四、电子邮件系统

#1. 组成三要素（必背）

#2. SMTP"推"与 POP3/IMAP"拉"（方向判断题核心)

• SMTP（TCP 25）：推送协议。发送方 UA → 发送方服务器、发送方服务器 → 接收方服务器，两段都是发送方主动把邮件推给对方
• POP3（TCP 110）：拉取协议。接收方 UA 主动从自己邮箱服务器下载邮件，"拉"
• IMAP（TCP 143）：也是拉取，但邮件保留在服务器上，支持在服务器上创建文件夹、部分下载、多设备同步（POP3 下载后默认从服务器删除、操作本地副本）

SMTP 细节：只能传送 7 位 ASCII 码（这是引入 MIME 的原因）；发件前先建立 TCP 连接，服务器间直接交付，不需中间服务器中转；交互命令为文本（HELO/MAIL FROM/RCPT TO/DATA 等）。

#3. 基于 Web 的邮件流程

用户通过浏览器访问邮箱（如网易邮箱网页版）时：浏览器与邮件服务器之间用 HTTP，但邮件服务器与邮件服务器之间仍用 SMTP。即 Web 邮件只改变了 UA 与服务器之间的"最后一公里"协议。

#4. MIME 概念

MIME（多用途互联网邮件扩展）：不是替代 SMTP，而是扩展——增加邮件主体的结构定义与非 ASCII 数据（图片、音频、中文、附件）的编码规则（如 Base64），编码后的结果仍是 ASCII，再交给 SMTP 传送。类比：MIME 是"内容翻译层"，SMTP 管道本身不变。

#五、WWW 与 HTTP

#1. WWW 与 URL

• WWW（万维网）：一个大规模、联机式的信息储藏所，用链接（超文本/超媒体）互连
• 三要素（一套体系）：HTML（文档表示）、URL（资源定位）、HTTP（传输协议）
• URL（统一资源定位符）一般形式：

$\text{协议类型}://\text{主机地址}[:\text{端口}]/\text{路径}[\?\text{查询}][\#\text{锚点}]$

例：http://www.abc.edu.cn:8080/cs/index.html——协议 http，主机 www.abc.edu.cn（也可写 IP），端口 8080（HTTP 默认 80，省略即 80），路径 /cs/index.html。注意 URL 里不出现用户名密码（教材标准形式），且 // 不可少。

#2. HTTP 特性总览

• 基于 TCP，默认端口 80；HTTP 本身无连接（交互前不需经 HTTP 层握手建连，建连由 TCP 代劳）、无状态（服务器不记忆客户，两次访问待遇相同）——后者引出 Cookie
• 面向文本：报文是 ASCII 可读文本

#3. HTTP 报文格式

请求报文：请求行 + 首部行 + 空行（CR LF）+ 实体主体（可选）

GET /cs/index.html HTTP/1.1        ← 请求行：方法 URL HTTP版本
Host: www.abc.edu.cn               ← 首部行（逐行 名: 值）
Connection: keep-alive
                                    ← 空行（必需，标志首部结束）
（实体主体：GET 一般为空，POST 放表单数据）

响应报文：状态行 + 首部行 + 空行 + 实体主体（如被请求的 HTML 文件本体）。

方法表（选择题高频）：

#4. 状态码分类表

状态行形如 HTTP/1.1 200 OK。状态码三位，按首位分类：

必记三件套：200 成功、301 重定向、404 找不到；条件 GET 成功时返回 304（正文为空，省带宽）。

#5. 非持久连接与持久连接（时间计算核心）

RTT（往返时间）：一个短分组从客户端到服务器再回到客户端所经历的时间（不含分组发送时延与服务器处理时延的应试简化）。TCP 建立连接需要"三次握手"，其中前两次握手恰好耗 1 个 RTT，第三次 ACK 与首个 HTTP 请求可同发——这是时间计算的建连开销来源（三次握手详见传输层）。

（1）非持久连接：每个对象都要"建连 → 请求 → 接收 → 断连"，一个 TCP 连接最多传送一个对象。HTTP/1.0 默认。

（2）持久连接：建连一次，传送多个对象后关闭。HTTP/1.1 默认。又分：

• 非流水线（non-pipelined）：收到前一个响应才能发下一个请求，每个对象各耗 1 个 RTT
• 流水线（pipelined）：收到 HTML 后连续发出全部对象请求，响应依次到达，理想情况下所有引用对象合计只耗 1 个 RTT

公式化分解（设页面 = 1 个基本 HTML + $n$ 个引用对象，RTT 均为 1 个单位；忽略传输时延）：

$T = \underbrace{1\ \text{RTT}}_{\text{TCP 建连}} + \underbrace{1\ \text{RTT}}_{\text{HTML 请求+返回}} + \left(\text{引用对象的获取开销}\right)$

推演逻辑（务必会复述，408 计算题常改问法）：

• 非持久：HTML 耗 2 RTT；每个对象都要重新握手，再耗 2 RTT → $2 + 2n$
• 持久非流水线：建连只做一次（HTML 用掉），此后每个对象仅 1 RTT 请求往返 → $2 + n$
• 持久流水线：建连 1 RTT + HTML 1 RTT，之后 $n$ 个请求一次发出、响应连续回来 → 再加 1 RTT → 共 3 RTT

变体提示：若题目说"每个对象的传输时延为 $t$"，则非持久每对象再加 $t$；若 DNS 解析未缓存，先加 1 个 DNS RTT；若问"从输入 URL 到页面完整显示"，别漏 HTML 本身的 2 RTT。并行连接（浏览器同时开多条 TCP）是另一种优化，题目会显式说明并行度 $k$，此时对象获取时间约为 $\lceil n/k \rceil$ 轮 × 每轮开销。

完整例题（模拟题）：主机要获取一个页面，该页面含 1 个基本 HTML 文件和 5 个 JPEG 图片引用，RTT = 100 ms，忽略传输与处理时延。分别求：①非持久连接；②持久非流水线；③持久流水线下的总时间。

解：

错因雷达：非持久漏算每个对象的建连 RTT（答成 $2+n$）；持久非流水线多算建连（答成 $7+n$）；流水线把 HTML 也并入流水线（答成 2 RTT——HTML 必须先到手才知道有哪些引用对象，无法与引用对象并行）。

#6. Cookie 机制

HTTP 无状态，但很多应用（购物车、登录态）需要记忆用户。Cookie 四组件：

1. HTTP 响应报文中的 Set-cookie: 首部行（服务器生成、标识用户）
2. 请求报文中的 Cookie: 首部行（浏览器此后对该站点自动携带）
3. 客户端保留的 Cookie 文件（由浏览器管理）
4. 服务器端的后台数据库（记录用户与 Cookie 标识的关联状态）

要点：Cookie 在标准（协议）层面无状态不变，状态存于两端（浏览器文件 + 服务器数据库），报文只是携带标识；会话 Cookie / 持久 Cookie 的区别在过期策略，408 不深入。选择题考"HTTP 无状态与 Cookie 的关系"：Cookie 是在应用之上为无状态 HTTP 补状态的手段，不改变 HTTP 本身。

#7. 代理服务器与 Web 缓存、条件 GET

代理服务器（Web 缓存，proxy cache）：代表原始服务器满足 HTTP 请求的中间实体。它既是服务器（对浏览器）又是客户（对原始服务器），保存最近请求过的对象副本。浏览器请求先到代理：命中则直接返回（时延 ≈ 接入网内一个 RTT），未命中则代理作为客户向原始服务器取回、缓存后返回。

价值：缩短响应时间、减少接入链路流量、降低接入链路压力（等效扩容），企业、校园网内部普遍部署。

条件 GET：保证缓存副本不过期的机制。满足两条件即为条件 GET：①请求方法为 GET；②首部带 If-Modified-Since: <日期>。

关键数字：304 响应不含实体主体，只传状态行与首部——这就是条件 GET 省带宽的原理；验证通过时代理仍从本地回给浏览器，端到端时延近似省掉对象传输时间。

#六、DHCP 动态主机配置协议

DHCP 属于应用层（套接字编程视角），但功能是给主机动态分配网络配置（IP 地址、子网掩码、默认网关、DNS 服务器地址），408 常与网络层、传输层联合出题（UDP 封装、广播地址）。

DORA 四步（Discover → Offer → Request → Acknowledge）：

分步要点：

1. Discover：客户机尚无 IP，源地址填 0.0.0.0，目的地址 255.255.255.255（受限广播，见网络层广播地址分类）。此广播封装在 IP 中，链路层以 MAC 广播帧（FF-FF-FF-FF-FF-FF） 投递（MAC 帧格式见数据链路层），所以同网段所有主机/服务器都能收到
2. Offer：网段内每台 DHCP 服务器广播（或单播）回一个"可用配置提案"
3. Request：客户机从多个 Offer 中选一个，以广播方式发送 Request——广播的用意是告知落选服务器"我没用你的，可以收回地址"；报文中含客户 MAC 与选中的服务器标识
4. ACK：被选服务器正式确认，客户机绑定 IP；此后可用单播正常通信。租用有期限，续租走单播 Request/ACK

传输层细节：DHCP 基于 UDP，服务器端口 67，客户端端口 68。"为什么全程要用广播"是命题点：第 ③ 步客户机仍未正式获得 IP，不能放心用单播，且必须让所有提案方都知道结果。

DHCP 中继：跨网段时由路由器充当中继代理转发 Discover（考试偶考概念，知道"路由器可转发 DHCP 广播请求到远端服务器"即可）。

#七、P2P 文件分发时间模型

场景：一个大小为 $F$（bit）的文件从服务器分发给 $N$ 个对等方。符号约定：

• $u_s$：服务器接入链路上载速率；$u_i$：第 $i$ 个对等方的上载速率；$d_i$：第 $i$ 个对等方的下载速率
• $d_{\min} = \min_i d_i$：下载最慢的对等方
• $u_{\text{total}} = u_s + \sum_{i=1}^{N} u_i$：系统总上载能力（P2P 模型中，每个对等方拿到数据后也能为别人上载）

（1）客户-服务器架构的最小分发时间

瓶颈有两个：服务器上载链路要送出 $N$ 份共 $NF$ bit；每个对等方下载链路要收完 $F$ bit。

$D_{C/S} \geq \max\left\{\frac{NF}{u_s},\ \frac{F}{d_{\min}}\right\}$

含义：$N$ 越大，第一项线性增长——用户越多越慢，服务器带宽是硬瓶颈。

（2）P2P 架构的最小分发时间

瓶颈仍是两个：全系统只需"注入"一份由服务器出的 $F$ bit 加上对等方之间转发不得凭空多出（总量守恒：至少要传 $F$ 给每个结点，但全网总上载能力变大）；每个对等方仍要收满 $F$ bit。

$D_{P2P} \geq \max\left\{\frac{F}{u_s},\ \frac{F}{d_{\min}},\ \frac{NF}{u_s + \sum_{i=1}^{N} u_i}\right\}$

含义：第三项中分子 $NF$ 是"全网要交付的总量"，分母是服务器 + 全体对等方的总上载能力。用户加入不仅增加需求也增加上载供给，故 $D_{P2P}$ 随 $N$ 增长远慢于线性（理想化模型，忽略请求开销与拓扑限制）。

对比例题（模拟题）：$F = 1$ Gbit，$u_s = 20$ Mbit/s，每个对等方 $u_i = 1$ Mbit/s、$d_i = 10$ Mbit/s，$N = 100$。求两种架构的最小分发时间下界。

解：

• $d_{\min} = 10$ Mbit/s，$F/d_{\min} = 1\,000/10 = 100$ s
• C/S：$NF/u_s = 100 \times 1\,000/20 = 5\,000$ s，故 $D_{C/S} = \max\{5000, 100\} = 5\,000$ s
• P2P：$u_{\text{total}} = 20 + 100 \times 1 = 120$ Mbit/s，$NF/u_{\text{total}} = 100\,000/120 \approx 833.3$ s，故 $D_{P2P} = \max\{1000/20,\ 100,\ 833.3\}$，其中 $F/u_s = 50$ s，取最大得 $\approx 833.3$ s

结论：$833$ s 对 $5\,000$ s——对等方越多，P2P 优势越大，量化印证了第一节的"自扩展性"。

按大纲掌握公式思想即可：会写两个 max 表达式、能代入数值、能解释每一项是哪个瓶颈；408 未考过此模型的完整推导证明。

#常见坑

1. DNS 服务器职能张冠李戴：给出"最终 IP"的是权限服务器；根服务器只返回 TLD 地址，从不直接解析到底；本地服务器不在层次树中，是主机代理
2. 递归/迭代看错位置：408 标准组合是"主机→本地递归，本地→根/TLD/权限迭代"。题目问"根服务器收到的是什么查询"，答案是迭代（除非题干明确设定全程递归）
3. DNS 端口与协议：查询 UDP 53，区域传送 TCP 53；"DNS 用 TCP"作为无附加条件的判断是错的
4. FTP 端口：控制 21、数据 20（主动模式）。被动模式数据端口非 20；TFTP 是 UDP 69 不是 TCP 20
5. 邮件协议方向：UA→发送服务器、服务器→服务器都是 SMTP（推）；只有"读邮件"是 POP3/IMAP（拉）。Web 邮件中浏览器与服务器间是 HTTP，服务器之间仍是 SMTP
6. HTTP 时间计算：非持久每对象 2 RTT（含重新建连）；流水线时基本 HTML 不能并入流水线（必须先拿到 HTML 才知道引用对象）；非流水线持久连接建连只算一次
7. 状态码：304 只出现在条件 GET 成功（未修改）时；301 是重定向不是错误
8. DHCP 第三步 Request 用广播：客户机此时无正式 IP，且需通知落选服务器收回提案；DORA 四步一个都不能少
9. P2P 分发公式：别忘了 $F/u_s$ 与 $F/d_{\min}$ 两项，P2P 的 max 有三项，取最大而非相加

#自测

1. 主机向本地域名服务器发出查询属于什么查询方式？本地服务器向根服务器的查询呢？
2. FTP 的控制连接与数据连接分别使用什么端口？哪条连接在整个会话期间始终打开？
3. 一封邮件从发送方 UA 到接收方 UA，依次经过哪些组件？各段分别用什么协议（推还是拉）？
4. 页面含 1 个 HTML 与 3 个图片，RTT = 50 ms，忽略传输时延。分别计算非持久、持久非流水线、持久流水线下的加载时间。
5. 条件 GET 的两个必要条件是什么？验证"对象未修改"时服务器返回什么状态码？

自测答案：

1. 主机→本地：递归查询；本地→根：迭代查询
2. 控制 21（始终打开）、数据 20（主动模式，按需建立）；控制连接始终打开
3. 发送方 UA --SMTP 推--> 发送方邮件服务器 --SMTP 推--> 接收方邮件服务器 --POP3/IMAP 拉--> 接收方 UA
4. 非持久：$(2+2\times3)\times50=400$ ms；持久非流水线：$(2+3)\times50=250$ ms；持久流水线：$3\times50=150$ ms
5. 方法为 GET 且首部含 If-Modified-Since；返回 304 Not Modified（空实体主体）