6. 应用层

网络应用模型

💡低优先级

非常简单的两个概念，简单看看，基本就是常识，选择题有小概率考查，都是送分题。

真题练习

C/S 模型

C/S（Client Server）模型：中心化、依赖服务器，适合稳定服务场景。

• 核心特点：客户端 （用户设备，如电脑、手机）向 服务器 （提供服务的专用设备）请求资源或服务，服务器响应并提供支持。具有上下级关系， 客户端之间不能交流。

• 通信方式：基于 “请求-响应”，客户端主动发起，服务器被动应答。

• 架构：中心化，服务器是核心枢纽，客户端依赖服务器获取服务。

• 典型例子：浏览网页（浏览器与 Web 服务器）、DHCP 、收发邮件（邮件客户端与邮件服务器）。

P2P 模型

P2P（Peer to Peer）：分布式、节点平等，适合资源共享和去中心化场景。

• 核心特点：网络中 设备对等，既是客户端又可作服务器，共同协作共享资源。

• 通信方式：设备直接互联，点对点通信，无需中心服务器。

• 架构：分布式，去中心化，资源分散在各节点，网络更灵活。

• 典型例子：文件共享（如 BitTorrent）、音视频通话（如 Skype）、区块链（如比特币）。

DNS

💡低优先级

在选择题中偶尔有考查，需要掌握 DNS 的域名服务器的不同层级，以及域名解析过程的两种方式（迭代和递归）。

真题练习

DNS 在传输层的封装的是 UDP 格式。

层次域名空间

DNS 使用 层次域名空间 来组织域名，将域名划分为多个级别，每个级别之间以点（.）分隔。域名从右到左逐级递增，最右边是 顶级域名（TLD），然后是 二级域名， 三级域名，以此类推。

例如， www.example.com 中， .com 是顶级域名， example.com 是二级域名， www.example.com 是子域名。

DNS 层次域名空间 的设计使得域名分布在不同的管理区域中，每个管理区域负责管理其自己的域名空间。这种分层结构有助于提高可扩展性和效率。

域名服务器

在 DNS 体系结构中，服务器按照层级划分，每一层负责不同的职责。下面按照从最高层到最低层的顺序，对四类常见的域名服务器进行说明：

1. 根域名服务器 (Root Name Servers):

   • 这些服务器位于 DNS 解析的最顶端。它们不直接回答关于哪个域名映射到哪个 IP 地址的查询，而是告诉查询者下一步应该询问哪个顶级域名（TLD）服务器。

   • 根服务器的数量是有限的，并且它们的位置在全球都是已知的。

2. 顶级域名服务器 (Top-Level Domain Name Servers, TLD):

   • 这些服务器负责特定的顶级域名（如 .com, .org, .net 等）。它们为下一级的域名（如 example.com）提供有关权威名称服务器的信息。

3. 权威域名服务器 (Authoritative Name Servers):

   • 这些服务器为特定的域名（如 example.com）提供详细的 DNS 记录信息（例如 A 记录、MX 记录等）。只有权威服务器才能为其负责的域名提供这些信息。

   • 大多数组织拥有权威 DNS服务器来为他们的域名提供解析服务。

   • 一个域可以有多个区，因此权限域名服务器可以有多个

4. 本地域名服务器 (Local Name Server)

   • 是在本地网络环境中运行的DNS服务器，它为该网络中的设备提供域名解析服务。

   • 每个 ISP 或一所大学都可以有一个本地域名服务器。

域名解析过程

域名解析分为 递归查询 和 迭代查询 两种。

• 递归查询：请求方（本地 DNS 服务器）把解析任务 完全交给 对方。(我帮你查)
• 迭代查询：请求方会得到一个“指引”，然后自己去问下一层。（告诉地址，你自己查）

迭代查询

在域名解析过程中，本地域名服务器 向根域名服务器发送的通常是迭代查询。

当 根域名服务器 收到查询请求后，不会代替本地域名服务器继续查询，而是返回结果中的两种情况之一：

• 若能解析出所需的 IP 地址，则直接返回；
• 若不能解析，则告知本地域名服务器应当联系的下一级顶级域名服务器。

随后，本地域名服务器根据指引，向对应的 顶级域名服务器 继续查询。顶级域名服务器的处理方式类似：

• 若能解析出所需的 IP 地址，则返回结果；
• 否则告知本地域名服务器应当访问的下一步权限域名服务器。

权限域名服务器的处理流程类似，这里不赘述了。最终，当本地域名服务器获得目标域名对应的 IP 地址后，会将结果返回给最初发起请求的主机。

递归查询

递归查询的过程如上图所示，本地域名服务器只需向 根域名服务器查询一次（步骤 2），后面的几次查询都是 递归地 在其他几个域名服务器之间进行的（步骤 3-7）。在步骤 7 中，本地域名服务器从根域名服务器得到了所需的 IP 地址，最后在步骤 8 中，本地域名服务器把查询结果告诉发起查询的主机。

因为该方法给根域名服务器造成的负载过大，所以实际中几乎不使用。

DNS 递归查询 和 迭代查询的不同点如下表所示：

特点	递归查询	迭代查询
查询责任	DNS 服务器负责查询所有结果	客户端逐级查询
查询复杂度	客户端简单，只需发起一次请求	客户端复杂，需要多次查询
使用场景	用户设备、本地 DNS 服务器	DNS 服务器之间的交互
性能	服务器负担较大	服务器负担较小

DNS 缓存

无论是浏览器、操作系统，还是本地的递归 DNS 服务器，在接收到域名解析结果之后，都会将其暂时保存在本地 缓存 中。这样，如果同一个域名在短时间内被多次请求，就可以直接从 缓存 中获取结果，而不需要再次向外部服务器发送查询请求。

DNS 记录中包含一个名为 TTL（Time to Live）的字段，用于指定这条记录可以在缓存中 保存多久。比如 TTL 为 3600 表示记录在缓存中可保留 3600 秒（即一小时）。在这段时间内，只要有查询，就可以直接使用缓存的结果。当 TTL 到期后，缓存记录会被丢弃，下一次查询将重新走完整的解析流程。

例题

DHCP

FTP

💡低优先级

考查概率比较小，了解 FTP 的基本原理，以及 数据连接 和 控制连接 的功能即可。

真题练习

将某台计算机中的文件通过网络传送到可能相距很远的另一台计算机中，是一项基本的网络应用，即文件传送。

文件传送协议（File Transfer Protocol，FTP）是因特网上使用得最广泛的文件传送协议。

• FTP提供交互式的访问，允许客户指明文件的类型与格式（如指明是否使用ASCII码），并允许文件具有存取权限（如访问文件的用户必须经过授权，并输入有效的口令）

• FTP屏蔽了各计算机系统的细节，因而适合于在 异构网络 中任意计算机之间传送文件。

在因特网发展的早期阶段，用FTP传送文件约占整个因特网的通信量的三分之一，而由电子邮件和域名系统所产生的通信量还要小于FTP所产生的通信量。只是到了1995年，万维网WWW的通信量才首次超过了FTP。

工作原理

两个连接的默认端口号（21、20）都是 FTP 服务器的。

控制连接保持连接状态不断，数据连接（TCP 连接）在传输完文件后会被关闭

FTP 的传输流程如下：

1. 建立连接

   • FTP 基于 TCP 协议运行。客户端与服务器之间首先建立一条 控制连接（服务器默认端口 21），用于命令与响应的传输。
   • 在实际传输数据时，还需要建立一条 数据连接。

2. 身份验证

   • 建立控制连接后，客户端需提供用户名和密码完成身份验证。
   • 部分服务器支持 匿名 FTP，允许用户以通用用户名（通常为 anonymous）和邮箱地址作为密码进行访问。

3. 命令与响应

   • 所有的 命令与响应 都通过控制连接完成。
   • 客户端发送命令（如上传、下载、列目录等），服务器返回 状态码（如成功、失败、权限不足），用于指示执行结果。

4. 数据连接的建立

   • 当需要传输文件或目录列表时，FTP 会额外建立数据连接。

   • 常见的两种模式：

     • 主动模式（Active Mode）：客户端 随机 开放一个端口，等待服务器 20端口 回连进行数据传输。（服务器连到客户端端口）
       
     • 被动模式（Passive Mode）：服务器 随机 开放一个端口，等待客户端发起连接。（客户端连到服务器）
       

5. 文件传输

   • 数据连接建立后即可传输数据，包括文件内容或目录信息。
   • 支持两种传输模式：
     • ASCII 模式：适合文本文件，自动进行换行符转换。
     • 二进制模式：适合图像、音频、压缩包等二进制文件，逐字节传输，避免数据损坏。

6. 关闭会话

   • 文件传输完成或用户退出时，客户端通过  QUIT 命令 请求关闭会话。
   • 服务器响应后，释放控制连接与数据连接。

控制连接

• 控制连接 是 FTP 会话中首先建立的连接，通常使用 TCP 端口 21。

• 主要作用是传输 命令和响应，用于 控制 FTP 会话的行为。

  • 客户端通过控制连接发送命令（如登录、列目录、切换目录）。

  • 服务器通过控制连接返回 状态码 和响应消息，指示命令执行结果（成功、失败、权限不足等）。

• 控制连接始终保持打开（持久连接），直到用户退出会话或发送 QUIT 命令。

数据连接

• 数据连接 专用于 文件内容和目录列表的传输，端口号由控制连接中的命令协商确定。

• 建立方式有两种模式：

  • 主动模式（Active Mode）
    • 客户端开放一个本地端口，并通过控制连接通知服务器。
    • 服务器主动连接到客户端该端口完成数据传输。
  • 被动模式（Passive Mode）
    • 服务器开放一个本地端口，并通过控制连接告知客户端。
    • 客户端主动连接到服务器该端口完成数据传输。
  • 数据连接 在需要时建立，用于 上传文件（客户端 → 服务器）或 下载文件（服务器 → 客户端）。

下图展示了 FTP 数据连接两种建立方式的区别：

例题

电子邮件

⭐中优先级

在选择题中考查，主要关注 SMTP、POP3、MIME 这几个协议的特点，还需要了解下电子邮件系统中几个组成部分。

真题练习

历史背景

电子邮件 E-mail 是因特网上最早流行的一种应用，并且仍然是当今因特网上最重要、最实用的应用之一。

传统的电话通信属于实时通信，存在以下两个缺点：

• 电话通信的主叫和被叫双方必须同时在场；
• 一些不是十分紧迫的电话也常常不必要地打断人们的工作或休息。

---

而电子邮件与邮政系统的寄信相似。

1. 发件人将邮件发送到自己使用的邮件服务器；

2. 发件人的邮件服务器将收到的邮件按其目的地址转发到接收方邮件服务器中的邮箱；

3. 收件人在方便的时候访问收件人邮件服务器中自己的邮箱，获取收到的电子邮件。

电子邮件使用方便、传递迅速而且费用低廉。它不仅可以传送文字信息，而且还可附上声音和图像。

由于电子邮件的广泛使用，现在许多国家已经正式取消了电报业务。在我国，电信局的电报业务也因电子邮件的普及而濒临消失。

电子邮件系统

电子邮件系统由 用户代理、邮件服务器 以及 电子邮件协议 这三个核心组成部分协同工作，确保邮件的发送、接收和存储。

用户代理

用户代理（UA, User Agent）是用户与电子邮件系统交互的接口，通常是邮件客户端软件（如 qq 邮箱网页界面、Outlook 等）。

功能：

• 提供用户友好的界面，用于撰写、发送、接收和阅读邮件。
• 管理邮件文件夹（如收件箱、已发送、草稿）。
• 与邮件服务器通信以发送或获取邮件。

邮件服务器

邮件服务器（Mail Server）是电子邮件系统的核心，负责存储、转发和管理邮件。

功能：

• 接收来自用户代理的邮件并存储。
• 根据邮件的目标地址，通过 SMTP 协议将邮件转发到目标邮件服务器。
• 提供邮件存储功能，供用户通过 POP3/IMAP 协议访问。 核心

SMTP

SMTP（Simple Mail Transfer Protocol）是用于邮件发送的标准协议，负责在邮件服务器之间或从用户代理到邮件服务器传输邮件。

功能：

• 定义了邮件如何从发送方传递到接收方的邮件服务器。
• 工作在 TCP/IP 协议之上，通常使用端口 25（或加密端口 587）。
• 仅负责邮件的发送，不涉及邮件的接收或存储。

工作流程：

• 用户代理通过 SMTP 将邮件发送到发送方的邮件服务器。
• 发送方服务器通过 SMTP 与接收方服务器通信，将邮件传递到目标服务器。

POP3

POP3 是用于从邮件服务器检索邮件的协议，允许用户将邮件下载到本地设备。

功能：

• 用户代理通过 POP3 连接到邮件服务器，下载邮件到本地。
• 默认情况下，邮件下载后会从服务器删除（可配置保留）。
• 工作在 TCP/IP 协议之上，通常使用端口 110（或加密端口 995）。

工作流程：

• 接收方用户代理通过 POP3 登录服务器。
• 下载新邮件到本地设备。
• 可选择删除服务器上的邮件副本。

注意

需要注意的是，SMTP 使用的是 “推送”（Push）方式进行通信。当用户代理发送邮件，或者邮件在邮件服务器之间传递时，SMTP 客户端会将邮件 主动推送 到 SMTP 服务器。

而 POP3 则采用 “拉取”（Pull）方式进行通信。当用户需要查看邮件时，用户代理会向邮件服务器发出请求，从服务器中 拉取 用户邮箱里的邮件。

IMAP

还有一种邮件读取协议是IMAP，比POP复杂很多，提供了创建文件夹、不同文件夹之间移动邮件和远程文件夹中查询邮件等联机命令。并且允许用户代理只获取报文的某些部分。

目前也新出现了很多基于万维网的电子邮件，如Hotmail、Gmail等，这种电子邮件的特点是用户浏览器与邮件服务器之间的邮件发送/接收使用HTTP，仅在不同邮件服务器之间传送邮件时才使用SMTP

电子邮件格式

一封电子邮件由 信封 和 内容 两部分组成，其中邮件 内容 又可分为 首部 和 主体。
邮件的 首部格式 由 RFC 标准定义，而 主体部分 则由用户自由撰写。

用户在填写完邮件首部后，系统会自动提取 信封 所需的信息，无需用户手动填写 信封 内容。

邮件首部由若干 首部行 组成，每行格式为：关键字: 值。其中：

• To：必填，指定一个或多个收件人的电子邮件地址，格式为 用户名@域名，如 abc@csgraduates.com。用户名在所属域名下必须唯一，从而保证该邮箱地址在整个互联网上唯一。
• Subject：可选，表示邮件主题，用于概括邮件内容。
• From：必填，表示发件人邮箱地址，通常由邮件系统自动填写。

首部和主体之间用一个空行分隔。以下是一个典型邮件内容示例：

From: sender@example.com
To: abc@cskaoyan.com
Subject: Meeting Schedule

Dear team,
Please find the meeting schedule attached.

MIME

MIME（Multipurpose Internet Mail Extensions，多用途互联网邮件扩展）是为了解决传统电子邮件格式的局限性而提出的一种扩展标准。

早期的电子邮件只能传输 纯文本（ASCII 码），不支持发送图片、音频、视频或非英语字符（如中文）。这严重限制了电子邮件的用途。MIME 的出现，就是为了解决这些问题。

MIME 主要包含以下三点 核心功能：

1. 支持 非 ASCII 字符
   • 允许使用 UTF-8 等编码发送包含中文、法语等字符的邮件内容。
2. 支持 多媒体内容
   • 可以发送图像（如 JPEG、PNG）、音频、视频等多种格式的附件或内嵌内容。
3. 支持 多部分内容（multipart）
   • 一封邮件可以同时包含文本和附件，甚至不同格式的内容（例如纯文本和 HTML 格式的正文）。

万维网

⭐中优先级

经常在选择题中考查 HTTP 协议的几个特性，包含 HTTP 的基本方法和状态码以及几个关键字段。

真题练习

WWW

WWW，也称为 万维网（World Wide Web），是一个信息系统，在这个系统中，文档和其他资源通过 统一资源标识符（Uniform Resource Identifiers，或 URI，通常为 URL）进行标识和互相链接。用户可以使用 网络浏览器 访问 万维网 上的资源。

组成结构

1. URL (统一资源定位符)：每个网页或资源都有一个唯一的地址，称为 URL，它定义了资源的位置和如何访问它。

2. HTTP/HTTPS (超文本传输协议/安全超文本传输协议)：这是用于从服务器传输网页到浏览器的协议。

3. HTML (超文本标记语言)：大多数网页使用 HTML 编写，它是用于描述和呈现超文本的标准标记语言。

重要 结构作为这个知识点的 记忆点 需要重点关注

HTTP 协议

HTTP（超文本传输协议）是互联网上应用最为广泛的一种网络协议。它是一个属于 应用层 的协议，常基于 TCP/IP 协议通信。HTTP 用于 客户端 和 服务器 之间的数据传输，特别是在 万维网（WWW）中，用于传输网页（HTML 文件）以及与其关联的资源（如图片、音频、视频等）。

无状态

HTTP 本身不保持 无状态 信息，每个请求都是独立的，服务器无法识别是不是同一个用户发送的多个请求。这一点在现实中通常通过 Cookie 和 Session 技术来弥补。

组成部分

上图展示了 HTTP 协议的几个重要组成部分，对于考试而言，重点关注 以下字段：

1. 请求和响应：HTTP 通信通常包括 客户端 向 服务器 发送 请求，然后 服务器 返回 响应 的过程。

2. 方法：HTTP 定义了一组 请求方法，用于表示对资源的不同操作：

   • GET：请求指定资源。
   • POST：提交数据以供处理。
   • PUT：更新指定资源。
   • DELETE：删除指定资源。
   • HEAD：与 GET 相似，但只请求资源的头部信息。

3. 状态码：响应返回一个 状态码，用于表示请求的结果，例如：

   • 200 OK：请求成功。
   • 404 Not Found：资源未找到。
   • 500 Internal Server Error：服务器内部错误。
   • 以及其他众多 状态码，用于表示不同的响应状态。

4. 头部字段：HTTP 请求和响应都包含 头部信息，提供有关请求或响应的元数据，例如 Content-Type（内容类型）或 User-Agent（用户代理）。

   • 消息体：请求 或 响应 的主体部分，通常包含要传输的数据。例如，POST 请求的数据或 服务器 返回的网页内容。

关键字段

以下首部字段可能在考试中被考察，需要了解一下：

方法 和 状态码 字段在组成部分已介绍，其余部分属于细枝末节，不予讨论。

长连接和短连接

长连接和短连接含义

HTTP 根据首部的 keepalive 选项是否被设置被分为 长连接 和 短连接。

• 长连接（持久连接，persistant connection）通过设置 keepalive 选项，可以在一个 TCP 连接 中发送多个 HTTP 请求。
• 短连接（非持久连接，multiple connection）没有设置 keepalive 选项，那么每一次发送 HTTP 请求都必须单独建立一个 TCP 连接。

HTTP 不同版本中的 keepalive

• 在 HTTP/1.0 中，持久连接 不是默认行为。要在 HTTP/1.0 中启用它，必须在请求头部添加 Connection: keep-alive 。
• 在 HTTP/1.1 中及之后，持久连接 是默认行为。如果想关闭它，必须在请求或响应头部添加 Connection: close 。 重要性质

流水线和非流水线

HTTP 流水线和非流水线含义

• 流水线（HTTP Pipelining）：HTTP 客户端在未等待前一个请求的响应的情况下，连续发送多个 HTTP 请求。
• 非流水线（Non-pipelined）：HTTP 客户端必须接收到上一个请求的响应，才能发送下一个请求。

HTTP 不同版本中的流水线支持

• 在 HTTP/1.0 中，流水线 的功能并不支持。
• 在 HTTP/1.1 中，引入了 HTTP 流水线 的支持，但由于使用中队头阻塞的问题，应用并不广泛。
• 在 HTTP/2 中，进一步改进了请求处理机制，允许多个请求和响应在同一个连接中并行进行，解决了队头阻塞的问题。

注意

什么是 队头阻塞（了解即可）

当多个请求被排成队列时，如果第一个请求由于某种原因（如延迟、丢包或慢速响应）未能及时处理，那么后续的所有请求都必须等待第一个请求的响应完成才能被处理。

在 HTTP/2.0 之前，你只有在完成上一个 HTTP 请求后，才能发送下一个请求。但是在 HTTP/2.0 中，你可以并发地发送多个 HTTP 请求，这些请求被并发地处理。

HTTP/1.1 和 HTTP/2 之间的区别

连接类型	传输方式 (连续性)	基础 RTT 耗时	拥塞窗口的交互表现	题目常见大坑 / 注意事项
非持久	非流水线	$2(N+1)\times \text{RTT}$	每个对象建立新连接，cwnd 全部重置为初始值	无，通常只需死记 $2(N+1)$。
非持久	并行连接	介于 $2\text{ RTT}$ 到 $2(N+1)\text{ RTT}$ 之间	多个 TCP 连接并发慢启动，各自独立计算 cwnd，抢占带宽。	考试若说“浏览器支持 $M$ 个并行连接”，需将 $N$ 个对象分组计算。
持久	非流水线	$(N+2)\times \text{RTT}$	cwnd 持续继承并增长。但因不连续发请求，大窗口优势可能因等待请求而无法完全发挥。	一个 RTT 只能发一个请求。即使 cwnd=100，你也只能等收到上一个对象后才能发下一个。
持久	流水线	理论理想值：$3\times \text{RTT}$	cwnd 完美继承并持续放大。在传输 $N$ 个对象时，cwnd 的限制是关键。	考研最爱考！此时 $N$ 个请求能发多少取决于当前 cwnd 的大小。若 $N>\text{cwnd}$，则需要拆分成多个 RTT 传输。

💡 核心做题口诀

1. 看到“非持久”：直接找 TCP 握手，每一次请求对象都要加 $1\text{ RTT}$ 的握手时间。

2. 看到“持久+流水线”：握手只有一次（$1\text{ RTT}$）。后续对象能不能在一个 RTT 里传完，全看拥塞窗口（cwnd）够不够大。如果 cwnd 小于剩余对象数，就得按照慢启动规律（1, 2, 4, 8…）分轮次（每轮 1 RTT）传输。

3. 持久 + 非流水线： 非文本 数据 的 MSS 个数 + HTTP 握手后发送文本数据给 客户的时间（$2\text{ RTT}$)

cookie

HTTP 协议是 无状态 的，这意味着每个请求都是独立的，服务器 默认情况下无法知道两个请求是否来自同一客户端或用户。Cookie 的引入使得 服务器 能够跨多个请求“识别”和“记住”用户。

HTTP 服务器通过 Set-Cookie 首部字段来设置每一个客户端的 Cookie 值，相应的 HTTP 响应的部分内容如下所示：

HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Path=/; Secure; HttpOnly

当浏览器接收到带有 Set-Cookie 字段的 HTTP 响应时，就会在存储该 Cookie 字段，并在下次向对应的 服务器 发送 HTTP 请求时自动将 Cookie 字段添加在 HTTP 首部，之后的 HTTP 请求的部分内容如下所示：

GET /dashboard HTTP/1.1
Cookie: sessionId=abc123

当 HTTP 服务器 接收到带有 Cookie 的请求时，它就可以区分这个请求是来自于那个客户端的了。

例题

WWW 请求接收的题目经常和 拥塞窗口相关，如 下图所示。