应用层

• 1: 网络应用模型
• 2: DNS
• 3: FTP
• 4: 电子邮件
• 5: 万维网

# 应用层

## 网络应用模型

- C/S模型
- P2P模型

## DNS系统

- 层次域名空间
- 域名服务器
- 域名解析过程

## FTP

- FTP协议的工作原理
- 控制连接和数据连接

## 电子邮件

- 电子邮件系统的组成结构
- 电子邮件格式和MIME
- SMTP协议与POP3协议

## WWW

- 概念和组成结构
- HTTP协议

1 - 网络应用模型

C/S 模型

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

• 核心特点：客户端 （用户设备，如电脑、手机）向 服务器 （提供服务的专用设备）请求资源或服务，服务器响应并提供支持。
• 通信方式：基于 “请求-响应”，客户端主动发起，服务器被动应答。
• 架构：中心化，服务器是核心枢纽，客户端依赖服务器获取服务。
• 典型例子：浏览网页（浏览器与 Web 服务器）、收发邮件（邮件客户端与邮件服务器）。

P2P 模型

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

• 核心特点：网络中 设备对等，既是客户端又可作服务器，共同协作共享资源。
• 通信方式：设备直接互联，点对点通信，无需中心服务器。
• 架构：分布式，去中心化，资源分散在各节点，网络更灵活。
• 典型例子：文件共享（如 BitTorrent）、音视频通话（如 Skype）、区块链（如比特币）。

2 - DNS

层次域名空间

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 地址后，会将结果返回给最初发起请求的主机。

sequenceDiagram
  participant Host as 主机
  participant Local as 本地域名服务器
  participant Root as 根域名服务器
  participant TLD as 顶级域名服务器 (TLD)
  participant Auth as 权限域名服务器 (Authoritative)

  Host->>Local: 1) 查询 www.example.com
  Local->>Root: 2) 迭代查询（请求根服务器）
  Root-->>Local: 3) Referral: 指向对应的 TLD 服务器（例如 .com）
  Local->>TLD: 4) 迭代查询（请求 TLD 服务器）
  TLD-->>Local: 5) Referral: 指向该域的 权限域名服务器
  Local->>Auth: 6) 迭代查询（请求权限域名服务器）
  Auth-->>Local: 7) 返回最终 IP 地址（例如 93.184.216.34）
  Local-->>Host: 8) 本地 DNS 将 IP 返回给主机
  Note right of Local: 本地域名服务器可能会把结果缓存一段时间

递归查询

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

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

sequenceDiagram
  participant Host as 主机
  participant Local as 本地域名服务器
  participant Root as 根域名服务器
  participant TLD as 顶级域名服务器 (TLD)
  participant Auth as 权限域名服务器 (Authoritative)

  Host->>Local: 1) 查询 www.example.com
  Local->>Root: 2) 向根域名服务器发起递归查询
  Root->>TLD: 3) 根服务器代为查询 TLD 服务器
  TLD->>Auth: 4) TLD 服务器递归查询权限域名服务器
  Auth-->>TLD: 5) 返回最终 IP 地址
  TLD-->>Root: 6) TLD 把结果返回给根服务器
  Root-->>Local: 7) 根服务器把最终 IP 地址交给本地 DNS
  Local-->>Host: 8) 本地 DNS 返回结果给主机

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

DNS 缓存

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

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

3 - FTP

工作原理

FTP 的传输流程如下：

1. 建立连接
   • FTP 基于 TCP 协议运行。客户端与服务器之间首先建立一条 控制连接（默认端口 21），用于命令与响应的传输。
   • 在实际传输数据时，还需要建立一条 数据连接。
2. 身份验证
   • 建立控制连接后，客户端需提供用户名和密码完成身份验证。
   • 部分服务器支持 匿名 FTP，允许用户以通用用户名（通常为 anonymous）和邮箱地址作为密码进行访问。
3. 命令与响应
   • 所有的 命令与响应 都通过控制连接完成。
   • 客户端发送命令（如上传、下载、列目录等），服务器返回 状态码（如成功、失败、权限不足），用于指示执行结果。
4. 数据连接的建立
   • 当需要传输文件或目录列表时，FTP 会额外建立数据连接。
   • 常见的两种模式：
     • 主动模式（Active Mode）：客户端开放端口，等待服务器回连进行数据传输。
     • 被动模式（Passive Mode）：服务器开放端口，等待客户端发起连接。
5. 文件传输
   • 数据连接建立后即可传输数据，包括文件内容或目录信息。
   • 支持两种传输模式：
     • ASCII 模式：适合文本文件，自动进行换行符转换。
     • 二进制模式：适合图像、音频、压缩包等二进制文件，逐字节传输，避免数据损坏。
6. 关闭会话
   • 文件传输完成或用户退出时，客户端通过 QUIT 命令请求关闭会话。
   • 服务器响应后，释放控制连接与数据连接。

控制连接

• 控制连接 是 FTP 会话中首先建立的连接，通常使用 TCP 端口 21。
• 主要作用是传输 命令和响应，用于 控制 FTP 会话的行为。
  • 客户端通过控制连接发送命令（如登录、列目录、切换目录）。
  • 服务器通过控制连接返回 状态码 和响应消息，指示命令执行结果（成功、失败、权限不足等）。
• 控制连接始终保持打开（持久连接），直到用户退出会话或发送 QUIT 命令。

数据连接

• 数据连接 专用于 文件内容和目录列表的传输，端口号由控制连接中的命令协商确定。
• 建立方式有两种模式：
  • 主动模式（Active Mode）
    • 客户端开放一个本地端口，并通过控制连接通知服务器。
    • 服务器主动连接到客户端该端口完成数据传输。
  • 被动模式（Passive Mode）
    • 服务器开放一个本地端口，并通过控制连接告知客户端。
    • 客户端主动连接到服务器该端口完成数据传输。
  • 数据连接 在需要时建立，用于 上传文件（客户端 → 服务器）或 下载文件（服务器 → 客户端）。

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

sequenceDiagram
    participant Client as 客户端
    participant Server as 服务器

    Note over Client,Server: 主动模式 (Active Mode)
    Client->>Server: 建立控制连接 (端口 21)
    Client->>Server: PORT 命令 (告知客户端开放的端口)
    Server-->>Client: 建立数据连接 (连接到客户端指定端口)
    Client->>Server: 发起数据传输请求 (如 LIST/RETR)
    Server-->>Client: 通过数据连接传输数据

    Note over Client,Server: 被动模式 (Passive Mode)
    Client->>Server: 建立控制连接 (端口 21)
    Client->>Server: PASV 命令 (请求服务器开放数据端口)
    Server-->>Client: 返回数据端口号
    Client->>Server: 连接到服务器指定端口（数据连接）
    Client->>Server: 发起数据传输请求
    Server-->>Client: 通过数据连接传输数据

4 - 电子邮件

电子邮件系统

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

用户代理

用户代理（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 登录服务器。
• 下载新邮件到本地设备。
• 可选择删除服务器上的邮件副本。

电子邮件格式

一封电子邮件由 信封 和 内容 两部分组成，其中邮件 内容 又可分为 首部 和 主体。
邮件的 首部格式 由 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 格式的正文）。

5 - 万维网

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 中，进一步改进了请求处理机制，允许多个请求和响应在同一个连接中并行进行，解决了队头阻塞的问题。

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 的请求时，它就可以区分这个请求是来自于那个客户端的了。