应用层

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

# 应用层

## 网络应用模型

- C/S模型
- P2P模型

## DNS系统

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

## FTP

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

## 电子邮件

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

## WWW

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

1 - 网络应用模型

C/S模型

1. 端通常是用户终端设备，例如个人计算机、移动设备等。服务器是一个专门的设备或应用程序，负责提供某种服务或资源，例如文件存储、网站内容、数据库访问等。
2. 通信方式：在C/S模型中，客户端和服务器之间的通信是基于请求和响应的方式进行的。客户端向服务器发出请求，服务器响应请求并提供所需的服务或资源。
3. 中心化：C/S模型通常具有中心化的架构，服务器是中心节点，客户端通过与服务器通信来获取服务或资源。
4. 例子：典型的C/S应用包括Web浏览器与Web服务器之间的通信、电子邮件客户端与电子邮件服务器之间的通信等。

P2P模型

1. 角色分配：在P2P模型中，网络中的设备通常是对等的（Peer），没有明确的客户端和服务器的区分。每个设备都可以充当客户端和服务器的角色。
2. 通信方式：P2P模型中，设备之间的通信是对等的，它们可以相互协作、共享资源和服务，而不需要中心服务器的介入。设备可以直接连接到其他设备，而不需要经过中间服务器。
3. 分布式：P2P模型通常是分布式的，没有单一的中心节点。设备之间可以相互通信和共享资源，形成一个分散的网络。
4. 例子：典型的P2P应用包括文件共享网络（如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 Name Servers):
   • 这些服务器负责特定的顶级域名（如 .com, .org, .net 等）。它们为下一级的域名（如 example.com）提供有关权威名称服务器的信息。
3. 权威域名服务器 (Authoritative Name Servers):
   • 这些服务器为特定的域名（如 example.com）提供详细的 DNS 记录信息（例如 A 记录、MX 记录等）。只有权威服务器才能为其负责的域名提供这些信息。
   • 大多数组织拥有权威 DNS 服务器来为他们的域名提供解析服务。
4. 本地域名服务器 (Local Name Server)
   • 是在本地网络环境中运行的 DNS 服务器，它为该网络中的设备提供域名解析服务。
   • 每个 ISP 或一所大学都可以有一个本地域名服务器。

域名解析过程

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

递归查询

1. 客户端向递归服务器发送一个请求，比如解析 www.example.com。
2. 如果递归服务器没有缓存结果，它会从根服务器开始，逐级查询：
   • 首先查询根域名服务器（Root Server），获取顶级域（TLD）的服务器地址。
   • 再查询 TLD 服务器（比如 .com），获取权威服务器的地址。
   • 然后查询权威服务器，最终获取目标域名的 IP 地址。
3. 递归服务器将最终的 IP 地址返回给客户端。

迭代查询

1. 客户端向本地 DNS 服务器（或根服务器）发送查询请求，比如解析 www.example.com。
2. 根服务器返回 .com 顶级域的 DNS 服务器地址。
3. 客户端再向 .com 顶级域 DNS 服务器发送查询请求。
4. .com 顶级域返回 example.com 的权威服务器地址。
5. 客户端向 example.com 的权威服务器发送查询请求，获取最终的 IP 地址。

对比

3 - FTP

工作原理

1. 建立连接：
   • FTP通常使用TCP作为传输层协议。客户端和服务器之间首先建立一个TCP连接。FTP默认使用两个端口，一个用于控制连接（命令连接，通常是端口21），另一个用于数据传输连接。
2. 身份验证：
   • 一旦建立了控制连接，客户端需要提供用户名和密码以进行身份验证。有些FTP服务器还支持匿名FTP，允许用户使用一个通用的用户名（通常是"anonymous"）和电子邮件地址作为密码进行访问。
3. 命令与响应：
   • 控制连接用于传输FTP命令和服务器的响应。客户端可以向服务器发送各种FTP命令，如上传文件、下载文件、列出目录内容等。服务器将对每个命令响应一个状态码，指示命令执行的结果（例如，成功、失败等）。
4. 数据连接：
   • 当需要传输文件或目录列表时，FTP使用数据连接来进行实际的数据传输。数据连接可以以两种方式之一建立：
   • 主动模式（Active Mode）：客户端打开一个本地端口，并通知服务器连接到该端口以进行数据传输。
   • 被动模式（Passive Mode）：服务器打开一个本地端口，并通知客户端连接到该端口以进行数据传输。
   • 数据连接用于传输文件的内容或目录列表等信息。
5. 文件传输：
   • 一旦建立了数据连接，文件传输开始。客户端可以向服务器上传文件（将本地文件发送到服务器）或下载文件（从服务器获取文件）。
   • 文件传输可以在ASCII模式和二进制模式之间切换。ASCII模式适用于文本文件，而二进制模式适用于二进制文件（如图像、音频等）。
6. 关闭连接：
   • 一旦文件传输完成或用户完成FTP会话，客户端可以发送QUIT命令以终止FTP连接。服务器会响应，并关闭连接。

控制连接和数据连接

1. 控制连接（Control Connection）：
   • 控制连接是FTP会话的首要连接，通常使用TCP的端口21。
   • 控制连接用于传输FTP命令和服务器的响应，用来控制FTP会话的行为。客户端通过控制连接向服务器发送各种FTP命令，如登录、列出文件目录、切换工作目录等。
   • 服务器通过控制连接发送状态码和响应消息，以指示每个FTP命令的执行结果（例如，成功、失败等）。
   • 控制连接始终保持打开状态，直到用户完成FTP会话，或者用户发送QUIT命令以终止连接。
2. 数据连接（Data Connection）：
   • 数据连接用于实际的文件传输，以及在某些情况下，传输文件的目录列表信息。数据连接通常使用不同的端口，其端口号由控制连接中的FTP命令指定。
   • 有两种主要的数据连接模式：
   • 主动模式（Active Mode）：在主动模式下，客户端在一个本地端口打开，并通过控制连接告知服务器连接到该端口以进行数据传输。服务器主动连接到客户端的本地端口。
   • 被动模式（Passive Mode）：在被动模式下，服务器在一个本地端口打开，并通过控制连接告知客户端连接到该端口以进行数据传输。客户端主动连接到服务器的本地端口。
   • 数据连接用于上传文件（将文件从客户端发送到服务器）和下载文件（从服务器获取文件）。

4 - 电子邮件

SMTP邮件发送过程

SMTP（Simple Mail Transfer Protocol）是用于电子邮件传输的协议。其邮件处理模型涉及到邮件的发送、中继和接收。下面是 SMTP 的邮件处理模型的简要概述：

1. 用户代理 (User Agent, UA)：
   • 用户代理是用户用来创建、读取和回复邮件的应用程序。常见的用户代理有 Outlook、Thunderbird 等电子邮件客户端。
2. 邮件提交代理 (Mail Submission Agent, MSA)：
   • 当用户准备好发送电子邮件时，用户代理将邮件提交给邮件提交代理。MSA 负责接收从用户代理发来的邮件，并将其转发到邮件传输代理。
   • 在某些情况下，MSA 和 MTA 可能是同一个服务器或服务，但它们的功能是分开的。
3. 邮件传输代理 (Mail Transfer Agent, MTA)：
   • MTA 负责从 MSA 接收邮件并将其传输到接收方的邮件交换代理或其他 MTA。
   • 如果收件人的邮箱与发件人在同一域名下，MTA 也可能直接将邮件传递给邮件传递代理 (MDA)。
   • 如果收件人位于不同的域，MTA 可能会中继邮件，经过一系列的其他 MTAs，直到邮件到达收件人的域。
4. 邮件交换代理 (Mail Exchanger, MX)：
   • 当电子邮件需要被发送到另一个域时，发件人的 MTA 会查找该域的 DNS MX 记录以确定邮件应该发送到哪个服务器或 MTAs。
   • MX 记录指向接收邮件的服务器。
5. 邮件传递代理 (Mail Delivery Agent, MDA)：
   • 当邮件到达目的地后，MTA 将邮件传递给 MDA。MDA 负责将邮件放入用户的邮箱中。
   • 在用户准备读取邮件时，他们的用户代理会与邮件存储服务（例如 IMAP 或 POP3 服务器）交互，从中提取邮件。

SMTP和POP3协议

电子邮件格式和MIME

1. 电子邮件的基本结构：
   • 一个标准的电子邮件通常由以下部分组成：
   • 头部（Header）：包含了电子邮件的元数据，如发件人、收件人、主题、日期等信息。
   • 主体（Body）：包含了邮件的主要内容，可以是纯文本或HTML格式的富文本内容。
   • 附件（Attachments）：可以包括一个或多个附件，如文档、图像、音频或其他文件。附件是电子邮件的一部分，但它们通常不会直接显示在邮件主体中。
2. MIME标头：
   • MIME引入了一些新的标头字段，用于描述电子邮件的内容类型和编码方式。这些标头字段包括：
   • Content-Type：指定了邮件主体或附件的内容类型（如文本、图像、音频、视频等）和字符集。
   • Content-Disposition：指定了附件的显示方式，如内联显示（Inline）或作为附件下载（Attachment）。
   • Content-Transfer-Encoding：指定了内容的传输编码方式，如Base64编码，用于二进制数据的传输。
3. 文本和HTML格式：
   • MIME允许电子邮件既可以包含纯文本内容，也可以包含HTML格式的富文本内容。这使得电子邮件能够呈现更丰富的视觉和格式化效果。
   • 在MIME中，文本内容通常使用Content-Type标头字段指定为"text/plain"，而HTML内容使用Content-Type标头字段指定为"text/html"。
4. 附件：
   • MIME允许将文件附件添加到电子邮件中，以便发送和接收文件。附件通常使用Content-Disposition标头字段来指定其显示方式。
   • 附件的数据通常使用Base64编码进行传输，以确保二进制文件的可靠传输。
5. 内联图像和嵌入式内容：
   • MIME允许内联图像和嵌入式内容，这些内容可以直接显示在电子邮件的主体中。这在创建富文本邮件和HTML格式邮件时很有用。
6. Multipart电子邮件：
   • MIME引入了多部分电子邮件的概念，允许将不同类型的内容（如文本、HTML、图像、附件）组合在一个电子邮件中。
   • 多部分电子邮件使用multipart标头字段指定邮件的不同部分，并为每个部分指定相应的Content-Type。

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 技术来弥补。

组成部分

1. 请求和响应：HTTP 通信通常包括客户端向服务器发送请求，然后服务器返回响应的过程。
2. 方法：HTTP 定义了一组请求方法，用于表示对资源的不同操作：
   • GET：请求指定资源。
   • POST：提交数据以供处理。
   • PUT：更新指定资源。
   • DELETE：删除指定资源。
   • HEAD：与 GET 相似，但只请求资源的头部信息。
   • OPTIONS：获取可以应用于目标资源的通信选项。
   • PATCH：对资源进行部分修改。
   • 其他方法还包括 CONNECT, TRACE 等。
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 的请求时，它就可以区分这个请求是来自于那个客户端的了。