应用层

• 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 或一所大学都可以有一个本地域名服务器。

域名解析过程

域名解析是将人类可读的域名转换为计算机可理解的 IP 地址的过程。以下以递归查询为例说明DNS查询的步骤：

1. 客户端发出域名解析请求：当用户在 Web 浏览器中输入域名（例如www.example.com）时，客户端设备会向本地递归域名服务器发送 DNS 解析请求。
2. 本地域名服务器查询：
   • 本地域名服务器收到请求后，首先检查自己的缓存，如果有匹配的域名/IP 地址映射，它会立即返回响应。
   • 如果没有缓存或已过期，递归域名服务器将迭代地查询其他域名服务器，从根域名服务器开始，然后逐步向下查询，直到找到权威域名服务器。
3. 权威域名服务器响应：一旦递归域名服务器找到了域名的权威域名服务器，它会向权威域名服务器发送查询请求。权威域名服务器将提供域名对应的 IP 地址或其他相关信息。
4. 递归域名服务器响应客户端：递归域名服务器收到权威域名服务器的响应后，将结果存储在缓存中，并将 IP 地址返回给客户端。客户端可以使用此 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 的请求时，它就可以区分这个请求是来自于那个客户端的了。